Модуль Apache mod_authnz_ldap

Краткое описание

Этот модуль позволяет интерфейсным модулям аутентификации, таким как mod_auth_basic, аутентифицировать пользователей через каталог LDAP.

mod_authnz_ldap поддерживает следующие возможности:

• Известно, что модуль поддерживает OpenLDAP SDK (версии 1.x и 2.x), Novell LDAP SDK и SDK iPlanet (Netscape).
• Сложные политики авторизации можно реализовать, представив их в виде фильтров LDAP.
• Использует расширенное кэширование операций LDAP с помощью mod_ldap.
• Поддержка LDAP через SSL (требуется Netscape SDK) или TLS (требуется OpenLDAP 2.x SDK или Novell LDAP SDK).

При использовании mod_auth_basic этот модуль вызывается директивой AuthBasicProvider со значением ldap.

Содержание

• Общие замечания
• Принцип работы
  • Этап аутентификации
  • Этап авторизации
• Директивы Require
  • Require ldap-user
  • Require ldap-group
  • Require ldap-dn
  • Require ldap-attribute
  • Require ldap-filter
  • Require ldap-search
• Примеры
• Использование TLS
• Использование SSL
• Предоставление сведений для входа
• Использование Active Directory
• Использование Microsoft FrontPage с mod_authnz_ldap
  • Принцип работы
  • Замечания

Общие замечания

Этот модуль кэширует результаты аутентификации и авторизации в соответствии с настройками mod_ldap. Изменения на базовом LDAP-сервере не будут немедленно отражены на HTTP-сервере. В частности, это относится к блокировке и отзыву доступа пользователей, смене паролей и изменению членства в группах. Сведения о параметрах кэширования см. в директивах mod_ldap.

Принцип работы

Предоставление пользователю доступа состоит из двух этапов. На первом этапе выполняется аутентификация: провайдер аутентификации mod_authnz_ldap проверяет действительность учетных данных пользователя. Этот этап также называют этапом поиска и привязки. На втором этапе выполняется авторизация: mod_authnz_ldap определяет, разрешен ли аутентифицированному пользователю доступ к соответствующему ресурсу. Этот этап также называют этапом сравнения.

mod_authnz_ldap регистрирует провайдер аутентификации authn_ldap и обработчик авторизации authz_ldap. Провайдер аутентификации authn_ldap можно включить с помощью директивы AuthBasicProvider, указав значение ldap. Обработчик authz_ldap расширяет типы авторизации директивы Require, добавляя значения ldap-user, ldap-dn и ldap-group.

Этап аутентификации

На этапе аутентификации mod_authnz_ldap выполняет поиск в каталоге записи, соответствующей имени пользователя, переданному HTTP-клиентом. Если найдена одна уникальная запись, mod_authnz_ldap пытается выполнить привязку к серверу каталога, используя DN этой записи и пароль, переданный HTTP-клиентом. Поскольку сначала выполняется поиск, а затем привязка, этот этап часто называют этапом поиска и привязки. Ниже перечислены действия, выполняемые на этом этапе.

1. Сформировать поисковый фильтр, объединив атрибут и фильтр, указанные в директиве AuthLDAPURL, с именем пользователя, переданным HTTP-клиентом.
2. Выполнить поиск в каталоге с помощью сформированного фильтра. Если поиск возвращает не ровно одну запись, запретить или отклонить доступ.
3. Получить различающееся имя записи, найденной в результате поиска, и попытаться выполнить привязку к серверу LDAP, используя этот DN и пароль, переданный HTTP-клиентом. Если привязка не удалась, запретить или отклонить доступ.

На этапе поиска и привязки используются следующие директивы

Этап авторизации

На этапе авторизации mod_authnz_ldap пытается определить, разрешен ли пользователю доступ к ресурсу. Для многих таких проверок требуется, чтобы mod_authnz_ldap выполнил операцию сравнения на сервере LDAP. Поэтому этот этап часто называют этапом сравнения. mod_authnz_ldap принимает следующие директивы Require, позволяющие определить, приемлемы ли учетные данные:

• Предоставить доступ, если задана директива Require ldap-user и указанное в ней имя пользователя совпадает с именем, переданным клиентом.
• Предоставить доступ, если задана директива Require ldap-dn и указанный в ней DN совпадает с DN, полученным из каталога LDAP.
• Предоставить доступ, если задана директива Require ldap-group и DN, полученный из каталога LDAP (или имя пользователя, переданное клиентом), содержится в группе LDAP или, возможно, в одной из ее подгрупп.
• Предоставить доступ, если задана директива Require ldap-attribute и атрибут, полученный из каталога LDAP, совпадает с указанным значением.
• Предоставить доступ, если задана директива Require ldap-filter и поисковый фильтр успешно находит один пользовательский объект, соответствующий DN аутентифицированного пользователя.
• Предоставить доступ, если задана директива Require ldap-search и поисковый фильтр успешно возвращает один соответствующий объект с любым различающимся именем.
• в противном случае запретить или отклонить доступ

