Модуль Apache mod_authnz_ldap

Обзор

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

mod_authnz_ldap поддерживает следующие функции:

• Поддерживает OpenLDAP SDK (как 1.x, так и 2.x), Novell LDAP SDK и iPlanet (Netscape) SDK.
• Сложные политики авторизации могут быть реализованы путём представления политики с помощью фильтров 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
• Примеры
• Использование 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, для которых может потребоваться загрузка дополнительных модулей авторизации.

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

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

Директивы Require

Директивы 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 указывает, какие имена пользователей могут получить доступ к ресурсу. После того как mod_authnz_ldap извлёк уникальный DN из каталога, он выполняет LDAP-операцию сравнения, используя имя пользователя, указанное в директиве Require ldap-user, чтобы определить, является ли этот пользователь частью только что полученной записи LDAP. Доступ нескольким пользователям можно предоставить, перечислив имена пользователей в строке через пробелы. Если имя пользователя содержит пробелы, оно должно быть заключено в двойные кавычки. Доступ нескольким пользователям также можно предоставить, используя несколько директив Require ldap-user, по одному пользователю в строке. Например, с AuthLDAPURL (т.е., cn используется для поиска), следующие директивы Require могут быть использованы для ограничения доступа:

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

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

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

Require ldap-user bjenson fuser jmanager

Require ldap-group

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

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

Следующая директива предоставит доступ как Фреду, так и Барбаре:

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

Следующие директивы позволят получить доступ Бобу Эллису, Тому Джексону, Барбаре Дженсен, Фреду Юзеру, Аллану Джефферсону и Полу Тилли, но не позволят получить доступ Джиму Свенсону или Эллиоту Родсу (поскольку они находятся на глубине вложенности подгрупп 2):

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

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

Требовать ldap-dn

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

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

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

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

Требовать ldap-атрибут

Директива 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"

Требовать ldap-фильтр

Директива 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, используя их 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

• Предоставить доступ любому пользователю в группе Администраторы. Пользователи должны пройти аутентификацию с помощью своего 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 и убедиться, что члены группы остаются синхронизированными с пользователями пейджеров. Это становится тривиальным с помощью фильтров. Цель состоит в предоставлении доступа любому пользователю, у которого есть пейджер, а также предоставлении доступа Джоу Менеджеру, у которого нет пейджера, но которому необходимо получить доступ к тому же ресурсу:

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

  Это может показаться запутанным, поэтому полезно оценить, как будет выглядеть фильтр поиска в зависимости от того, кто подключается, как показано ниже. Если Фред Юзер подключается как fuser, фильтр будет выглядеть так

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

  Вышеупомянутый поиск увенчается успехом только в том случае, если у fuser есть пейджер. Когда Джоу Менеджер подключается как jmanager, фильтр выглядит так

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

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

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

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

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

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

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

Для указания защищенного сервера LDAP используйте ldaps:// в директиве AuthLDAPURL вместо ldap://.

Размещение информации о входе

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

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

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

Это может значительно упростить кодирование и конфигурацию, необходимую в некоторых веб-приложениях.

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

Установка Active Directory может поддерживать несколько доменов одновременно. Для различения пользователей между доменами может быть добавлен идентификатор, называемый именем принципа пользователя (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

Пользователям нужно будет вводить свое имя принципа пользователя в качестве логина в формате somebody@nz.example.com.

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

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

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

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

Как это работает

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

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

Ограничения

• При выборе URL LDAP атрибут, используемый для аутентификации, должен быть таким, чтобы он был также действительным для помещения в файл пользователей mod_authn_file. Идентификатор пользователя идеально подходит для этого.
• При добавлении пользователей через FrontPage администраторы FrontPage должны выбирать имена пользователей, которые уже существуют в каталоге LDAP (по понятным причинам). Кроме того, пароль, который администратор вводит в форму, игнорируется, так как Apache фактически будет выполнять аутентификацию по паролю в базе данных LDAP, а не по паролю в локальном файле пользователей. Это может вызвать путаницу у веб-администраторов.
• Apache должен быть скомпилирован с mod_auth_basic, mod_authn_file и mod_authz_groupfile для использования поддержки FrontPage. Это связано с тем, что 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 off

AuthLDAPCompareDNOnServer on

AuthLDAPDereferenceAliases always

AuthLDAPGroupAttribute member uniqueMember

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=..."