Apache. Документация на русском


Разделы:   1    2    3    4    5    6    7    8    9      10      11    12    13    14    15    16  

Раздел 10. Модули Апача

Пункты:   85    86    88    89    90    91    92    93    94    95    96    97    98    99    100    101    102    103    104    105    106    107    108    109      110      111    112    113    114    115    116    117    118    119    120    121    122    123    124    125    126    127    128    129    130    131    132    133    134    135    136    137    138    139    140    141    142    143    144    145    146    147    148    149    150    151    152    153    154    155    156    157    158    159    160    161    163    164    165    166    167    168    170    171    172    173    174    175    176    177    178    179    180    181    182    183    184    185    186    187    188    189    190    191    192    193    194    195    196    197    198    199    200    201    203    204    205    206    207    208    209    210    211    212    213  

 <         > 
  RU            EN  

Пункт 110. Модуль 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 значением.

Содержание

  • Общие предостережения
  • Операция
    • Фаза аутентификации
    • Фаза авторизации
  • Требуемые директивы
    • Требовать пользователя ldap
    • Требовать ldap-группу
    • Требовать ldap-dn
    • Требовать ldap-атрибут
    • Требовать ldap-фильтр
  • Примеры
  • Использование 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. Если привязка не удалась, запретите или отклоните доступ.

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

AuthLDAPURL Указывает сервер LDAP, базовое DN, атрибут для использования при поиске, а также дополнительный поисковый фильтр.
AuthLDAPBindDN Необязательный DN для привязки на этапе поиска.
AuthLDAPBindPassword Необязательный пароль для привязки на этапе поиска.

Фаза авторизации

На этапе авторизации 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 использует следующие директивы на этапе сравнения:

AuthLDAPURL Атрибут, указанный в URL-адресе, используется в операциях сравнения для Require ldap-user операции.
AuthLDAPCompareDNOnServer Определяет поведение директивы Require ldap-dn .
AuthLDAPGroupAttribute Определяет атрибут, используемый для сравнений в Require ldap-group директиве.
AuthLDAPGroupAttributeIsDN Указывает, следует ли использовать DN пользователя или имя пользователя при выполнении сравнений для директивы Require ldap-group .
AuthLDAPMaxSubGroupDepth Определяет максимальную глубину подгрупп, которые будут оцениваться при сравнениях в Require ldap-group директиве.
AuthLDAPSubGroupAttribute Определяет атрибут, используемый при получении членов подгруппы текущей группы во время сравнений в директиве Require ldap-group .
AuthLDAPSubGroupClass Задает значения объектного класса LDAP, используемые для определения того, действительно ли запрошенные объекты каталога являются объектами группы (в отличие от объектов пользователя) во время Require ldap-group обработки подгрупп директивы.

Требуемые директивы

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

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

Требовать пользователя ldap

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

 Требовать пользователя ldap "Барбара Дженсон"
Требовать пользователя ldap "Fred User"
Требовать пользователя ldap "Joe Manager" 

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

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

 Требуется пользователь ldap bjenson fuser jmanager 

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

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

 dn: cn=Администраторы, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Барбара Дженсон, o=Пример
uniqueMember: cn=Fred User, o=Example 

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

 Требуется группа ldap cn=Администраторы, o=Пример 

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

 dn: cn=Сотрудники, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Менеджеры, o=Пример
uniqueMember: cn=Администраторы, o=Пример
uniqueMember: cn=Пользователи, o=Пример
dn: cn=Менеджеры, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Боб Эллис, o=пример
uniqueMember: cn=Том Джексон, o=Пример
dn: cn=Администраторы, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Барбара Дженсон, o=Пример
uniqueMember: cn=Fred User, o=Example
dn: cn=Пользователи, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Аллан Джефферсон, o=Пример
uniqueMember: cn=Пол Тилли, o=Пример
uniqueMember: cn=Временные сотрудники, o=Пример
dn: cn=Временные сотрудники, o=Пример
объектный класс: groupOfUniqueNames
uniqueMember: cn=Джим Свенсон, o=Пример
uniqueMember: cn=Эллиот Родс, o=пример 

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

 Требуется группа ldap cn=Сотрудники, o=Пример
AuthLDAPMaxSubGroupDepth 1 

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

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

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

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

 Требуется ldap-dn cn=Барбара Дженсон, o=Пример 

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

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

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

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

 Требовать ldap-атрибут "employeeType=active" 

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