Можно также использовать другие значения Require, для которых может потребоваться загрузка дополнительных модулей авторизации.

• Предоставить доступ всем успешно аутентифицированным пользователям, если задана директива Require valid-user. (требуется mod_authz_user)
• Предоставить доступ, если задана директива Require group и загружен модуль mod_authz_groupfile с установленной директивой AuthGroupFile.
• другие...

На этапе сравнения mod_authnz_ldap использует следующие директивы:

Директивы Require

Директивы Apache Require используются на этапе авторизации, чтобы убедиться, что пользователю разрешен доступ к ресурсу. mod_authnz_ldap расширяет типы авторизации значениями ldap-user, ldap-dn, ldap-group, ldap-attribute и ldap-filter. Можно также использовать другие типы авторизации, но для этого может понадобиться загрузить дополнительные модули авторизации.

Начиная с версии 2.4.8, в директивах LDAP require поддерживаются выражения.

Require ldap-user

Директива Require ldap-user указывает, каким именам пользователей разрешен доступ к ресурсу. Получив из каталога уникальный DN, mod_authnz_ldap выполняет операцию сравнения LDAP, используя имя пользователя, указанное в Require ldap-user, чтобы проверить, является ли это имя частью только что полученной записи LDAP. Доступ можно предоставить нескольким пользователям, указав их имена в одной строке через пробел. Если имя пользователя содержит пробел, его необходимо заключить в двойные кавычки. Доступ также можно предоставить нескольким пользователям, используя несколько директив Require ldap-user и указывая по одному пользователю в каждой строке. Например, при AuthLDAPURL, равном ldap://ldap/o=Example?cn (то есть для поиска используется cn), можно использовать следующие директивы Require, чтобы ограничить доступ:

Require ldap-user "Barbara Jenson"
Require ldap-user "Fred User"
Require ldap-user "Joe Manager"

Благодаря тому, как mod_authnz_ldap обрабатывает эту директиву, Barbara Jenson может войти как Barbara Jenson, Babs Jenson или под любым другим cn, указанным в ее записи LDAP. Для поддержки всех значений атрибута в записи пользователя достаточно одной строки Require ldap-user.

Если бы в приведенном выше URL использовался атрибут uid, а не атрибут cn, приведенные выше три строки можно было бы объединить в одну

Require ldap-user bjenson fuser jmanager

Require ldap-group

Эта директива указывает группу LDAP, участникам которой разрешен доступ. В ней указывается различающееся имя группы LDAP. Примечание: не заключайте имя группы в кавычки. Например, предположим, что в каталоге LDAP существует следующая запись:

dn: cn=Administrators, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Example
uniqueMember: cn=Fred User, o=Example

Следующая директива предоставит доступ Fred и Barbara:

Require ldap-group cn=Administrators, o=Example

Участников можно искать и в подгруппах указанной группы LDAP, если значение AuthLDAPMaxSubGroupDepth больше 0. Например, предположим, что в каталоге LDAP существуют следующие записи:

dn: cn=Employees, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Managers, o=Example
uniqueMember: cn=Administrators, o=Example
uniqueMember: cn=Users, o=Example

dn: cn=Managers, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Bob Ellis, o=Example
uniqueMember: cn=Tom Jackson, o=Example

dn: cn=Administrators, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Example
uniqueMember: cn=Fred User, o=Example

dn: cn=Users, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Allan Jefferson, o=Example
uniqueMember: cn=Paul Tilley, o=Example
uniqueMember: cn=Temporary Employees, o=Example

dn: cn=Temporary Employees, o=Example
objectClass: groupOfUniqueNames
uniqueMember: cn=Jim Swenson, o=Example
uniqueMember: cn=Elliot Rhodes, o=Example

Следующие директивы предоставят доступ Bob Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson и Paul Tilley, но не предоставят доступ Jim Swenson или Elliot Rhodes (поскольку они находятся на глубине подгрупп 2):

Require ldap-group cn=Employees, o=Example
AuthLDAPMaxSubGroupDepth 1

