В данной статье будут использованы РЕД ОС 8 x86_64 (20241206), РЕД АДМ 2.0.0, XSQUARE 5.0
Рассмотрим настройку и работу схем аутентификации LDAP и Kerberos SSO в XSQUARE - PGHS на примере домена РЕД АДМ и ОС семейства РЕД ОС 8.
Для развертывания тестового домена xsquare.adm нам понадобится:
- Машина с РЕД ОС 8 Сервер для контроллера домена
- Машина с РЕД ОС 8 Сервер для РЕД АДМ
- Машина с РЕД ОС 8 Сервер для XSQUARE - PGHS + XRAD
- Машина с РЕД ОС 8 Рабочая станция для ввода в домен в качестве клиентской машины.
Установка РЕД ОС 8
Установка РЕД ОС 8 Сервер
Рассмотрим установку РЕД ОС 8 Сервер с установочного носителя.
После загрузки программы установки выбираем языковые параметры
Определяем место установки ОС
и при необходимости выполняем разметку дисков
В разделе выбор программ указываем в качестве базового окружения Сервер минимальный
Включаем пользователя root и задаем ему пароль Qweasdzxc123!!!
создаем пользователя red с паролем Qweasdzxc!
Начинаем установку
По окончанию установки - перезагружаемся, входим под учетной записью root и обновляем нашу систему с помощью команды
dnf makecache && upgrade -y
Установка РЕД ОС 8 Рабочая станция
Установка РЕД ОС 8 Рабочая станция происходит аналогичным образом, с той лишь разницей, что базовое окружение оставляем по умолчанию - "Рабочая станция с графическим окружением"
Развертывание домена РЕД АДМ
Итак, мы имеем две машины с РЕД ОС 8 Сервер с последними обновлениями
10.150.117.213 - сервер с РЕД АДМ
10.150.117.215 - сервер на котором будет разворачиваться контроллер домена.
Для удобства на обеих системах - одинаковые учетные записи (root и red).
Установка РЕД АДМ
Загружаем из центра загрузок файл redadm-enterprise-2.0.0-1.red80.x86_64.rpm и копируем его на сервер 10.150.117.213 в удобный каталог, например /tmp. Запускаем установку с помощью команды
dnf install -y redadm-enterprise-2.0.0-1.red80.x86_64.rpm
после успешного завершения установки необходимо проверить статус сервисов
systemctl status redadm.service rabbitmq-server.service \
redadm-celery-worker.service redadm-celery-beat.service nginx.service \
memcached.service
Далее переходим на рабочую станцию, запускаем браузер, открываем страницу с адресом нашего сервера РЕД АДМ https://10.150.117.213 для первоначальной настройки РЕД АДМ. Принимаем лицензионное соглашение и вводим лицензионный ключ.
Указываем учетную запись root от сервера РЕД АДМ
В разделе "Параметры сети" необходимо выбрать ручные настройки и добавить в качестве первичного DNS-сервера адрес нашего будущего контроллера домена.
Далее указываем путь и учетную запись для установки базы данных.
Следующим этапом развертываем контроллер домена, для этого указываем адрес нашего сервера 10.150.117.215 и параметры привилегированного пользователя на данном сервере.
Параметры сети можно оставить без изменений, так как РЕД АДМ настроит всё сам
Определяем ключевые параметры нашего домена:
имя домена, пароль учетной записи администратора домена (administrator) и имя контроллера домена, а также параметры сервисной учетной записи.
После успешного развертывания домена нам необходимо ввести сервер с РЕД АДМ в домен, но перед этим необходимо убедиться в доступности нашего домена. Это можно сделать с помощью команды
nslookup xsquare.adm
Наш домен недоступен, так как в РЕД ОС 8 необходимо отключить использование DNSStubListener. Это можно сделать установив данный параметр в "no" в файле /etc/systemd/resolved.conf
Для применения изменений перезапускаем сервис systemd-resolved
systemctl restart systemd-resolved.service
После чего повторно проверяем доступность домена через nslookup
Возвращаемся на рабочую станцию и указываем имя сервера РЕД АДМ под которым данная машина будет введена в домен, а также учетную запись с правами для ввода в домен (administrator)
По окончанию установки РЕД АДМ входим в систему управления под учетной записью администратора домена
Создание пользователей и групп
Теперь создадим тестового пользователя и группы в домене. Для этого переходим в подраздел "Пользователи" раздела "Управление объектами домена" и выбираем "Создать". После чего вводим параметры нового пользователя, у нас это будет max redov.
Таким же образом создадим пользователя ldap reader, который будет использоваться PGHS для чтения каталога по LDAP
Переходим в подраздел "Группы" и создаем две тестовые группы test_group1 и test_group2
После чего выбираем каждую новую группу и добавляем нашего пользователя max redov в каждую из них.
Ввод клиентского компьютера в домен
Теперь введем наш клиентский компьютер 10.150.117.218 в домен, для этого перейдем в раздел "Компьютеры" - "Недоверенные компьютеры" и выберем действие "Подключить вручную". Вводим IP-адрес нашего клиентского компьютера и нажимаем "Далее".
Вводим логин и пароль привилегированного пользователя на клиентской машине (но не root), а также логин и пароль администратора домена.
Также необходимо задать именование компьютера в домене, так как РЕД АДМ не сможет ввести в домен компьютер с именем localhost.localdomain. Дополнительно выбираем "Сменить DNS на компьютерах" и указываем адрес нашего контроллера домена.
ПРИМЕЧАНИЕ: для ввода в домен машины с РЕД ОС 8 необходимо отключать DNSStubListener в файле /etc/systemd/resolved.conf
Настройка LDAP в PGHS
Перейдем к самому главному - настройке аутентификации по LDAP в PGHS. XRAD и PGHS развернуты на отдельной рабочей станции РЕД ОС 8.
Для начала проверим возможность подключения по LDAP к нашему домену с помощью нашей сервисной учетной записи ldap_reader. Это можно сделать с помощью утилиты ldapsearch:
ldapsearch -x -H ldap://10.150.117.215 -D "cn=ldap reader, cn=Users, dc=xsquare, dc=adm" -w "Password!" -b "dc=xsquare,dc=adm"
Получаем ответ, что подключение без шифрования не поддерживается
Поэтому добавляем ключ -Z для включения режима start_tls
ldapsearch прерывает работу, так как не может верифицировать SSL сертификат, поэтому укажем параметр LDAPTLS_REQCERT=never для того, чтобы игнорировать проверку сертификатов, после чего получаем содержимое каталога
Теперь открываем рабочую станцию 10.150.117.233, где развернуты PGHS и XRAD, переходим в каталог /usr/local/xsquare.pghs и открываем файл auth_config.json для редактирования.
auth_config.json содержит массив описателей схем аутентификации. Каждая схема состоит из трех элементов:
- name - имя схемы
- type - тип схемы
- options — параметры схемы
После установки PGHS нам доступны шаблоны для каждой поддерживаемой схемы аутентификации.
Так как домен РЕД АДМ работает в режиме Microsoft Active Directory, то отредактируем схему с именем «User Auth Microsoft LDAP» и типом «microsoft_ldap» следующим образом:
"name": "User Auth Microsoft LDAP",
"type": "microsoft_ldap",
"options": {
"host": "10.150.117.215",
"port": 389,
"base": "DC=xsquare,DC=adm",
"encryption": "start_tls",
"bind_dn": "cn=ldap reader,cn=Users,dc=xsquare,dc=adm",
"password": "Password!",
"request_user_groups": true
}
где
- host — адрес нашего контроллера домена
- base — точка входа в домен, мы указали корень домена xsquare.local
- bind_dn — имя пользователя для подключения по LDAP
- password — пароль нашего пользователя ldap_reader
Мы будем тестировать подключение с шифрованием на порту 389. Сохраняем изменения и перезапускаем службу PGHS:
systemctl restart xsquare.pghs.service
Далее заходим в XRAD Builder. Для использования схем аутентификации необходимо создать список схем, состоящих из имени и типа, которые будут использоваться в XRAD при создании страниц, а затем в PGHS при обработке. Этот список по сути является отображением списка из файла auth_config.json.
Перейдем к настройке первой страницы авторизации. Если мы перейдем в процессинг страницы авторизации, то увидим здесь одну единственную схему аутентификации с именем User Auth, которая реализует аутентификацию по логину и паролю.
Нажмем ПКМ по блоку схем аутентификации и добавим новую схему типа Microsoft LDAP c именем "User Auth Microsoft LDAP". Так как схема использует логин и пароль, то укажем источники для данных переменных.
До этого у нас была одна схема User Auth, которая вызывалась всегда (Условие отображения — Always). Теперь нам нужно разделить вызов схемы аутентификации в зависимости от того, какая нажата кнопка на форме авторизации. Это можно реализовать с помощью условия отображения типа SQL Expression. После нажатия кнопки значение ее статического идентификатора будет записано в переменную REQUEST. Поэтому в SQL Expression можно указать следующий код:
$1 = 'MS_LDAP_BTN’
А в качестве входного параметра передадим REQUEST.
При этом необходимо изменить статический идентификатор кнопки входа по LDAP на "MS_LDAP_BTN".
Аналогично изменим условия отображения на SQL Expression для схемы User Auth с таким содержимым:
$1 = 'LOG_IN’
Таким образом, при нажатии на кнопку "Microsoft LDAP" у нас будет вызываться обработка схемы User Auth Microsoft LDAP. При нажатии кнопки "Войти" со статическим идентификатором LOG_IN будет вызываться базовая схема аутентификации.
Сохраняем изменения нашей страницы авторизации и проверим в PGHS вход с помощью схемы LDAP и нашего пользователя max redov.
Успешный вход!
Общая схема работы аутентификации по LDAP описывается следующей последовательностью действий:
- Пользователь вводит логин и пароль, используемые для аутентификации в корпоративной сети;
- PGHS обращается к указанному в настройках LDAP серверу и проверяет наличие пользователя в базе пользователей на корпоративном сервере:
- если пользователя с такими данными в корпоративной сети не существует, то система запрещает вход;
- если пользователь существует, то проверяется его пароль и в случае успеха он получает разрешение на доступ к PGHS и авторизуется.
Что важно: PGHS не хранит пароли корпоративных пользователей, они хранятся на стороне каталога LDAP.
После того, как пользователь успешно авторизовался, имя пользователя записывается в глобальную переменную APP_USER, а группы пользователя - через запятую записываются в переменную APP_USER_GROUPS.
Давайте создадим тестовую страницу user_data и отобразим содержимое этих переменных для нашего пользователя.
Так как наш пользователь max redov состоит в группах test_group1 и test_group2, то создадим на странице два региона типа HTML. В первом - запишем следующий код:
<p>&APP_USER. состоит в группе test_group1</p>
В условиях отображения региона выберем SQL Expression со следующим кодом:
$1 LIKE '%test_group1%', а в качестве входного параметра передадим переменную APP_USER_GROUPS.
Аналогичным образом создадим второй регион для проверки test_group2
сохраним изменения и проверим результат в PGHS. На странице user_data отображаются оба региона:
Теперь зайдем в РЕД АДМ в оснастку Пользователи, откроем свойство "Член групп" пользователя max redov и удалим пользователя из группы test_group1
После чего вернемся в PGHS, и перезайдем под пользователем max redov для проверки изменений. Как видно все работает так, как задумывалось.
Настройка Kerberos SSO в PGHS
PGHS поддерживает беспарольную аутентификацию с помощью технологии единого входа Single Sign-On на базе протокола Kerberos. Рассмотрим настройку прозрачной аутентификации Kerberos SSO в PGHS.
Общий алгоритм настройки Kerberos SSO сводится к нескольким шагам:
- Добавить службу, создав Service Principal Name
- Сгенерировать keytab файл
- Сконфигурировать PGHS
Service Principal Name (SPN) – это уникальный идентификатор экземпляра службы. В нашем случае для контроллера домена такой службой выступает сервер c PGHS.
В первую очередь необходимо обеспечить доступность сервера с PGHS для всех клиентов домена по определенному имени (в нашем случае выберем имя "pghs"). Достичь этого можно различными способами, но наиболее логичным является создание A-записи в DNS. Для работы с DNS из РЕД АДМ необходимо установить менеджер управления контроллером домена. Для этого в разделе "Управление доменом" выбираем подраздел "Контроллеры домена". Выбираем наш контроллер домена dc1 и нажимаем "Установить менеджер", после чего нужно ввести параметры учетной записи привилегированного пользователя на КД и начать установку.
После установки в разделе "Управление доменом" должен появиться подраздел DNS. Заходим в Зоны прямого просмотра и выбираем зону xsquare.adm, после чего нажимаем "Создать запись". В открывшемся окне настраиваем параметры записи:
тип записи - А
название - pghs
IP-адрес - 10.150.117.233
После создания записи, проверим в браузере доступность сервера по новому имени
Имя сервисной службы SPN привязывается к учетной записи компьютера или пользователя. Рекомендуется создать отдельную учетную запись сервисного пользователя с определёнными параметрами:
- запретить смену пароля
- не ограничивать срок действия пароля
Это важно, так как при смене пароля или истечении срока действия придется заново генерировать keytab файлы привязанные к этому пользователю.
Поэтому создадим пользователя sso_user
Теперь создадим SPN, РЕД АДМ позволяет сделать это в подразделе "Глобальная конфигурация" раздела "Управление доменом". Выбираем вкладку SPN и нажимаем "Добавить". Вводим имя SPN по указанному шаблону: HTTP/pghs.xsquare.adm и привязываем к пользователю sso_user.
Введем в поле для поиска * и отобразим все SPN в домене, в том числе вновь добавленную для сервиса PGHS.
К сожалению, в РЕД АДМ как и при использовании напрямую утилиты samba-tools при добавлении SPN не происходит изменение userPrincipalName (имя входа пользователя) в свойствах пользователя на SPN. Поэтому, чтобы избежать ошибки "kinit: Client not found in Kerberos database while getting initial credentials" изменим этот параметр вручную. Для этого открываем свойства пользователя sso_user, переходим на вкладку "Учетная запись" и меняем параметр "Имя для входа" с sso_user@xsquare.adm на HTTP/pghs.xsquare.adm@XSQUARE.ADM
Теперь создадим keytab файл для нашего сервиса, для этого переходим на контроллер домена и под учетной записью администратора домена генерируем файл с помощью команды
samba-tool domain exportkeytab /tmp/pghs.keytab --principal=HTTP/pghs.xsquare.adm
Проверим список ключей в сгенерированном keytab-файле с помощью команды
klist -ke /tmp/pghs.keytab
Для проверки keytab-файла необходима настроенная Kerberos-аутентификация, проверим это с помощью команды
kinit administrator
Вводим пароль администратора и получаем билет
Теперь попробуем зарегистрироваться с помощью нашего keytab-файла:
kinit -5 -V -k -t /tmp/pghs.keytab HTTP/pghs.xsquare.adm
Отлично! Мы имеем корректный keytab-файл, который позволяет аутентифицироваться, копируем его на сервер с PGHS.
Содержимое keytab-файла необходимо записать в файл auth_config.json сервиса PGHS в закодированном в base64 виде.
Для кодирования keytab файла можно воспользоваться стандартной утилитой base64:
base64 –w 0 /tmp/pghs.keytab > pghs_keytab.b64
Копируем закодированное содержимое в буфер обмена. Открываем для редактирования файл auth_config.json и вставляем скопированную строку в параметр keytab раздела options схемы "User Auth Microsoft Kerberos SSO", а также, если необходимо, указываем параметры соединения с LDAP сервером для получения групп пользователя.
Сохраняем файл auth_config.json и перезапускаем PGHS
systemctl restart xsquare.pghs.service
Открываем в XRAD нашу страницу авторизации, переходим в процессинг и создаем новую схему аутентификации с типом Microsoft Kerberos SSO и именем User Auth Microsoft Kerberos SSO
Изменяем условие отображения схемы на SQL Expression и добавляем код:
$1 = ‘KSSO’
а также указываем переменную REQUEST, которая будет содержать статический идентификатор нажатой кнопки, в качестве входного параметра
Если сейчас сделать проверку входа по кнопке Microsoft Kerberos SSO, мы получим ошибку, так как для полей ввода логина и пароля стоит проверка на ненулевые значения.
Отключим валидацию полей P1_LOGIN и P1_PASSWORD (необходимо создавать кастомную валидацию в разделе процессинг), а также изменим статический идентификатор кнопки Microsoft Kerberos SSO на KSSO
Все готово! Логинимся под учетной записью max redov на клиенсткой машине, открываем в браузере страницу сервиса по имени pghs и пробуем аутентифицироваться
К сожалению, мы не настроили браузер для осуществления kerberos-аутентификации. Настроим Chromium, который является дефолтным браузером в РЕД ОС. Для этого под учетной записью root создаем каталог managed
mkdir -p /etc/chromium/policies/managed
и создаем в нем новый файл xsquare.adm.json c политиками
{
"AuthServerAllowlist": "*.xsquare.adm",
"AuthNegotiateDelegateAllowlist": "*.xsquare.adm"
}
данные политики разрешают осуществлять kerberos-аутентфикацию для любых сервисов в домене xsquare.adm. Сохраняем данный файл и открываем в chromium страницу chrome://policy, чтобы проверить, что наши политики корректно применились.
После чего пробуем аутентифицироваться еще раз. Рассмотрим еще одну возможную ошибку на пути kerberos аутентификации - отсутствие билета для нашего пользователя. Открываем терминал и получаем билет для max.redov с помощью команды
kinit max.redov
После этого пробуем аутентифицироваться и нас точно ждет успех!
Также проверим корректность получения групп пользователя посредством тестовой страницы user_data, которую мы создавали в разделе LDAP. Должна быть отображена группа test_group2, так как мы исключили пользователя из test_group1.
На этом - всё, успехов!