Следующая директива предоставит доступ любому с атрибутом города, равным «Сан-Хосе», или со статусом, равным «Активный».

 Требуется ldap-атрибут city="San Jose" "status=active" 

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

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

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

 Требовать ldap-фильтр "&(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=*)"
    Требовать действительного пользователя 
  • Следующий пример такой же, как и выше; но с опущенными полями с полезными значениями по умолчанию. Также обратите внимание на использование резервного сервера LDAP.
     AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example"
    Требовать действительного пользователя 
  • Следующий пример похож на предыдущий, но вместо UID используется обычное имя. Обратите внимание, что это может быть проблематично, если несколько человек в каталоге используют один и тот же cn , потому что поиск cn должен возвращать только одну запись. Вот почему этот подход не рекомендуется: лучше выбрать атрибут, который гарантированно уникален в вашем каталоге, например uid .
     AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn"
    Требовать действительного пользователя 
  • Предоставьте доступ любому в группе администраторов. Пользователи должны пройти аутентификацию, используя свой UID.
     AuthLDAPURL ldap://ldap.example.com/o=Example?uid
    Требуется группа ldap cn=Администраторы, o=Пример 
  • Предоставьте доступ любому в группе, чье имя совпадает с именем хоста виртуального хоста. В этом примере выражение используется для построения фильтра.
     AuthLDAPURL ldap://ldap.example.com/o=Example?uid
    Требуется группа ldap cn=%{ИМЯ_СЕРВЕРА}, o=Пример 
  • В следующем примере предполагается, что каждый сотрудник Example, у которого есть буквенно-цифровой пейджер, будет иметь атрибут LDAP qpagePagerID . В примере доступ предоставляется только людям (аутентифицированным по их UID), у которых есть буквенно-цифровые пейджеры:
     AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*)
    Требовать действительного пользователя 
  • Следующий пример демонстрирует возможности использования фильтров для выполнения сложных административных требований. Без фильтров было бы необходимо создать новую группу LDAP и обеспечить синхронизацию членов группы с пользователями пейджера. Это становится тривиальным с фильтрами. Цель состоит в том, чтобы предоставить доступ всем, у кого есть пейджер, а также предоставить доступ Джо Менеджеру, у которого нет пейджера, но которому нужен доступ к тому же ресурсу:

     AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager))
    Требовать действительного пользователя 

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

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=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, используйте в директиве ldaps:// AuthLDAPURL вместо ldap:// .

Предоставление информации для входа

когда этот модуль выполняет аутентификацию , атрибуты ldap, указанные в authldapurl директиве, помещаются в переменные среды с префиксом «AUTHENTICATE_».

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

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

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

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

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

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

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

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

 AuthLDAPBindDN apache@example.com
Пароль AuthLDAPBindPassword
AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub 

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

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

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

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

 AuthLDAPURL "адрес"
AuthGroupFile "файл моей группы"
Требовать группу "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 директиву, найденную в .htaccess файлах FrontPage, чтобы он знал, где искать действительный список пользователей. Если mod_authnz_ldap директивы не находятся в том же .htaccess файле, что и директивы FrontPage, то хак не сработает, потому что у него mod_authnz_ldap никогда не будет возможности обработать .htaccess файл и он не сможет найти пользовательский файл, управляемый FrontPage.


Директива AuthLDAPAuthorizePrefix

Описание:Указывает префикс для переменных окружения, устанавливаемых при авторизации.
Синтаксис: AuthLDAPAuthorizePrefix prefix
По умолчанию: AuthLDAPAuthorizePrefix AUTHORIZE_
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.6 и выше

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

Примечание

Переменные авторизации не устанавливаются, когда пользователь авторизуется на основе Require valid-user .

Директива AuthLDAPBindAuthoritative

Описание:Определяет, используются ли другие поставщики проверки подлинности, когда пользователь может быть сопоставлен с DN, но сервер не может успешно выполнить привязку с учетными данными пользователя.
Синтаксис: AuthLDAPBindAuthoritative off|on
По умолчанию: AuthLDAPBindAuthoritative on
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

По умолчанию последующие поставщики аутентификации запрашиваются только в том случае, если пользователя нельзя сопоставить с DN, но не в том случае, если пользователя можно сопоставить с DN и его пароль не может быть проверен с помощью привязки LDAP. Если AuthLDAPBindAuthoritative установлено значение off , другие настроенные модули проверки подлинности будут иметь возможность проверить пользователя, если привязка LDAP (с учетными данными текущего пользователя) не удастся по какой-либо причине.

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

