Вы здесь

LDAP авторизация на сайте

Drupal можно с легкостью назвать универсальным инструментом для реализации различных задач, также и определенной сложности enterprise решения.
Так получилось, что в основном Drupal я использую на предприятии, внутри Интранет сети, которая имеет Active Directory. И для того чтобы полноценно
использовать инфраструктура нашей сети, программой минимум это является Active Directory авторизация на сайтах и сервисах, и тут проблем у Drupal-а
нет, благодаря модулю Lightweight Directory Access Protocol (LDAP).
В данном материале я хочу рассказать, как он настроен в моём окружении, и может кому то статья пригодится.

Итак, сразу забегая скажу, что с помощью данного модуля вы сможете предоставить:
1. LDAP авторизацию в вашей сети (в моём случае используется Active Directory от Microsoft)
2. Настроить сквозную авторизацию (когда пользователь автоматически входит под учётной записью операционной системы)
3. Ограничивать доступ, тем кто может входить на сайт и кому нельзя.
4. Синхронизация атрибутов учетной записи Active Directory с полями профиля пользователя на сайте, так и наоборот.
5. Актуализация учетной записи на сайте после смены логина учетной записи Active Directory (обычно происходит после смены фамилии сотрудника - меняется аналогично логин)
6. Присваивание роли пользователю на сайте в зависимости от его нахождения в определенной группе Active Directory

Итак для работы авторизации нам понадобятся 2 модуля:

  1. Lightweight Directory Access Protocol (LDAP)
  2. LDAP Single Sign On

Т.к. я пока являюсь активным пользователем Drupal 7, то все инструкции буду приводить на его примере, но опять же когда я интереса ради запускал Drupal 8,
то понял что модуль практически идентичен 7ой версии Drupal.

Скопируем к себе данные модуля, а также их зависимости Ctools и Entity API. На странице модулей активируем следующие модули:

  1. LDAP Authentication
  2. LDAP Authorization (модуль опционально, если вам требуется ограничение на доступ к сайта, либо ролям сайта по признаку нахождения пользователя в группах Active Directory)
  3. LDAP Authorization - Drupal Roles (дополнение к выше описанному модулю)
  4. LDAP Servers
  5. LDAP SSO (модуль опционально, если вам не требуется сквозная авторизация, либо пока веб-сервер не настроен под это, можно не устанавливать)
  6. LDAP User Module

Стоит отметить, что модуль не установится, если в ваших настройках PHP не установлен модуль php_ldap. Потому заранее установите, и настройте под характеристики вашего окружения.

После успешной установки модуля, перейдем в его настройки которые расположены здесь admin/config/people/ldap

Настройки модуля поделены на 4 вкладки: Settings, Servers, User, Authentication, Authorization

В первой вкладке настраивается метод шифрования паролей учетной записи Active Directory внутри Drupal-а.

На своей практике я это не использую, потому сразу перехожу во вторую вкладку Servers. И здесь мы остановимся по подробней.
Во вкладке отображены все созданные сервера LDAP авторизации, которые будут использованы на сайте, по умолчанию этот список пуст и нам с помощью кнопки Add LDAP Server Configuration можно создать новый сервер.
Страница создания сервера поделена на несколько блоков, рассмотрим каждый из них:

Connection settings

Machine name for this server configuration. - собственно машинное имя создаваемого сервера. Обычно называю active_directory
Name **- ещё какое то имя сервера, также называю active_directory
**Enabled
- ставлю галочку, таким образом включаю создаваемую конфигурацию сервера
LDAP Server Type - в моём случае выбираю Active Directory
LDAP server - доменное имя либо IP адрес по которому находится сервер Active directory, в моём случае ad.zv
LDAP port - отставляю по умолчанию 389, у нас он такой же
Use Start-TLS - галочку не ставлю, т.к. не используем шифрование
Follow LDAP Referrals - также не ставлю, хотя так до конца и не разбирался для чего нужна данная настройка

Bingind method

Binding Method for Searches (such as finding user object or their group memberships)
Другими словами спрашивается каким образом, от чьего имени будет происходить подключение к сервере Active directory для поиска пользователя на факт существования, чтения его аттрибутов и т.д.
Также как и в описании к значения использую первый вариант Service Account Bind как best practice.
А именно подключение к серверу будет происходить от специальной заранее созданной учетной записи в Active directory которая имеет право на чтение каталогов и структуры Active Directory
Выбирая данный вариант ниже необходимо указать логин и пароль сервисной учетной записи в полях DN for non-anonymous search и Password for non-anonymous search

Clear existing password from database. Check this when switching away from Service Account Binding - пункт не применим к нашему методу описанному выше, потому галочку не ставим.

LDAP user to Drupal user relationship

Base DNs for LDAP users, groups, and other entries - базовый DN где находятся все пользователи в Active Directory, в моём случае ставлю DC=ad,DC=zv. В данной настройке лучше проконсультироваться с системными администраторами вашего сервера Active Directory
AuthName attribute и AccountName attribute - атрибут в котором хранится логин пользователя и аккаунт имя, обычно они должны быть одинаковы, и в большинстве случаев указывается samaccountname , т.к. по умолчанию логин находится там в Active Directory
Email attribute - атрибут в котором находится почтовый ящик пользователя, в моём случае mail. Стоит отметить что для Drupal-а это поле обязательно, т.к. Drupal не может иметь пользователя без почтового ящика, потому если в вашем окружении есть вероятность того что существует пользователи без почтового ящика, то вам необходимо воспользоваться полем ниже для заполнения почтового ящика по шаблону, либо позже в другой вкладке мы вернёмся к данной настройке с другой стороны.
Email template - шаблон почтового ящик, применяется тогда, когда ваши почтовые ящики например идентичны логину, либо состоят из нескольких атрибутов пользователя в Active Directory. Потому вы может просто составить его из токенов аттрибутов.
Thumbnail attribute - атрибут в котором находится изображение пользователя (в binary) для последующей загрузки в изображения профиль пользователя в Drupal-е, в моём случае thumbnailPhoto
Persistent and Unique User ID Attribute - уникальный атрибут, который никогда не изменится у пользователя Active Directrory. Применяется в тех случаях когда например логин у вас представляет собой фамилию и инициалы пользователя, и если вдруг пользователь сменил фамилию, и следом ему изменили логин, то для следующего входа им на сайт для Drupal-а он будет по умолчанию как новый пользователь, и Drupal будет создавать новую учётную запись (конечно при условии, что почтовый ящик ему тоже сменили, т.к. если он останется прежним, то Drupal сообщит о конфликте почтового ящика, и не создаст новую запись). Именно поэтому данное поле служит уникальным ключом на которое в первую очередь будет смотреться при входе пользователя на сайт, даже если он сменил логин, Drupal сначала найдёт его по данному атрибуты, и тогда по нему построит связь с пользователем Active Directory и как следствие обновит ему логин на сайте Drupal. В моем случае это objectsid
Does the Persistent and Unique User ID Attribute hold a binary value? - галочку ставлю, т.к. objectsid хранится в binary.

0
0
02.11.2018 - 21:29