Поведение этой директивы изменяют директивы AuthLDAPGroupAttribute, AuthLDAPGroupAttributeIsDN, AuthLDAPMaxSubGroupDepth, AuthLDAPSubGroupAttribute и AuthLDAPSubGroupClass.

Require ldap-dn

Директива Require ldap-dn позволяет администратору предоставлять доступ на основе различающихся имен. В ней указывается DN, который должен совпасть, чтобы доступ был предоставлен. Если различающееся имя, полученное с сервера каталога, совпадает с различающимся именем в Require ldap-dn, авторизация предоставляется. Примечание: не заключайте различающееся имя в кавычки.

Следующая директива предоставит доступ для конкретного DN:

Require ldap-dn cn=Barbara Jenson, o=Example

Поведение этой директивы изменяет директива AuthLDAPCompareDNOnServer.

Require ldap-attribute

Директива Require ldap-attribute позволяет администратору предоставлять доступ на основе атрибутов аутентифицированного пользователя в каталоге LDAP. Если атрибут в каталоге совпадает со значением, заданным в конфигурации, доступ предоставляется.

Следующая директива предоставит доступ всем, у кого атрибут employeeType равен active

Require ldap-attribute employeeType="active"

Несколько пар «атрибут/значение» можно указать в одной строке через пробел или в нескольких директивах Require ldap-attribute. Перечисление нескольких пар «атрибут/значение» подразумевает операцию ИЛИ. Доступ будет предоставлен, если любое из перечисленных значений атрибутов совпадет со значением соответствующего атрибута в объекте пользователя. Если значение атрибута содержит пробел, двойными кавычками нужно заключить только это значение.

Следующая директива предоставит доступ всем, у кого атрибут city равен "San Jose" или атрибут status равен "Active"

Require ldap-attribute city="San Jose" status="active"

Require ldap-filter

Директива Require ldap-filter позволяет администратору предоставлять доступ на основе сложного поискового фильтра LDAP. Если DN, возвращенный в результате поиска по фильтру, совпадает с DN аутентифицированного пользователя, доступ предоставляется.

Следующая директива предоставит доступ всем, у кого есть мобильный телефон и кто работает в отделе маркетинга

Require ldap-filter "&(cell=*)(department=marketing)"

Разница между директивами Require ldap-filter и Require ldap-attribute состоит в том, что ldap-filter выполняет поиск в каталоге LDAP с помощью указанного поискового фильтра, а не простое сравнение атрибутов. Если достаточно простого сравнения атрибутов, операция сравнения, выполняемая директивой ldap-attribute, будет быстрее поиска, выполняемого директивой ldap-filter, особенно в большом каталоге.

При использовании выражения в фильтре необходимо правильно экранировать фильтры LDAP, чтобы защититься от LDAP-инъекций. Для этого можно использовать функцию ldap.

<LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
  Require ldap-filter (memberOf=cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}},ou=Websites,o=Example)
</LocationMatch>

Require ldap-search

Директива Require ldap-search позволяет администратору предоставлять доступ на основе универсального поискового фильтра LDAP с использованием выражения. Доступ предоставляется, если поисковый фильтр находит ровно одно совпадение, независимо от различающегося имени.

Следующая директива предоставит доступ к URL, соответствующим заданным объектам на сервере LDAP:

<LocationMatch ^/dav/(?<SITENAME>[^/]+)/>
Require ldap-search (cn=%{ldap:%{unescape:%{env:MATCH_SITENAME}} Website)
</LocationMatch>

Примечание: необходимо правильно экранировать все выражения, чтобы защититься от LDAP-инъекций. Для этого можно использовать функцию ldap, как показано в примере выше.

Примеры

• Предоставить доступ всем, кто есть в каталоге LDAP, используя UID для поиска.

  AuthLDAPURL "ldap://ldap1.example.com:389/ou=People, o=Example?uid?sub?(objectClass=*)"
  Require valid-user

• Следующий пример аналогичен предыдущему, но в нем опущены параметры с полезными значениями по умолчанию. Обратите также внимание на использование резервного сервера LDAP.

  AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
  Require valid-user

• Следующий пример похож на предыдущий, но вместо UID в нем используется общее имя. Это может быть проблематично, если у нескольких пользователей каталога совпадает cn, поскольку поиск по cn должен возвращать ровно одну запись. Поэтому такой подход не рекомендуется: лучше выбрать атрибут, уникальность которого в каталоге гарантирована, например uid.

  AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
  Require valid-user

• Предоставить доступ всем участникам группы Administrators. Пользователи должны проходить аутентификацию с помощью UID.

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid
  Require ldap-group cn=Administrators, o=Example

• Предоставить доступ всем участникам группы, имя которой совпадает с именем хоста виртуального хоста. В этом примере для построения фильтра используется выражение.

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid
  Require ldap-group cn=%{SERVER_NAME}, o=Example

• В следующем примере предполагается, что у всех сотрудников Example, использующих буквенно-цифровой пейджер, есть атрибут LDAP qpagePagerID. Пример предоставит доступ только тем пользователям (аутентифицированным по UID), у которых есть буквенно-цифровые пейджеры:

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
  Require valid-user

• В следующем примере показано, как с помощью фильтров реализовать сложные административные требования. Без фильтров пришлось бы создать новую группу LDAP и следить за тем, чтобы состав ее участников синхронизировался со списком пользователей пейджеров. С фильтрами это становится тривиальной задачей. Требуется предоставить доступ всем, у кого есть пейджер, а также Joe Manager, у которого пейджера нет, но которому нужно получить доступ к тому же ресурсу:

  AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
  Require valid-user

  Поначалу этот последний пример может показаться сложным, поэтому полезно посмотреть, как будет выглядеть поисковый фильтр в зависимости от того, кто подключается, как показано ниже. Если Fred User подключится как fuser, фильтр будет выглядеть так:

  (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

  Предыдущий поиск будет успешным, только если у fuser есть пейджер. Когда Joe Manager подключается как jmanager, фильтр выглядит так:

  (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

  Предыдущий поиск будет успешным независимо от того, есть ли у jmanager пейджер.

Использование TLS

Чтобы использовать TLS, см. директивы mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert и LDAPTrustedMode.

В качестве второго необязательного параметра директивы AuthLDAPURL можно указать тип соединения, переопределяющий тип по умолчанию, заданный директивой LDAPTrustedMode. Это позволяет обновить соединение, установленное по URL ldap://, до защищенного соединения через тот же порт.

Использование SSL

Чтобы использовать SSL, см. директивы mod_ldap LDAPTrustedClientCert, LDAPTrustedGlobalCert и LDAPTrustedMode.

Чтобы указать защищенный сервер LDAP, используйте в директиве AuthLDAPURL ldaps:// вместо ldap://.

Предоставление сведений для входа

При выполнении аутентификации этим модулем атрибуты LDAP, указанные в директиве AuthLDAPURL, помещаются в переменные окружения с префиксом "AUTHENTICATE_".

При выполнении авторизации этим модулем атрибуты LDAP, указанные в директиве AuthLDAPURL, помещаются в переменные окружения с префиксом "AUTHORIZE_".

Если поле атрибутов содержит имя пользователя, общее имя и номер телефона, CGI-программа сможет получить эти сведения без выполнения дополнительного независимого запроса LDAP.

Это может значительно упростить разработку и настройку некоторых веб-приложений.

Использование Active Directory

Установка Active Directory может одновременно поддерживать несколько доменов. Чтобы различать пользователей из разных доменов, в запись пользователя каталога можно добавить идентификатор под названием User Principal Name (UPN). Обычно UPN состоит из имени учетной записи пользователя и компонентов домена, например somebody@nz.example.com.

Возможно, вы захотите настроить модуль mod_authnz_ldap для аутентификации пользователей из любого домена леса Active Directory. Тогда и somebody@nz.example.com, и someone@au.example.com можно будет аутентифицировать одним и тем же запросом.

Для этого Active Directory поддерживает концепцию глобального каталога. Глобальный каталог представляет собой доступную только для чтения копию выбранных атрибутов всех серверов Active Directory в лесу Active Directory. Запрос к глобальному каталогу позволяет искать во всех доменах одним запросом, не выполняя поиск на серверах, соединенных потенциально медленными каналами связи.

Если глобальный каталог включен, он представляет собой независимый сервер каталога, работающий на порту 3268 (3269 для SSL). Чтобы найти пользователя, выполните поиск по поддереву по атрибуту userPrincipalName с пустым корнем поиска, например:

AuthLDAPBindDN apache@example.com
AuthLDAPBindPassword password
AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub

Пользователям потребуется вводить User Principal Name в качестве имени для входа, например somebody@nz.example.com.

Использование Microsoft FrontPage с mod_authnz_ldap

Обычно FrontPage использует собственные файлы пользователей и групп веб-сайта FrontPage (то есть модули mod_authn_file и mod_authz_groupfile) для обработки всей аутентификации. К сожалению, нельзя просто перейти на аутентификацию LDAP, добавив нужные директивы: это нарушит работу форм Permissions в клиенте FrontPage, которые пытаются изменить стандартные текстовые файлы авторизации.

После создания веб-сайта FrontPage для добавления к нему аутентификации LDAP достаточно добавить следующие директивы в каждый файл .htaccess, создаваемый на веб-сайте

AuthLDAPURL       "the url"
AuthGroupFile     "mygroupfile"
Require group     "mygroupfile"

Принцип работы

FrontPage ограничивает доступ к веб-сайту, добавляя директиву Require valid-user в файлы .htaccess. Директива Require valid-user успешно срабатывает для любого пользователя, который действителен с точки зрения LDAP. Это означает, что действительным пользователем считается любой, у кого есть запись в каталоге LDAP, тогда как FrontPage считает действительными только тех, кто указан в локальном файле пользователей. Заменив ldap-group авторизацией по файлу групп, можно позволить Apache обращаться к локальному файлу пользователей (которым управляет FrontPage), а не к LDAP, при авторизации пользователя.

После добавления директив, указанных выше, пользователи FrontPage смогут выполнять все операции управления из клиента FrontPage.

Замечания

• При выборе URL LDAP атрибут для аутентификации должен быть пригоден для использования в файле пользователей mod_authn_file. Для этого идеально подходит идентификатор пользователя.
• При добавлении пользователей через FrontPage администраторам следует выбирать имена пользователей, уже существующие в каталоге LDAP (по очевидным причинам). Кроме того, пароль, введенный администратором в форму, игнорируется, поскольку Apache будет выполнять аутентификацию по паролю в базе данных LDAP, а не по паролю в локальном файле пользователей. Это может запутать администраторов веб-сайта.
• Для поддержки FrontPage Apache должен быть скомпилирован с mod_auth_basic, mod_authn_file и mod_authz_groupfile. Это необходимо, поскольку Apache по-прежнему будет использовать файл групп mod_authz_groupfile для определения уровня доступа пользователя к веб-сайту FrontPage.
• Директивы необходимо поместить в файлы .htaccess. Их размещение внутри директив <Location> или <Directory> не сработает. Это связано с тем, что mod_authnz_ldap должен иметь возможность получить директиву AuthGroupFile из файлов FrontPage .htaccess, чтобы определить, где искать список действительных пользователей. Если директивы mod_authnz_ldap находятся не в том же файле .htaccess, что и директивы FrontPage, этот обходной прием не сработает, поскольку mod_authnz_ldap не сможет обработать файл .htaccess и найти файл пользователей, которым управляет FrontPage.

AuthLDAPAuthorizePrefix prefix

AuthLDAPAuthorizePrefix AUTHORIZE_

AuthLDAPBindAuthoritative off|on

AuthLDAPBindAuthoritative on

AuthLDAPBindDN distinguished-name

AuthLDAPBindPassword password

#Password used as-is
AuthLDAPBindPassword secret

#Run /path/to/program to get my password
AuthLDAPBindPassword exec:/path/to/program

#Run /path/to/otherProgram and provide arguments
AuthLDAPBindPassword "exec:/path/to/otherProgram argument1"

AuthLDAPCharsetConfig file-path

Language-Extension charset [Language-String] ...

AuthLDAPCompareAsUser on|off

AuthLDAPCompareAsUser off

AuthLDAPCompareDNOnServer on|off

AuthLDAPCompareDNOnServer on

AuthLDAPDereferenceAliases never|searching|finding|always

AuthLDAPDereferenceAliases always

AuthLDAPGroupAttribute attribute

AuthLDAPGroupAttribute member uniqueMember

AuthLDAPGroupAttributeIsDN on|off

AuthLDAPGroupAttributeIsDN on

AuthLDAPInitialBindAsUser off|on

AuthLDAPInitialBindAsUser off

AuthLDAPInitialBindPattern regex substitution

AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)

AuthLDAPInitialBindPattern (.+) $1@example.com

AuthLDAPInitialBindPattern (.+) cn=$1,dc=example,dc=com

AuthLDAPMaxSubGroupDepth Number

AuthLDAPMaxSubGroupDepth 10

AuthLDAPRemoteUserAttribute uid

AuthLDAPRemoteUserIsDN on|off

AuthLDAPRemoteUserIsDN off

AuthLDAPSearchAsUser on|off

AuthLDAPSearchAsUser off

AuthLDAPSubGroupAttribute attribute

AuthLDAPSubGroupAttribute member uniqueMember

AuthLDAPSubGroupClass LdapObjectClass

AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames

AuthLDAPURL url [NONE|SSL|TLS|STARTTLS]

AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/dc=..."