Смотрите также

  • AuthUserFile
  • AuthBasicProvider


Директива AuthLDAPBindDN

Описание:Необязательный DN для использования при привязке к серверу LDAP
Синтаксис: AuthLDAPBindDN distinguished-name
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Необязательный DN, используемый для привязки к серверу при поиске записей. Если не указано, mod_authnz_ldap будет использоваться анонимная привязка.



Директива AuthLDAPBindPassword

Описание:Пароль, используемый в сочетании с DN привязки
Синтаксис: AuthLDAPBindPassword password
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:exec: был добавлен в версии 2.4.5.

Пароль привязки для использования вместе с DN привязки. Обратите внимание, что пароль привязки, вероятно, является конфиденциальными данными и должен быть должным образом защищен. Вы должны использовать AuthLDAPBindDN и только AuthLDAPBindPassword в том случае, если они вам абсолютно необходимы для поиска в каталоге.

Если значение начинается с exec: результирующая команда будет выполнена, и первая строка, возвращенная программой в стандартный вывод, будет использоваться в качестве пароля.

 #Пароль используется как есть
Секрет AuthLDAPBindPassword
# Запустите /путь/к/программе, чтобы получить мой пароль
AuthLDAPBindPassword exec:/путь/к/программе
# Запустите /path/to/otherProgram и укажите аргументы
AuthLDAPBindPassword "exec:/path/to/otherProgram arguments1" 


Директива AuthLDAPCharsetConfig

Описание:Конфигурационный файл преобразования языка в кодировку
Синтаксис: AuthLDAPCharsetConfig file-path
Контекст:конфигурация сервера
Положение дел:Расширение
Модуль:mod_authnz_ldap

Директива AuthLDAPCharsetConfig устанавливает расположение языка в файле конфигурации преобразования кодировки. Путь к файлу относится к ServerRoot . Этот файл определяет список языковых расширений для наборов символов. Большинство администраторов используют предоставленный charset.conv файл, который связывает общие языковые расширения с наборами символов.

Файл содержит строки в следующем формате:

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

