Astra Linux SE 1.7.7, ALD Pro 2.5.0., XSQUARE 5.0 будут использованы в данной статье.
Рассмотрим настройку и работу схем аутентификации LDAP и Kerberos SSO в XSQUARE - PGHS на примере домена ALD Pro и ОС Astra Linux Special Edition (ALSE).
Установка Astra Linux SE 1.7.7
Рассмотрим установку Astra Linux SE 1.7.7 с установочного носителя.
После загрузки программы установки необходимо принять лицензионное соглашение
Процесс установки обычно состоит из следующих типовых шагов:
1. Выбираем способ переключения раскладки
2. В настройках сети указываем имя компьютера и домена. На данном этапе можно указать любые, так как мы изменим их при развертывании домена.
3. Указываем имя пользователя-администратора и его пароль
4. Выбираем часовой пояс
5. Выполняем разметку дисков и определяем место для установки ОС
6. После установки базового образа выбираем требуемые компоненты ОС
7. Выбираем необходимый для развертывания контроллера домена максимальный уровень защищенности
8. Устанавливаем и настраиваем системный загрузчик GRUB
9. Дожидаемся завершения установки операционной системы
и осуществляем первичный вход.
Развертывание домена ALD Pro
Подготовка окружения сервера к установке контроллера домена
ALD Pro можно установить на хостах под управлением операционной системы Astra Linux Special Edition. Для установки контроллеров домена и других подсистем требуется максимальный уровень защищенности «Смоленск», а клиентскую часть можно установить в системе с любым уровнем защищённости. Для проверки версии и уровня защищенности операционной системы Astra Linux используйте следующие команды:
cat /etc/astra/build_version
sudo astra-modeswitch getname
Настройка сетевого интерфейса
Перед развертыванием доменной инфраструктуры важно спроектировать топологию локальной сети. Рабочие станции обычно получают настройки динамически от DHCP-сервера, а на контроллерах домена и других подсистемах рекомендуется использовать статические адреса.
Если операционная система была установлена с графическим интерфейсом fly-wm, то в качестве менеджера сетевых подключений устанавливается служба NetworkManager. На серверах ее нужно отключить, это можно сделать с помощью следующих команд:
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
sudo systemctl mask NetworkManager
sudo systemctl status NetworkManager
После выполнения последней команды в терминале должна отобразиться информация о маскировке службы NetworkManager.
После отключения службы NetworkManager необходимо установить сетевые настройки нужно в файлах /etc/network/interfaces и /etc/resolv.conf.
sudo nano /etc/network/interfaces
Пример настройки сетевого интерфейса на контроллере домена для использования статического IP-адреса:
Для применения новых настроек, необходимо перезапустить службу Networking и очистить старое соединение командой flush утилиты ip:
sudo ip addr flush dev eth0
sudo systemctl restart networking
Для возможности обращения к публичным репозиториям следует настроить функцию разрешения имен. Для этого необходимо прописать адрес 77.88.8.8 в /etc/resolv.conf
sudo nano /etc/resolv.conf
После установки этих настроек проверьте подключение к репозиториям Astra Linux:
ping -c 4 dl.astralinux.ru
Настройка имени хоста
Для изменения имени хоста воспользуемся утилитой hostnamectl:
sudo hostnamectl set-hostname dc1.xsquare.local
В имени хоста можно использовать прописные [A-Z] и строчные [a-z] буквы латинского алфавита, цифры [0-9], точку [.] и дефис [-]. Имя хоста должно быть задано в формате полного имени FQDN (Fully Qualified Domain Name), например, dc1.xsquare.local, поэтому команда hostname без параметров должна выдавать полное имя. Данное правило касается имён всех машин домена.
Для того чтобы имя контроллера всегда могло быть преобразовано в IP-адрес вне зависимости от доступности DNS-службы, содержимое файла /etc/hosts нужно изменить следующим образом:
В начало файла нужно добавить строку, в которую вписать статический IP-адрес контроллера, а за ним полное и короткое имя хоста. Первым по списку обязательно должно идти полное имя, т.к. первое значение считается каноническим именем и будет возвращаться командой hostname -f, что требуется для корректной работы скриптов автоматизации. Имена следует указывать в нижнем регистре. Еще крайне важно закомментировать или удалить строку, связывающую имя хоста с IP-адресом локальной петли 127.0.1.1, т.к. эти адреса имеют выше приоритет, а нам крайне важно, чтобы имя хоста разрешалось в локальный адрес, потому что некоторые службы могут прослушивать порты только на этом адресе.
Подключение репозиториев
Для установки продукта из официальных интернет-репозиториев на операционной системе ALSE 1.7.7 в файле /etc/apt/sources.list укажем ссылку на base репозиторий:
deb http://dl.astralinux.ru/astra/frozen/1.7_x86-64/1.7.7/repository-base 1.7_x86-64 main non-free contrib
Для установки продукта ALD Pro 2.5.0 из официальных интернет-репозиториев нужно создать дополнительный файл /etc/apt/sources.list.d/aldpro.list и добавить в него следующую строку:
deb https://dl.astralinux.ru/aldpro/frozen/01/2.5.0/ 1.7_x86-64 main base
Обновление программных пакетов
Следующим шагом необходимо проверить наличие доступных для обновления пакетов и выполнить обновление пакетов в случае их наличия:
sudo apt update
sudo apt list --upgradable
sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confold
Установка пакетов
Для установки пакетов ALD Pro необходимо выполнить следующую команду:
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -q aldpro-mp aldpro-gc aldpro-syncer
После завершения установки необходимо повысить роль сервера до контроллера домена.
Повышение роли сервера до контроллера домена
Повышение роли сервера до контроллера домена выполняется с помощью неинтерактивной утилиты
aldpro-server-install
Примечание: Чтобы пароль не попал в историю команд, вы можете добавить пробел в начало строки или временно отключить запись истории с помощью дополнительной опции history оболочки bash, состояние которой можно изменить с помощью команд set +o / set -o.
Выполним повышение роли сервера до контроллера домена:
set +o history
sudo aldpro-server-install -d xsquare.local -n dc1 --ip 10.150.117.238 --setup_gc --setup_syncer --no-reboot
set -o history
После ввода команды система запросит пароль администратора домена, который будет установлен для доменного пользователя admin и суперпользователя LDAP-каталога cn=Directory Manager. Пароль должен быть не менее 8 символов. После ввода пароля будет произведено развертывание инфраструктуры домена, которое занимает около 30 минут.
После успешного повышения роли сервера до контроллера домена вы можете проверить содержимое файла /etc/resolv.conf и убедиться, что теперь DNS-запросы обрабатываются собственной службой Bind9:
Для того чтобы все изменения вступили в силу требуется перезагрузить сервер:
sudo reboot
После перезагрузки сервера вы сможете войти в систему, используя доменную учетную запись администратора:
Проверить статус доменных служб можно с помощью команды
status утилиты aldproctl:
sudo aldproctl status
Создание пользователей и групп
Теперь создадим тестовые группы и пользователя в домене. Управление доменом осуществляется через веб-интерфейс по адресу созданного домена. Откроем браузер Firefox, автоматический откроется страница входа в систему ALD Pro
Заходим под учетной записью администратора домена и набор средств по управлению доменом
Создадим две тестовые группы test_group1 и test_group2 для этого заходим в оснастку "Пользователи и компьютеры" - "Группы пользователей" и нажимаем кнопку "Новая группа"
Указываем имя группы и выбираем наш домен в качестве подразделения, сохраняем изменения
Аналогичным образом создаем группу test_group2. Далее создадим нового пользователя max belov в той же оснастке "Группы и пользователи"
После того как новый пользователь будет создан, перейдем во вкладку "Группы" этого пользователя и определим его в наши тестовые группы
Создадим также сервисную учетную запись пользователя ldap_reader, с помощью которой будем обращаться к LDAP
Ввод клиентского компьютера в домен
Установка Astra Linux SE 1.8
Введем в наш домен клиентский компьютер на базе ОС Astra Linux SE 1.8. Для этого загружаемся с носителя и в оболочке запускаем установщик.
В Astra Linux 1.8 этапы установки отлично оптимизированы, необходимо всего лишь пройти 4 шага:
1. Принять лицензионное соглашение, выбрать язык установки и уровень защищенности.
2. Установить региональные параметры
3. Выбрать раздел для установки, параметры разметки и компоненты системы
4. Создать пользователя и пароль
Теперь можно приступать к установке.
После установки и перезагрузки входим под учетной записью локального администратора.
Настройка сети на клиентских компьютерах
На пользовательских компьютерах настройка сети выполняется через стандартную службу NetworkManager. Клиентский компьютер уже получил сетевой адрес от DHCP сервера, поэтому необходимо установить только адрес нашего контроллера домена в "Серверы DNS" и наименование домена в "Поисковый домен".
Для установки пакетов необходимо проверить доступность сервера с репозиториями
ping 77.88.8.8
ping dl.astralinux.ru
также проверим версию сборки ОС
cat /etc/astra/build_version
Настройка репозиториев
Для того, чтобы ввести клиентский компьютер в домен ALD Pro необходимо установить клиентскую часть ALD Pro версии 2.5.0 из официальных репозиториев. Пропишем актуальные репозитории в файл /etc/apt/sources.list
sudo nano /etc/apt/sources.list
deb https://dl.astralinux.ru/astra/frozen/1.8_x86-64/1.8.1/repository-main/ 1.8_x86-64 main contrib non-free
Для установки ALD Pro client необходимо создать отдельный список /etc/apt/sources.list.d/aldpro.list
sudo nano /etc/apt/sources.list.d/aldpro.list
со следующим содержимым
deb https://dl.astralinux.ru/aldpro/frozen/01/2.5.0 1.8_x86-64 main base
Далее необходимо обновить индекс и проверить, нет ли пакетов, доступных для обновления. Обновить систему, если таковые будут обнаружены
sudo apt update
sudo apt list --upgradable
sudo apt dist-upgrade -y -o Dpkg::Options::=--force-confnew
Установка пакетов на клиентский компьютер
Теперь система готова к установке клиентской части ALD Pro, для этого необходимо выполнить команду:
sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -q aldpro-client
Для удобства давайте изменим имя компьютера на более короткое astra-1
sudo hostnamectl set-hostname astra-1
Примечание: При вводе в домен компьютера, на котором включен режим замкнутой программной среды, перед запуском скрипта ввода в домен необходимо выполнить перезагрузку компьютера.
Перезагружаем систему
sudo reboot
Для успешного ввода компьютера в домен требуется несколько условий:
- у компьютера должно быть задано уникальное имя, которое еще не используется в домене.
- в качестве DNS-сервера должен быть указан IP-адрес контроллера домена.
- установлен пакет клиентского программного обеспечения aldpro-client.
Проверить уникальность имени в домене можно командой nslookup
Все готово для ввода компьютера в домен. Выполнить ввод pc-1 можно с помощью команд:
set +o history
sudo /opt/rbta/aldpro/client/bin/aldpro-client-installer --domain xsquare.local --account admin --host astra-1 --gui --force --orgunits "ou=xsquare.local,cn=orgunits,cn=accounts,dc=xsquare,dc=local"
set -o history
где
--domain - имя домена
--account - логин администратора домена
--host - имя компьютера в нижнем регистре
--gui - использовать интерактивный режим
--force - продолжить ввод компьютера в домен, даже если в домене для его
имени уже есть учетная запись.
--orgunits - подразделение компьютера. При выполнении без указанного
параметра, компьютеру присваивается корневое подразделение.
После ввода команды система запросит ввести пароль администратора домена.
После успешного ввода в домен перезагружаем систему sudo reboot и входим под доменной учетной записью max belov
Настройка LDAP в PGHS
Перейдем к настройке аутентификации по LDAP в PGHS. XRAD и PGHS развернуты на отдельном сервере под управлением deb base ОС. Для начала проверим возможность подключения по LDAP к ALD Pro с этого компьютера с помощью нашей сервисной учетной записи ldap_reader. Это можно сделать с помощью утилиты ldapsearch, которую можно установить следующим образом:
sudo apt install ldap-utils
Проверим подключение к ALD Pro:
ldapsearch -x -H ldap://10.150.117.238 -D "uid=ldap_reader,cn=users,cn=accounts,dc=xsquare,dc=local" -w "Qweasdzxc123" -b "dc=xsquare,dc=local"
После успешного чтения содержимого каталога ALD Pro, переходим в режим суперпользователя и откроем для редактирования файл auth_config.json в каталоге PGHS: /usr/local/xsquare.pghs/auth_config.json
auth_config.json содержит массив описателей схем аутентификации. Каждая схема состоит из трех элементов:
- name - имя схемы
- type - тип схемы
- options — параметры схемы
После установки PGHS нам доступны шаблоны для каждой поддерживаемой схемы аутентификации.
Отредактируем схему с именем «User Auth LDAP» и типом «ldap» следующим образом:
"name": "User Auth LDAP",
"type": "ldap",
"options": {
"host": "10.150.117.238",
"port": 389,
"base": "DC=xsquare,DC=local",
"encryption": "start_tls",
"bind_dn": "uid=ldap_reader,cn=users,cn=accounts,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, которая реализует аутентификацию по логину и паролю.
Нажмем ПКМ по блоку схем аутентификации и добавим новую схему типа LDAP c именем "User Auth LDAP". Так как схема использует логин и пароль, то укажем источники для данных переменных.
До этого у нас была одна схема User Auth, которая вызывалась всегда. (Условие отображения — Always). Теперь же нам нужно разделить вызов схемы аутентификации в зависимости от того, какая нажата кнопка на форме авторизации. Это можно реализовать с помощью условия отображения типа SQL Expression. После нажатия кнопки значение ее статического идентификатора будет записано в переменную REQUEST. Поэтому в SQL Expression можно указать следующий код:
$1 = 'LDAP_BTN’
А в качестве входного параметра передадим REQUEST.
При этом необходимо изменить статический идентификатор кнопки входа по LDAP на "LDAP_BTN".
Аналогично изменим условия отображения на SQL Expression для схемы User Auth с таким содержимым:
$1 = 'LOG_IN’
Таким образом, при нажатии на кнопку LDAP у нас будет вызываться обработка схемы User Auth LDAP. При нажатии кнопки Войти со статическим идентификатором LOG_IN будет вызываться базовая схема аутентификации.
Сохраняем изменения нашей страницы авторизации и проверим в PGHS вход с помощью схемы LDAP и нашего пользователя max belov.
Успешный вход!
Общая схема работы аутентификации по LDAP описывается следующей последовательностью действий:
- Пользователь вводит логин и пароль, используемые для аутентификации в корпоративной сети;
- PGHS обращается к указанному в настройках LDAP серверу и проверяет наличие пользователя в базе пользователей на корпоративном сервере:
- если пользователя с такими данными в корпоративной сети не существует, то система запрещает вход;
- если пользователь существует, то проверяется его пароль и в случае успеха он получает разрешение на доступ к PGHS и авторизуется.
Что важно: PGHS не хранит пароли корпоративных пользователей, они хранятся на стороне каталога LDAP.
После того, как пользователь успешно авторизовался, имя пользователя записывается в глобальную переменную APP_USER, а группы пользователя - через запятую записываются в переменную APP_USER_GROUPS.
Давайте создадим тестовую страницу user_data и отобразим содержимое этих переменных для нашего пользователя.
Так как наш пользователь max belov состоит в группах test_group1 и test_group2, то создадим на странице два региона типа HTML. В первом - запишем следующий код:
<p>&APP_USER. is a member of the test_group1</p>
В условиях отображения региона выберем SQL Expression со следующим кодом:
$1 LIKE '%test_group1%', а в качестве входного параметра передадим переменную APP_USER_GROUPS.
Аналогичным образом создадим второй регион для проверки test_group2:
сохраним изменения и посмотрим на результат в PGHS. На странице user_data отображаются оба региона:
Теперь зайдем на контроллер домена в оснастку Пользователи и компьютеры ALD Pro, откроем свойства пользователя max belov и удалим пользователя из группы test_group1:
После чего вернемся в PGHS, и перезайдем под пользователем max belov для проверки изменений. Как видно все работает так, как задумывалось.
Настройка 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"). Для этого на контроллере домена dc1 выполним следующую команду:
sudo ipa host-add --ip-address 10.150.117.203 pghs.xsquare.local
Далее добавим новую службу и создадим SPN для нашего веб-сервиса pghs.xsquare.local
sudo ipa service-add HTTP/pghs.xsquare.local
как видно из результатов работы команды - создана новая служба с SPN:
HTTP/pghs.xsquare.local@XSQUARE.LOCAL
Теперь создадим keytab файл для нашего сервиса
sudo ipa-getkeytab -s dc1.xsquare.local -p HTTP/pghs.xsquare.local -k ald.keytab
Параметр -s указывает контроллер домена, к которому происходит запрос на получение ключа.
Параметр -p указывает наименование сервиса, для которого создается keytab.
Параметр -k указывает имя файла, в который будет сохранен созданный keytab
Файл keytab содержит ключи, используемые для аутентификации этого сервиса через Kerberos. Данные ключи необходимо записать в файл auth_config.json сервиса PGHS в закодированном в base64 виде.
Для кодирования keytab файла можно воспользоваться стандартной утилитой base64:
base64 –w 0 ald.keytab > ald_keytab.base64
Копируем полученный файл ald_keytab.base64 на наш сервер с PGHS и копируем его содержимое в буфер обмена.
После этого вставляем скопированную строку в параметр keytab раздела options схемы "User Auth Kerberos SSO", а также, если необходимо, указываем параметры соединения с LDAP сервером для получения групп пользователя.
Сохраняем изменения в файле auth_config.json и перезапускаем pghs:
systemctl restart xsquare.pghs.service
Открываем в XRAD нашу страницу авторизации и первым делом устанавливаем статический идентификатор кнопки KSSO
После этого переходим в процессинг страницы авторизации и добавляем новую схему аутентификации типа Kerberos SSO с именем "User Auth Kerberos SSO"
Изменяем условие отображения схемы на SQL Expression и добавляем код:
$1 = ‘KSSO’
а также указываем переменную REQUEST, которая будет содержать статический идентификатор нажатой кнопки, в качестве входного параметра
Если сейчас сделать проверку входа по Kerberos SSO, мы получим ошибку, так как для полей ввода логина и пароля стоит проверка на ненулевые значения.
Отключим валидацию полей P1_LOGIN и P1_PASSWORD
Для такого сочетания схем аутентификации необходимо создавать кастомную валидацию в разделе процессинг.
Далее входим на компьютере, включенном в домен, под учетной записью max belov. Открываем в браузере http://pghs и пробуем войти по Kerberos SSO. Наиболее вероятно, что мы получим 401 ошибку
Что можно предпринять для решения проблемы:
- настроить браузер, так как именно браузер обеспечивает работу механизма Kerberos SSO
- перезайти на клиентском компьютере, для обновления билета Kerberos
- получить билет Kerberos для нашей службы с помощью команды kinit kinit -kt ald.keytab HTTP/pghs.xsquare.local
Рассмотрим настройку браузера на примере firefox.
Открываем настройки firefox:
about:config
и отфильтруем необходимые нам параметры по строке negotiate
В параметрах network.negotiate-auth.delegation-uris и network.negotiate-auth.trusted-uris необходимо указать uris серверов для которых будет вызываться сквозная аутентификация Kerberos. В нашем случае укажем имя нашего сервера - pghs.
После чего пробуем авторизоваться заново и нас наконец-то ждёт успех!
После ввода клиентского компьютера в домен в браузере firefox прописываются настройки для всей доменной зоны, поэтому аутентификации по Kerberos должна работать, если обратиться по полному имени сервиса http://pghs.xsquare.local, но в большинстве случаев это неудобно. В этом случае также можно выставить в true флаг network.negotiate-auth.allow-non-fqdn, который позволяет аутентифицироваться по неполному имени (FQDN).
Также проверим корректность получения групп пользователя посредством тестовой страницы user_data, которую мы создавали в разделе LDAP. Должна быть отображена группа test_group2, так как мы исключили пользователя из test_group1.
На этом - всё, успехов!