Рассмотрим настройку и работу схем аутентификации Microsoft LDAP и Microsoft Kerberos SSO в XSQUARE - PGHS. Интеграция PGHS с LDAP позволяет использовать информацию о пользователях в группах пользователей, которые уже существуют в большинстве корпоративных сред, для обеспечения безопасного управления пользователями и упрощения доступа. Таким образом, схема аутентификации Microsoft LDAP позволяет получить доступ к PGHS с любого устройства под привычными корпоративными учетками.
Использование Microsoft Kerberos SSO позволяет вообще не вводить логин и пароль, а авторизоваться в PGHS нажатием одной кнопки при условии логона в операционную систему под доменной учетной записью.
Для демонстрации этих возможностей развернем тестовый домен на базе Microsoft Windows Server 2019.
Установка Windows Server 2019
Для начала загружаемся с установочного носителя, выбираем язык, формат времени и раскладку клавиатуры.
Выбираем установку стандартной редакции с графическим интерфейсом.
Принимаем лицензионное соглашение. Выбираем Custom Install для чистой установки.
Назначаем пароль для учетной записи администратора. После перезагрузки входим в систему под учетной записью администратора.
Создание домена
Перед тем, как начать установку Active Directory, необходимо выполнить несколько подготовительных шагов.
Для начала настроим статический IP-адрес. Это можно сделать в настройках сетевого адаптера. Открываем свойства сетевого адаптера.
Выбираем протокол IPv4 и вводим статический IP-адрес.
Также желательно изменить имя сервера на более понятное. Заходим в свойства системы.
Изменяем имя сервера, после чего необходимо перезагрузиться.
Теперь установим роль контроллера домена. Открываем диспетчер серверов, нажимаем «Управление», «Добавить роли и компоненты».
Нажимаем «Далее» на приветственной странице установки. В следующем окне оставляем установку ролей и компонентов, нажимаем «Далее».
Выбираем сервер, на который будет установлена роль контроллера домена. По умолчанию выбран локальный сервер и нажимаем «Далее».
Среди всех ролей выбираем следующие:
• DHCP-сервер
• DNS-сервер
• Доменные службы Active Directory
и нажимаем «Далее».
Пропускаем все следующие разделы и нажимаем «Установить».
После завершения установки кликаем по пункту меню «Повысить роль этого сервера до уровня контроллера домена».
В открывшемся окне выбираем операцию развертывания. Если разворачивается первый контроллер домена в сети, как в нашем случае, оставляем выбор на «Добавить лес», вводим имя домена и нажимаем «Далее».
В следующем окне оставляем все как есть и вводим надежный пароль для режима восстановления. В окне параметра DNS нажимаем «Далее». В окне «Дополнительные параметры» автоматически будет подобрана именно NETBIOS. Его менять не обязательно, просто нажимаем «Далее». В окне «Пути» стоит оставить все как есть. Начнется проверка системы на соответствие требованиям. Если ошибок не будет, активируется кнопка «Установить».
Дождитесь окончания повышения сервера до контроллера домена.
Сервер будет перезагружен, а после перезагрузки станет контроллером домена.
Создание пользователей и групп
Теперь создадим нового пользователя в домене. Заходим в оснастку «Пользователи и компьютеры Active Directory».
Раскрываем наш домен, кликаем ПКМ «Users» и выбираем «Создать» → «Пользователь».
Создаем тестового пользователя Max Belov.
Аналогичным способом добавляем две тестовые группы test_group1 и test_group2.
Добавим нашего пользователя Max Belov в обе группы.
В Active Directory любой пользователь по умолчанию имеет право на чтение каталога, поэтому создадим сервисную учетную запись пользователя ldap_reader, с помощью которой PGHS будет читать содержимое Active Directory.
Включим в оснастке отображение дополнительных компонентов.
Откроем свойства пользователя ldap_reader, теперь нам доступен Редактор атрибутов. Из редактора атрибутов скопируем или запомним атрибут distinguishedName (уникальное имя).
Значение этого атрибута мы будем указывать в настройках для чтения каталога Active Directory.
Ввод клиентского компьютера в домен
Введем в наш домен клиентский компьютер на базе ОС Windows 10. Перед вводом компьютера нам необходимо настроить сетевые параметры. Обычно клиентские компьютеры получают настройки от DHCP-сервера, но для примера укажем их вручную. Открываем свойства сетевого адаптера, где нас интересуют настройки IP версии 4. Укажем наш контроллер домена в качестве основного шлюза и в качестве DNS-сервера.
После этого можно ввести компьютер в домен. Для этого заходим в свойства системы и на вкладке «Имя компьютера» нажимаем «Изменить». Указываем имя компьютера и наш домен xsquare.local.
Далее необходимо ввести логин и пароль учетной записи с правами на добавление в домен, в нашем случае это - Администратор. Добро пожаловать в домен xsquare.local, но для применения изменений необходимо перезагрузиться. После перезагрузки мы можем войти в домен под учетной записью нашего пользователя Max Belov.
Настройка Microsoft LDAP в PGHS
Итак, переходим к самому главному! На отдельном сервере под управлением OC Xubuntu мы установили XRAD и PGHS. Для начала проверим возможность подключения к Active Directory с этого компьютера с помощью нашей сервисной учетной записи ldap_reader. Это можно сделать с помощью утилиты ldapsearch, которую можно установить следующим образом:
sudo apt install ldap-utils
Проверим подключение к Active Directory:
ldapsearch -x -H ldap://10.150.117.224 -D "cn=ldap_reader,cn=Users,dc=xsquare,dc=local" -w "Qweasdzxc123" -b "dc=xsquare,dc=local"
После успешного чтения содержимого каталога Active Directory, переходим в режим суперпользователя и откроем для редактирования файл auth_config.json в каталоге PGHS: /usr/local/xsquare.pghs/auth_config.json
auth_config.json содержит массив описателей схем аутентификации. Каждая схема состоит из трех элементов:
- name - имя схемы
- type - тип схемы
- options — параметры схемы
После установки PGHS нам доступны шаблоны для каждой поддерживаемой схемы аутентификации.
Отредактируем схему с именем «User Auth Microsoft LDAP» и типом «microsoft_ldap» следующим образом:
{
"name": "User Auth Microsoft LDAP",
"type": "microsoft_ldap",
"options": {
"host": "10.150.117.224",
"port": 389,
"base": "DC=xsquare,DC=local",
"encryption": "plain",
"bind_dn": "CN=ldap_reader,CN=Users,DC=xsquare,DC=local",
"password": "Qweasdzxc123",
"request_user_groups": true
}
}
где
- host — адрес нашего контроллера домена
- base — точка входа в домен, мы указали корень домена xsquare.local
- bind_dn — имя пользователя для подключения к LDAP
- password — пароль нашего пользователя ldap_reader
Мы будем тестировать подключение без шифрования на порту 389. Сохраняем изменения и перезапускаем службу PGHS:
systemctl restart xsquare.pghs.service
Далее заходим в XDAR Builder. Для использования схем аутентификации необходимо создать список схем, состоящих из имени и типа, которые будут использоваться в XRAD при создании страниц, а затем в PGHS при обработке. Этот список по сути является отображением списка из файла auth_config.json.
Перейдем к настройке первой страницы авторизации. Если мы перейдем в процессинг страницы авторизации, то увидим здесь одну единственную схему аутентификации с именем User Auth, которая реализует аутентификацию по логину и паролю.
Нажмем ПКМ по блоку схем аутентификации и добавим новую схему типа Microsoft LDAP c именем«User Auth Microsoft LDAP». Так как схема использует логин и пароль, то укажем источники для данных переменных.
До этого у нас была одна схема User Auth, которая вызывалась всегда. (Условие отображения — Always). Теперь же нам нужно разделить вызов схемы аутентификации в зависимости от того, какая кнопка на форме авторизации нажата. Это можно реализовать с помощью условия отображения SQL Expression. После нажатия кнопки значение ее статического идентификатора будет записано в переменную REQUEST. Поэтому в SQL Expression можно указать следующий код:
$1 = 'MicrosoftLDAP’
А в качестве входного параметра REQUEST
Аналогично изменим условия отображения для схемы User Auth:
$1 = 'LOG_IN’
Таким образом, при нажатии на кнопку Microsoft LDAP у нас будет вызываться обработка схемы User Auth Microsoft LDAP. При нажатии кнопки Войти со статическим идентификатором LOG_IN будет вызываться базовая схема аутентификации.
Сохраняем изменения нашей страницы авторизации и проверим в PGHS вход с помощью схемы Microsoft LDAP и нашего пользователя Max Belov.
Успех!
Общая схема работы Microsoft LDAP описывается следующей последовательностью действий:
- Пользователь вводит логин и пароль, используемые для аутентификации в корпоративной сети;
- PGHS обращается к указанному в настройках AD/LDAP серверу и проверяет наличие пользователя в базе пользователей на корпоративном сервере:
- если пользователя с такими данными в корпоративной сети не существует, то система запрещает вход;
- если пользователь существует, то проверяется его пароль и в случае успеха он получает разрешение на доступ к PGHS и авторизуется.
Что важно: PGHS не хранит пароли корпоративных пользователей, они хранятся на стороне AD/LDAP.
После того, как пользователь успешно авторизовался, имя пользователя записывается в глобальную переменную APP_USER, а группы пользователя - через запятую записываются в переменную APP_USER_GROUPS.
Давайте создадим тестовую страницу user_data и отобразим содержимое этих переменных для нашего пользователя.
Так как наш пользователь Max Belov состоит в группах test_group1 и test_group2, то создадим на странице два региона типа HTML. В первом - запишем следующий код:
<p>&APP_USER. состоит в группе test_group1</p>
В условиях отображения региона выберем SQL Expression со следующим кодом:
$1 LIKE '%test_group1%', а в качестве входного параметра передадим переменную APP_USER_GROUPS.
Аналогичным образом создадим второй регион для проверки test_group2:
сохраним изменения и посмотрим на результат. На странице отображается оба региона:
Теперь зайдем на контроллер домена в оснастку Пользователи и компьютеры Active Directory, откроем свойства пользователя Max Belov, вкладку Член групп и удалим пользователя из группы test_group1:
После чего вернемся в PGHS, и перезайдем под пользователем Max Belov для проверки изменений. Как видно все работает так, как задумывалось.
Настройка Microsoft Kerberos SSO в PGHS
PGHS поддерживает беспарольную аутентификацию с помощью технологии единого входа Single Sign-On на базе протокола Kerberos. Рассмотрим настройку прозрачной аутентификации Microsoft Kerberos SSO. Первое, что нужно сделать, это чтобы для всех клиентов наш сервер с PGHS был доступен по определенному имени.
Достичь этого можно различными способами. В нашем случае давайте сделаем это посредством создания A-записи в DNS. Для этого в диспетчере серверов заходим в «Средства» и открываем оснастку DNS.
В диспетчере DNS, открываем «Зоны прямого просмотра» нашего контроллера домена, выбираем домен xsquare.local и в контекстном меню выбираем «Создать узел (A или AAAA)».
Указываем, что наш сервер 10.150.117.220 c PGHS и XRAD будет доступен по имени PGHS.
Общий алгоритм настройки Kerberos SSO сводится к нескольким шагам:
- Связать имя сервисной службы (Service Principal Name) c учетной записью пользователя/компьютера
- Сгенерировать keytab файл
- Сконфигурировать PGHS
Service Principal Name (SPN) – это уникальный идентификатор экземпляра службы. В нашем случае для контроллера домена такой службой выступает сервер c PGHS.
SPN имеет следующий вид:
protocol/service.name@DOMAIN
Необходимо обратить внимание, что в качестве service.name нужно использовать полное имя сервера, а в качестве протокола – HTTP. Таким образом SPN для нашего сервера будет иметь следующий вид:
HTTP/pghs.xsquare.local@XSQUARE.LOCAL
В Active Directory имя сервисной службы SPN привязывается к учетной записи компьютера или пользователя. Рекомендуем создать отдельную учетную запись сервисного пользователя с определёнными параметрами:
- запретить смену пароля
- не ограничивать срок действия пароля
Это важно, так как при смене пароля или истечении срока действия придется заново генерировать keytab файлы привязанные к этому пользователю.
Поэтому создадим пользователя pghs_kerberos
Запретим смену пароля и снимем ограничение срока действия пароля:
SPN можно создавать с помощью утилиты setspn. Но также SPN будет создано при генерации keytab файла. Поэтому сразу сгенерируем keytab файл. Для этого запускаем powershell и используем утилиту ktpass указывая SPN, имя пользователя, пароль, режимы шифрования и выходной файл:
ktpass -princ HTTP/pghs.xsquare.local@XSQUARE.LOCAL -mapuser pghs_kerberos -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass Password123!!! -out С:\pghs.keytab
Проверяем, что keytab файл появился на диске:
После чего копируем полученный keytab файл на сервер с PGHS для того, чтобы внести изменения в auth_config.json
В auth_config.json содержимое keytab файла записывается в закодированном в BASE64 виде. Для этого можно воспользоваться стандартной утилитой base64:
base64 –w 0 pghs.keytab > pghs.base64
После этого вставляем закодированную строку в параметр keytab раздела options схемы User Auth Microsoft Kerberos SSO, а также, если необходимо, указываем параметры для соединения с LDAP сервером для получения групп пользователя.
Далее сохраняем изменения в файле auth_config.json и перезапускаем pghs:
systemctl restart xsquare.pghs.service
Открываем в XRAD нашу страницу авторизации и первым делом меняем статический идентификатор кнопки MS_KSSO:
После этого переходим в процессинг страницы авторизации и добавляем новую схему аутентификации типа Microsoft Kerberos SSO с именем User Auth Microsoft Kerberos SSO :
Изменяем условие отображения схемы на SQL Expression и добавляем код:
$1 = ‘MS_KSSO’
а также указываем переменную REQUEST, которая будет содержать статический идентификатор нажатой кнопки, в качестве входного параметра:
Если сейчас сделать проверку входа по Microsoft Kerberos SSO, мы получим ошибку, так как для полей ввода логина и пароля стоит проверка на ненулевые значения.
Отключим валидацию полей P1_LOGIN и P1_PASSWORD
Для такого сочетания схем аутентификации необходимо создавать кастомную валидацию в разделе процессинг.
Далее входим на компьютере, включенном в домен, под учетной записью Max Belov.
Наиболее вероятно, что мы получим 401 ошибку:
Во-первых, после настройки kerberos в домене, необходимо перезайти на клиентском компьютере, для обновления билета kerberos, а во-вторых, необходимо настроить браузер, так как именно браузер обеспечивает работу механизма Kerberos SSO. Рассмотрим настройку браузера на примере firefox.
Открываем настройки firefox:
about:config
и отфильтруем необходимые нам параметры по строке negotiate
В параметрах network.negotiate-auth.delegation-uris и network.negotiate-auth.trusted-uris необходимо указать uris серверов для которых будет вызываться сквозная аутентификация Kerberos. В нашем случае укажем имя нашего сервера - pghs.
После чего пробуем авторизоваться заново и нас наконец-то ждёт успех!
также можем проверить корректность получения групп пользователя посредством тестовой страницы user_data, которую мы создавали в разделе Microsoft LDAP. Должна быть отображена группа test_group2, так как мы исключили пользователя из test_group1.