Регистр расширения значения не имеет. Пустые строки и строки, начинающиеся с символа решетки ( # ), игнорируются.



Директива AuthLDAPCompareAsUser

Описание:Используйте учетные данные аутентифицированного пользователя для выполнения сравнений авторизации
Синтаксис: AuthLDAPCompareAsUser on|off
По умолчанию: AuthLDAPCompareAsUser off
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.6 и выше

Когда установлено и mod_authnz_ldap пользователь аутентифицирован, сравнения LDAP для авторизации используют запрошенное отличительное имя (DN) и пароль базовой аутентификации HTTP аутентифицированного пользователя вместо учетных данных, настроенных сервером.

Проверки авторизации ldap -attribute , ldap-user и ldap-group (только одноуровневые) используют сравнения.

Эта директива влияет на сравнения, выполняемые во время обработки вложенной группы, только если AuthLDAPSearchAsUser она также включена.

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

Смотрите также

  • AuthLDAPInitialBindAsUser
  • AuthLDAPSearchAsUser


Директива AuthLDAPCompareDNOnServer

Описание:Используйте сервер LDAP для сравнения DN
Синтаксис: AuthLDAPCompareDNOnServer on|off
По умолчанию: AuthLDAPCompareDNOnServer on
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Если установлено, mod_authnz_ldap будет использовать сервер LDAP для сравнения DN. Это единственный надежный способ сравнить DN. mod_authnz_ldap выполнит поиск в каталоге DN, указанного в директиве Require dn , затем извлечет DN и сравнит его с DN, полученным из записи пользователя. Если эта директива не установлена, mod_authnz_ldap просто выполняется сравнение строк. При таком подходе можно получить ложноотрицательные результаты, но это намного быстрее. Обратите внимание, что mod_ldap кеш может ускорить сравнение DN в большинстве ситуаций.



Директива AuthLDAPDereferenceAliases

Описание:Когда модуль разыменует псевдонимы
Синтаксис: AuthLDAPDereferenceAliases never|searching|finding|always
По умолчанию: AuthLDAPDereferenceAliases always
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Эта директива указывает, когда mod_authnz_ldap будут разыменовываться псевдонимы во время операций LDAP. Значение по умолчанию always .



Директива AuthLDAPGroupAttribute

Описание:Атрибуты LDAP, используемые для идентификации пользователей-членов групп.
Синтаксис: AuthLDAPGroupAttribute attribute
По умолчанию: AuthLDAPGroupAttribute member uniquemember
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Эта директива указывает, какие атрибуты LDAP используются для проверки наличия пользователей в группах. Можно использовать несколько атрибутов, указав эту директиву несколько раз. Если не указано, то mod_authnz_ldap использует атрибуты member и uniquemember .



Директива AuthLDAPGroupAttributeIsDN

Описание:Используйте DN имени пользователя клиента при проверке членства в группе
Синтаксис: AuthLDAPGroupAttributeIsDN on|off
По умолчанию: AuthLDAPGroupAttributeIsDN on
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Когда установлено on , эта директива говорит использовать различающееся имя имени пользователя клиента при проверке членства в группе. В противном случае будет использоваться имя пользователя. Например, предположим, что клиент отправил имя пользователя bjenson , соответствующее DN LDAP cn=Babs Jenson, o=Example . Если эта директива установлена, mod_authnz_ldap будет проверяться, есть ли в группе cn=Babs Jenson, o=Example член. Если эта директива не установлена, то mod_authnz_ldap будет проверяться, есть ли в группе bjenson член.



Директива AuthLDAPInitialBindAsUser

Описание:Определяет, выполняет ли сервер первоначальный поиск DN, используя собственное имя пользователя пользователей базовой проверки подлинности, а не анонимно или с жестко запрограммированными учетными данными для сервера.
Синтаксис: AuthLDAPInitialBindAsUser off|on
По умолчанию: AuthLDAPInitialBindAsUser off
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.6 и выше

По умолчанию сервер либо анонимно, либо с выделенным пользователем и паролем преобразует имя пользователя для базовой проверки подлинности в различающееся имя (DN) LDAP. Эта директива заставляет сервер использовать дословные имя пользователя и пароль, предоставленные входящим пользователем, для выполнения первоначального поиска DN.

Если дословное имя пользователя нельзя связать напрямую, но требуется некоторое косметическое преобразование, см. раздел AuthLDAPInitialBindPattern .

Эту директиву следует использовать только в том случае, если ваш LDAP-сервер не поддерживает анонимный поиск и вы не можете использовать выделенный файл AuthLDAPBindDN .

Недоступно только с авторизацией

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

Смотрите также

  • AuthLDAPInitialBindPattern
  • AuthLDAPBindDN
  • AuthLDAPCompareAsUser
  • AuthLDAPSearchAsUser


Директива AuthLDAPInitialBindPattern

Описание:Указывает преобразование имени пользователя для базовой аутентификации, которое будет использоваться при привязке к серверу LDAP для выполнения поиска по DN.
Синтаксис: AuthLDAPInitialBindPattern regex substitution
По умолчанию: AuthLDAPInitialBindPattern (.*) $1 (remote username used verbatim)
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.6 и выше

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

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

Эту директиву следует использовать только в том случае, если ваш LDAP-сервер не поддерживает анонимный поиск и вы не можете использовать выделенный файл AuthLDAPBindDN .

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

Недоступно только с авторизацией

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

отладка

Подставленное DN записывается в переменной окружения LDAP_BINDASUSER . Если регулярное выражение не соответствует входным данным, используется дословное имя пользователя.

Смотрите также

  • AuthLDAPInitialBindAsUser
  • AuthLDAPBindDN


Директива AuthLDAPMaxSubGroupDepth

Описание:Задает максимальную глубину вложенности подгрупп, которая будет оцениваться перед прекращением поиска пользователя.
Синтаксис: AuthLDAPMaxSubGroupDepth Number
По умолчанию: AuthLDAPMaxSubGroupDepth 10
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.0 и выше

Когда для этой директивы установлено ненулевое значение X в сочетании с использованием директивы Require ldap-group someGroupDN , предоставленные учетные данные пользователя будут искаться как член объекта someGroupDN каталога или любой член группы текущей группы до максимального уровня вложенности, X указанного параметром эта директива.

Смотрите Require ldap-group раздел для более подробного примера.

Производительность вложенных групп

При AuthLDAPSubGroupAttribute перекрытии AuthLDAPGroupAttribute (как это происходит по умолчанию и в соответствии с требованиями общих схем LDAP) некэшированный поиск подгрупп в больших группах может быть очень медленным. Если вы используете большие невложенные группы, установите AuthLDAPMaxSubGroupDepth значение ноль.



Директива AuthLDAPRemoteUserAttribute

Описание:Используйте значение атрибута, возвращенное во время пользовательского запроса, чтобы установить переменную среды REMOTE_USER.
Синтаксис: AuthLDAPRemoteUserAttribute uid
По умолчанию: none
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

Если эта директива установлена, значение переменной REMOTE_USER среды будет установлено равным значению указанного атрибута. Убедитесь, что этот атрибут включен в список атрибутов в определении AuthLDAPUrl, иначе эта директива не будет действовать. Эта директива, если она присутствует, имеет приоритет над AuthLDAPRemoteUserIsDN . Эта директива полезна, если вы хотите, чтобы люди входили на веб-сайт, используя адрес электронной почты, но серверное приложение ожидает, что имя пользователя будет идентификатором пользователя.



Директива AuthLDAPRemoteUserIsDN

Описание:Используйте DN имени пользователя клиента, чтобы установить переменную среды REMOTE_USER.
Синтаксис: AuthLDAPRemoteUserIsDN on|off
По умолчанию: AuthLDAPRemoteUserIsDN off
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

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



Директива AuthLDAPSearchAsUser

Описание:Используйте учетные данные аутентифицированного пользователя для выполнения поиска авторизации
Синтаксис: AuthLDAPSearchAsUser on|off
По умолчанию: AuthLDAPSearchAsUser off
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.6 и выше

Если установлено и mod_authnz_ldap аутентифицирован пользователь, LDAP при поиске авторизации использует запрошенное различающееся имя (DN) и пароль базовой аутентификации HTTP аутентифицированного пользователя вместо учетных данных, настроенных сервером.

Проверка авторизации ldap -filter и ldap-dn использует поиск.

Эта директива влияет на сравнения, выполняемые во время обработки вложенной группы, только если AuthLDAPCompareAsUser она также включена.

Эту директиву следует использовать только в том случае, если ваш LDAP-сервер не поддерживает анонимный поиск и вы не можете использовать выделенный файл AuthLDAPBindDN .

Смотрите также

  • AuthLDAPInitialBindAsUser
  • AuthLDAPCompareAsUser


Директива AuthLDAPSubGroupAttribute

Описание:Указывает метки атрибутов, по одному значению на строку директивы, используемые для различения членов текущей группы, которые являются группами.
Синтаксис: AuthLDAPSubGroupAttribute attribute
По умолчанию: AuthLDAPSubgroupAttribute member uniquemember
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.0 и выше

Объект группы LDAP может содержать элементы, являющиеся пользователями, и элементы, являющиеся группами (называемые вложенными или подгруппами). Директива AuthLDAPSubGroupAttribute определяет метки членов группы, а директива AuthLDAPGroupAttribute определяет метки членов пользователей. Можно использовать несколько атрибутов, указав эту директиву несколько раз. Если не указано, то mod_authnz_ldap использует атрибуты member и uniqueMember .



Директива AuthLDAPSubGroupClass

Описание:Указывает, какие значения objectClass LDAP идентифицируют объекты каталога, которые являются группами во время обработки подгрупп.
Синтаксис: AuthLDAPSubGroupClass LdapObjectClass
По умолчанию: AuthLDAPSubGroupClass groupOfNames groupOfUniqueNames
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap
Совместимость:Доступно в версии 2.3.0 и выше

Объект группы LDAP может содержать элементы, являющиеся пользователями, и элементы, являющиеся группами (называемые вложенными или подгруппами). Директива AuthLDAPSubGroupAttribute определяет метки участников, которые могут быть подгруппами текущей группы (в отличие от пользователей). Директива AuthLDAPSubGroupClass определяет значения объектного класса LDAP, используемые для проверки того, что эти потенциальные подгруппы на самом деле являются групповыми объектами. Затем в проверенных подгруппах можно выполнить поиск дополнительных пользователей или членов подгруппы. Можно использовать несколько атрибутов, указав эту директиву несколько раз. Если не указано, mod_authnz_ldap используются значения groupOfNames и groupOfUniqueNames .



Директива AuthLDAPUrl

Описание:URL-адрес, указывающий параметры поиска LDAP
Синтаксис: AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS]
Контекст:каталог, .htaccess
Переопределить:Аутконфиг
Положение дел:Расширение
Модуль:mod_authnz_ldap

URL-адрес RFC 2255, в котором указаны используемые параметры поиска LDAP. Синтаксис URL-адреса

ldap://host:port/basedn?attribute?scope?filter

Если вы хотите указать более одного URL-адреса LDAP, которые Apache должен попробовать по очереди, используйте следующий синтаксис:

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

Предостережение: если вы указываете несколько серверов, вам необходимо заключить всю строку URL в кавычки; в противном случае вы получите сообщение об ошибке: «AuthLDAPURL принимает один аргумент, URL-адрес для определения соединения LDAP.» Конечно, вы можете использовать параметры поиска для каждого из них.

LDAP
Для обычного ldap используйте строку ldap . Для безопасного LDAP используйте ldaps вместо этого. Безопасный LDAP доступен только в том случае, если Apache был связан с библиотекой LDAP с поддержкой SSL.
хост:порт

Имя/порт сервера ldap (по умолчанию для localhost:389 и ldap для localhost:636 ) ldaps . Чтобы указать несколько резервных серверов LDAP, просто перечислите все серверы, разделенные пробелами. mod_authnz_ldap попытается подключиться к каждому серверу по очереди, пока не установит успешное соединение. Если указано несколько серверов ldap, то весь URL-адрес LDAP должен быть заключен в двойные кавычки.

После установления соединения с сервером это соединение остается активным на протяжении всего жизненного цикла процесса httpd или до тех пор, пока сервер LDAP не выйдет из строя.

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

основанный
DN ветви каталога, с которого должны начинаться все поиски. По крайней мере, это должна быть вершина вашего дерева каталогов, но также может указываться поддерево в каталоге.
атрибут
Атрибут для поиска. Хотя RFC 2255 разрешает список атрибутов, разделенных запятыми, будет использоваться только первый атрибут, независимо от их количества. Если атрибуты не указаны, по умолчанию используется uid . Рекомендуется выбрать атрибут, который будет уникальным для всех записей в поддереве, которое вы будете использовать. Все перечисленные атрибуты будут помещены в среду с префиксом AUTHENTICATE_ для использования другими модулями.
объем
Масштабы поиска. Может быть или one или sub . Обратите внимание, что область base также поддерживается RFC 2255, но не поддерживается этим модулем. Если область не указана или base указана, по умолчанию используется область sub .
фильтр
Действительный поисковый фильтр LDAP. Если не указано, по умолчанию используется значение (objectClass=*) , которое будет искать все объекты в дереве. Фильтры ограничены примерно 8000 символов (определение MAX_STRING_LEN в исходном коде Apache). Этого должно быть более чем достаточно для любого приложения. В 2.4.10 и более поздних версиях ключевое слово none отключает использование фильтра; это требуется для некоторых примитивных серверов LDAP.

При выполнении поиска атрибут, фильтр и имя пользователя, переданные HTTP-клиентом, объединяются для создания поискового фильтра, который выглядит как . (&(filter)(attribute=username))

Например, рассмотрим URL-адрес ldap://ldap.example.com/o=Example?cn?sub?(posixid=*) . Когда клиент пытается подключиться с использованием имени пользователя Babs Jenson , результирующий поисковый фильтр будет иметь вид (&(posixid=*)(cn=Babs Jenson)) .

Можно добавить необязательный параметр, позволяющий URL-адресу LDAP переопределять тип подключения. Этот параметр может быть одним из следующих:

НИКТО
Установите незащищенное соединение с портом LDAP по умолчанию. Это то же самое, что и ldap:// на порту 389.
SSL
Установите безопасное соединение на безопасном порту LDAP по умолчанию. Это то же самое, что ldaps://
ТЛС | СТАРТЛС
Установите обновленное защищенное соединение на порту LDAP по умолчанию. Это соединение будет инициировано на порту 389 по умолчанию, а затем обновлено до безопасного соединения на том же порту.

См. выше примеры AuthLDAPUrl URL-адресов.



 <         > 

Пункты:   85    86    88    89    90    91    92    93    94    95    96    97    98    99    100    101    102    103    104    105    106    107    108    109      110      111    112    113    114    115    116    117    118    119    120    121    122    123    124    125    126    127    128    129    130    131    132    133    134    135    136    137    138    139    140    141    142    143    144    145    146    147    148    149    150    151    152    153    154    155    156    157    158    159    160    161    163    164    165    166    167    168    170    171    172    173    174    175    176    177    178    179    180    181    182    183    184    185    186    187    188    189    190    191    192    193    194    195    196    197    198    199    200    201    203    204    205    206    207    208    209    210    211    212    213  

Рейтинг@Mail.ru