Модуль 4. Работа службы каталога ALD Pro

Введение

В этом модуле мы рассмотрим общую архитектуру службы каталога ALD Pro, устройство LDAP-каталога, функции KDC-сервера и даже узнаем, зачем на контроллерах домена FreeIPA устанавливается Samba.

Крайне полезными будут практические материалы по управлению компонентами системы и информация про идентификаторы безопасности.

Архитектура службы каталога ALD Pro

Система ALD Pro (Astra Linux Directory Pro) — это набор сетевых служб сервера Astra Linux для организации централизованного управления ИТ-инфраструктурой на базе широко известных компонентов с открытым исходным кодом.

В основе системы лежит служба каталога FreeIPA, которая централизованно хранит информацию о пользователях, компьютерах и сервисных учётных записях. Доступ к этим данным осуществляется через открытые протоколы.

Система ALD Pro отвечает за работу службы NTP в домене и расширяет возможности службы каталога FreeIPA благодаря интеграции с системой конфигурирования SaltStack. Эта интеграция позволяет централизованно настраивать рабочие станции в домене, применяя концепцию групповых политик.

Мы уже разобрали работу служб NTP, DNS и портала управления ALD Pro. Сегодня мы продолжим знакомство с архитектурой и рассмотрим взаимосвязь таких компонентов, как 389 Directory Server, MIT Kerberos, Samba. Общая архитектура решения представлена на рис. 235.

../_images/aldpro_mod4_image4.png

рис. 235 Архитектура службы каталога

Ключевым компонентом FreeIPA является LDAP-каталог 389 Directory Server, который представляет собой специализированную нереляционную систему хранения и управления данными. Чтобы интегрировать компоненты системы с LDAP-каталогом разработчики FreeIPA создали порядка 15 специальных плагинов, например, для управления топологией, динамического назначения номеров идентификаторов безопасности и др.

Структура LDAP-каталога подобна файловой системе, где папкам соответствуют записи, а файлам – атрибуты записей. Подробнее об этом мы расскажем в одном из следующих разделов.

За работу каталога могут отвечать десятки и даже сотни серверов, которые объединяются в кластер, обеспечивающий устойчивость к разделению (англ. Partition Tolerance) и согласованность данных в конечном итоге (анг. Eventually Consistent) по теореме CAP.

Внешние клиенты, например, агент групповых политик Standalone Salt-minion, взаимодействуют с контроллерами домена по протоколу LDAP на портах 389/TCP и 636/TCP (LDAP + TLS). Локальные компоненты, такие как KDC, DNS, Samba, обращаются к базе LDAP через специальные плагины по LDAPI, используя unix-сокет (англ. LDAP over IPC, LDAPI), что повышает безопасность и сокращает накладные расходы на сетевой стек.

Сервер FreeIPA

Название службы каталога FreeIPA является акронимом от Free Identity, Policy and Audit, что указывает на основные приоритеты в развитии продукта — централизованное управление идентификацией, политиками и аудитом.

Также как в 90-е годы Microsoft заимствовала из UNIX-мира технологии DNS, Kerberos, LDAP для построения своего Windows-домена, команда разработчиков проекта FreeIPA ставит сейчас своей целью заимствовать у Microsoft лучшие бизнес-практики для построения Linux-домена. Именно по этой причине система унаследовала от Active Directory многие концепции, такие как:

  • Домен — совокупность пользователей, компьютеров и других сетевых объектов, информация о которых хранится в общей базе данных.

  • Контроллер домена — сервер, обеспечивающий работу распределенной базы данных домена (службы каталога) и предоставляющий всем участникам сервисы аутентификации и авторизации.

  • Доменный пользователь — пользователь, которому создана учетная запись в домене, с помощью которой он может проходить аутентификацию на контроллерах домена и получать авторизованный доступ при обращении к доменным сервисам.

  • Доменный компьютер — компьютер, которому создана учетная запись в домене, с помощью которой он может получать информацию из LDAP-каталога и проверять аутентичность пользователей по протоколу Kerberos V5.

  • Керберизированный сервис — сетевое приложение, которому создана учетная запись в домене, которую он может использовать как компьютер для получения информации из LDAP-каталога и проверки аутентичности пользователей по протоколу Kerberos V5.

Вместе с тем некоторые функции реализованы иначе, чем в AD, или даже не планируются к реализации. Например, в части централизованного управления рабочими станциями FreeIPA предлагает хороший базовый набор политик безопасности, но все остальные функции предлагает решать с помощью отдельных систем конфигурирования. Поэтому в продукте ALD Pro эта потребность закрыта интеграцией с одной из лучших систем управления конфигурациями SaltStack.

В состав компонентов FreeIPA входят:

  • Сервер LDAP на базе 389 Directory Server.

  • Служба для управления DNS на базе BIND9.

  • Единая точка входа по протоколу Kerberos V5 на базе MIT Kerberos KDC.

  • Дополнительно с помощью Samba AD может быть активирована интеграция с Active Directory (в ALD Pro компонент устанавливается по умолчанию).

  • Дополнительно с помощью DogTag может быть реализована работа с сертификатами (в ALD Pro планируется реализация внешних плагинов к PKI Proxy для интеграции со сторонними удостоверяющими центрами).

Управление сервером FreeIPA

Для управления службой каталога можно использовать различные инструменты, которые взаимодействуют с ней через программные интерфейсы JSON-RPC или XML-RPC, которыми она оборачивает свои компоненты, или напрямую через LDAP. Основными клиентскими интерфейсами являются:

  • Веб-портал, который доступен по адресу https://<fqdn имя контроллера>/ipa/ui/ и работает через JSON-RPC.

    Вы можете обращаться к этому инструменту для настройки тех функций, которые не заявлены в продукте ALD Pro, но поддерживаются компонентом. Например, для настройки правил автоматического монтирования сетевых дисков.

  • Утилита ipactl, используется для управления службами FreeIPA, их корректного включения, выключения и перезапуска.

  • Утилита командной строки ipa, которая установлена на всех доменных компьютерах и работает через JSON-RPC. Утилита имеет собственный механизм автоматического обнаружения контроллеров и поддерживает прозрачную Kerberos-аутентификацию.

  • Дополнительные утилиты, такие как ipa-backup, ipa-restore, ipa-getkeytab и др.

Веб-интерфейс управления

Мы не будем подробно останавливаться на веб-интерфейсе и скажем только, что он есть, и вы можете получить к нему доступ, например, по адресу https://dc-1.ald.company.lan/ipa/ui.

../_images/aldpro_mod4_image5.png

рис. 236 Интерфейс веб-портала FreeIPA

Для входа на портал по умолчанию используется прозрачная Kerberos-аутентификация, поэтому, если у вас в связке ключей есть действующий TGT-билет, то вы попадете в систему без необходимости ввода пароля.

В горизонтальном меню представлено пять вкладок:

  • Идентификация – управление объектами каталога (пользователи, узлы, службы, группы).

  • Политика – политики паролей, билетов Kerberos, HBAC-правила, SUDO-правила, Parsec (интеграция с функциями мандатного контроля от Astra Linux).

  • Аутентификация – управление аутентификацией через серверы RADIUS, одноразовые ключи и сертификаты.

  • Сетевые службы – управление службой DNS и автомонтированием папок.

  • IPA-сервер – управление топологией репликации, настройка ролей, диапазонов идентификаторов и др. параметров.

Утилита ipactl

Все компоненты контроллера домена представляют собой службы, которыми можно управлять через утилиту systemctl. Например, вы можете перезапустить веб-сервер командой systemctl restart apache2.service. Но, учитывая, что запуск и выключение служб требуется выполнять в определенном порядке, была разработана специальная утилита ipactl, которая позволяет управлять всеми этими службами сразу.

Основные команды утилиты:

  • Команда ipactl start – запуск.

  • Команда ipactl stop – остановка.

  • Команда ipactl restart – перезапуск.

  • Команда ipactl status – вывод статуса.

Для выполнения команд нужно обладать привилегиями суперпользователя, поэтому добавляйте к ним sudo, например:

sudo ipactl status

Результат выполнения команды:

admin@dc-1:~$ sudo ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

Утилита ipa

Утилита ipa написана на языке Python и входит в состав пакета freeipa-client, который устанавливается на всех компьютерах в домене. Для ее использования ничего дополнительно устанавливать не требуется.

Для взаимодействия с сервером утилита отправляет запросы по протоколу JSON-RPC. Аутентификация выполняется по протоколу Kerberos V5 с использованием билетов из связки ключей текущего пользователя.

Чтобы проверить, от имени какого пользователя выполняются запросы на сервере, можно использовать команду ipa user-find с параметром --whoami. После выполнения запроса в связке ключей должен появиться билет на доступ к HTTP-службе того контроллера, через который был обработан запрос.

ipa user-find --whoami

Результат выполнения команды:

admin@dc-1:~$ ipa user-find --whoami
---------------------
найден 1 пользователь
---------------------
  Имя учётной записи пользователя: admin
  Фамилия: Administrator
  Домашний каталог: /home/admin
  Оболочка входа: /bin/bash
  Псевдоним учётной записи: admin@ALD.COMPANY.LAN, root@ALD.COMPANY.LAN
  UID: 491200000
  ID группы: 491200000
  Учётная запись отключена: False
---------------------------------
Количество возвращённых записей 1
---------------------------------

Параметры для бэкенда и для клиентской части определяются в общем конфигурационном файле /etc/ipa/default.conf. На контроллере домена содержимое файла имеет следующий вид:

admin@dc-1:~$ cat /etc/ipa/default.conf
[global]
host = dc-1.ald.company.lan
basedn = dc=ald,dc=company,dc=lan
realm = ALD.COMPANY.LAN
domain = ald.company.lan
xmlrpc_uri = https://dc-1.ald.company.lan/ipa/xml
ldap_uri = ldapi://%2Frun%2Fslapd-ALD-COMPANY-LAN.socket
mode = production
enable_ra = False
ra_plugin = None

На обычном доменном компьютере этот файл выглядит немного иначе:

admin@pc-1:~$ cat /etc/ipa/default.conf
[global]
basedn = dc=ald,dc=company,dc=lan
realm = ALD.COMPANY.LAN
domain = ald.company.lan
server = dc-1.ald.company.lan
host = pc-1.ald.company.lan
xmlrpc_uri = https://dc-1.ald.company.lan/ipa/xml
enable_ra = False

Параметры, актуальные больше для клиента:

  • xmlrpc_uri — адрес сервера FreeIPA, к которому должен подключаться клиент для взаимодействия с доменом. По умолчанию в параметрах xmlrpc_uri и server будет указан адрес того контроллера, через который компьютер был присоединен к домену.

    Этот адрес используется как утилитой ipa, так и дополнительными инструментами, например, утилитой ipa-getcert и др. Обратите также внимание, что современные версии клиентских приложений используют JSON-RPC, поэтому заменяют в адресе значение /ipa/xml на /ipa/json.

    Если параметр xmlrpc_uri не задан, то клиент попытается сформировать URI-адрес, используя значение параметра server.

  • server — полное имя (FQDN) сервера FreeIPA для взаимодействия клиента через XML-RPC. Этот параметр считается устаревшим и используется, только если не задан параметр xmlrpc_uri.

  • domain — полное имя домена для автоматического обнаружения активного контроллера по SRV-записям вида _ldap._tcp.ald.company.lan. Клиент переходит на механизм автоматического обнаружения сервисов, только если параметры xmlrpc_uri и server не будут заданы явным образом.

    Если параметр domain не задан, то клиент попытается взять вместо него значение параметра realm в нижнем регистре символов.

  • enable_ra — указывает, действует ли центр сертификации (англ. Certification Authority, CA) в качестве агента центра регистрации (англ. Registration Authority), как в случае интеграции с DogTag. В продукте ALD Pro центр сертификации DogTag не используется, поэтому параметр имеет значение False.

Параметры, актуальные больше для сервера:

  • host — имя хоста, которое используется при формировании URL-адресов.

  • realm — область Kerberos, которая используется, например, для формирования имени службы dirsrv@ALD-COMPANY-LAN. Параметр критичен для сервера, а на клиенте значение realm может быть использовано вместо domain, если этот параметр не будет задан явным образом.

  • ldap_uri — адрес LDAP-сервера, который используется бэкендом API, поэтому данная настройка задается только на контроллерах домена. По умолчанию бэкенд использует протокол LDAPI для обращения к серверу через UNIX-сокет.

  • basedn — отличительное имя (DN) базовой записи для поиска записей в LDAP-каталоге. Если параметр не задан, то basedn формируется по значению параметра domain. Параметр критичен для сервера, а на клиенте используется, например, утилитой ipa-client-automount.

  • mode — определяет режим работы сервера, поддерживаются значения production и development. В продуктивном режиме, например, для повышения производительности не выполняются некоторые дополнительные самопроверки.

  • ra_plugin — определяет название плагина для взаимодействия бэкенда с центром регистрации (англ. Registration Authority), как в случае интеграции с DogTag. В продукте ALD Pro центр сертификации DogTag не используется, поэтому параметр имеет значение None.

Как вы могли заметить, для обеспечения быстрой работы и высокой отказоустойчивости утилита ipa использует довольно сложный порядок выбора активного сервера FreeIPA:

  1. В первую очередь утилита ipa проверяет доступность того сервера, который указан в параметре xmlrpc_uri.

  2. Если параметр xmlrpc_uri не задан, то утилита формирует URI по значению параметра server и проверяет доступность API по этому адресу.

  3. Если параметр server не задан, то утилита выполняет автоматическое обнаружение сервера через DNS по SRV-записям вида _ldap._tcp.<полное имя домена>, используя в качестве полного имени домена значение параметра domain.

  4. Если параметр domain не задан, то вместо него утилита попробует использовать значение realm в нижнем регистре символов.

Доступность сервера FreeIPA можно проверить командой ping. С помощью ключа -d можно запросить вывод дополнительной отладочной информации:

ipa -d ping

Результат выполнения команды:

 admin@dc-1:~$ ipa -d ping
 ...
 ipa: DEBUG: importing plugin module ipaclient.plugins.vault
 ipa: DEBUG: failed to find session_cookie in persistent storage for principal 'admin@ALD.COMPANY.LAN'
 ipa: DEBUG: trying https://dc-1.ald.company.lan/ipa/json
 ipa: DEBUG: New HTTP connection (dc-1.ald.company.lan)
 ipa: DEBUG: received Set-Cookie (<class 'list'>)'['ipa_session=MagBearerToken=9Q6FI...ZMCHCKsExQ%3d%3d;path=/ipa;httponly;secure;']'
 ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=9Q6FINpIhPV...MCHCKsExQ%3d%3d;' for principal admin@ALD.COMPANY.LAN
 ipa: DEBUG: Created connection context.rpcclient_140561608787896
 ipa: DEBUG: raw: ping(version='2.239')
 ipa: DEBUG: ping(version='2.239')
 ipa: DEBUG: [try 1]: Forwarding 'ping/1' to json server 'https://dc-1.ald.company.lan/ipa/json'
 ipa: DEBUG: HTTP connection keep-alive (dc-1.ald.company.lan)
 ipa: DEBUG: received Set-Cookie (<class 'list'>)'['ipa_session=MagBearerToken=0r2cXXlnOKMtVYcu....%3d%3d;path=/ipa;httponly;secure;']'
 ipa: DEBUG: storing cookie 'ipa_session=MagBearerToken=0r2...Q%3d%3d;' for principal admin@ALD.COMPANY.LAN
 ipa: DEBUG: Destroyed connection context.rpcclient_140561608787896
 --------------------------------------------
 IPA server version 4.8.10. API version 2.239
 --------------------------------------------

Прокомментируем некоторые строки:

  • ipa: DEBUG — это отладочные данные, из которых можно извлечь много полезной информации о порядке обработки запроса;

  • ipa: DEBUG: trying https://dc-1.ald.company.lan/ipa/json — указывает, на какой URL-адрес был направлен текущий запрос;

  • ipa: DEBUG: raw: ping(version=“2.239“) — указывает используемую версию API и выполняемую команду.

Для получения расширенной информации по командам утилиты и их параметрам можно воспользоваться командой ipa help topics. Для выхода из справки нажмите клавишу q, как при работе с утилитой less.

ipa help topics

Результат выполнения команды:

admin@dc-1:~$ ipa help topics
dnarange                        dnarange
dns                             Система доменных имён (DNS)
domainlevel                     Повысить уровень домена IPA.
group                           Groups of users
hbac                            Команды управления доступом на основе узла
hbactest                        Simulate use of Host-based access controls
host                            Узлы/Компьютеры
hostgroup                       Groups of hosts.
idrange                         Диапазоны идентификаторов
...

Чтобы просмотреть справку по управлению пользователями, введите команду:

ipa help user

Результат выполнения команды:

admin@dc-1:~$ ipa help user
Пользователи

Управление записями пользователей. Все пользователи являются POSIX-пользователями.

IPA поддерживает широкий спектр форматов имён пользователей, но следует учитывать те ограничения, которые могут существовать в конкретной среде.
...

Утилита IPA имеет большое количество команд. В рамках модуля мы рассмотрим только управление пользователями, см. табл. 15, но вы можете обратиться также к более полному курсу по автоматизации средствами утилиты ipa.

табл. 15 Список команд утилиты IPA для управления пользователями

Команда

Выполняемое действие

ipa user-add

Добавить нового пользователя. Если вы хотите добавить нового «неподтвержденного» пользователя, воспользуйтесь командой ipa stageuser-add.

ipa user-add-manager

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

ipa user-add-principal

Добавить новый псевдоним Kerberos к учетной записи пользователя.

ipa user-del

Удалить пользователя. По умолчанию используется --no-preserve, поэтому запись удаляется безвозвратно. Если использовать ключ --preserve, то записи будут перемещены в контейнер cn=deleted users,cn=accounts,cn=provisioning — в ALD Pro называется «Корзина», а в интерфейсе FreeIPA — «Хранимые пользователи». Если учетная запись уже находится в корзине, она может быть окончательно удалена повторным выполнением команды ipa user-del без ключа --preserve.

ipa user-disable

Деактивировать учетную запись пользователя.

ipa user-enable

Активировать учетную запись пользователя.

ipa user-find

Выполнить поиск учетных записей пользователей.

ipa user-mod

Изменить учетную запись пользователя.

ipa user-remove-manager

Удалить отметку о руководителе сотрудника.

ipa user-remove-principal

Удалить псевдоним Kerberos учетной записи.

ipa user-show

Показать сведения о пользователе.

ipa user-stage

Переместить удаленную запись в список неподтвержденных пользователей.

ipa user-status

Состояние блокировки учетной записи пользователя.

ipa user-undel

Восстановить удаленную учетную запись пользователя из корзины.

ipa user-unlock

Разблокировать учетную запись пользователя.

ipa passwd

Установить новый пароль.
Поиск пользователей (ipa user-find)

Для поиска пользователей в каталоге используется команда ipa user-find, которая выведет список записей по заданным критериям. Синтаксис команды:

ipa [global-options] user-find [CRITERIA] [options]

Где:

  • global-options — глобальные параметры, описание которых можно просмотреть командой ipa -h, например, ключ -d позволяет включить вывод сообщений для отладки.

  • CRITERIA — критерий поиска по атрибутам uid, givenName, sn, telephoneNumber, ou, title. Допускает указывать не только полное значение, но и часть подстроки.

  • options — дополнительные параметры фильтрации, см. табл. 16.

Запросы к серверу можно отследить в журнале доступа командой sudo tail -f /var/log/dirsrv/slapd-ALD-COMPANY-LAN/access, см. рис. 237.

../_images/aldpro_mod4_image6.png

рис. 237 Проверка запроса на поиск в LDAP-каталоге по журналу доступа

Давайте запросим информацию о пользователе с логином admin. Чтобы можно было использовать вывод утилиты ipa, в скриптах автоматизации можно добавить ключ --raw. В этом случае вы получите данные в формате LDIF (от англ. LDAP, Data Interchange Format — формат представления записей службы каталога или их изменений в текстовой форме):

admin@dc-1:~$ ipa user-find --all --raw --login admin
---------------------
найден 1 пользователь
---------------------
  dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
  uid: admin
  sn: Administrator
  cn: Administrator
  homedirectory: /home/admin
  gecos: Administrator
  loginshell: /bin/bash
  krbprincipalname: admin@ALD.COMPANY.LAN
  krbprincipalname: root@ALD.COMPANY.LAN
  uidnumber: 296400000
  gidnumber: 296400000
  x-ald-user-mic-level: 63
  nsaccountlock: FALSE
  rbtadp: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
  rbtaou: ald.company.lan
  ipaNTSecurityIdentifier: S-1-5-21-2487214781-2721300798-1427603078-500
  ...
---------------------------------
Количество возвращённых записей 1
---------------------------------

Удалить поясняющие записи и лишние пробелы можно командами grep и sed:

ipa user-find --all --raw --login admin \
 | grep -E '(^\s\s|^$)' \
 | sed 's/^\s\s//g' \
 | grep -iE '(^dn|^sn|^uid|nsaccountlock|^$)'

Где:

  • grep -E '(^\s\s|^$)' — выбирает строки, начинающиеся с двух пробелов (\s символ пробела в регулярных выражениях) или пустые строки (^$).

  • sed 's/^\s\s//g' — заменяет двойной пробел в начале строки на пустой символ.

  • grep -iE '(^dn|^sn|^uid|nsaccountlock|^$) — выбирает несколько полей с помощью логического утверждения dn ИЛИ sn ИЛИ uid ИЛИ nsaccountlock. Обратите внимание, что в конце также выбираются и пустые строки ^$. Дело в том, что они нужны для разделения нескольких записей согласно спецификации формата LDIF.

Результат выполнения команды:

dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
uid: admin
sn: Administrator
uidnumber: 491200000
nsaccountlock: FALSE

Чтобы не допустить высокой нагрузки на сервер, бэкенд IPA возвращает не более 100 записей, а на обработку запросов должно уходить не более 2 секунд. Если ваш запрос не уложится в эти ограничения, то вы получите ошибку. Текущие лимиты можно посмотреть с помощью команды ipa config-show:

admin@dc-1:~$ ipa config-show
  Максимальная длина имени пользователя: 32
  Максимальная длина имени хоста: 64
  Основа домашних каталогов: /home
  Оболочка по умолчанию: /bin/bash
  Группа пользователей по умолчанию: ipausers
  Почтовый домен по умолчанию: ald.company.lan
  Ограничение времени поиска: 2
  Ограничение размера поиска: 100
  ...

Изменить конфигурацию можно с портала FreeIPA или из командной строки:

admin@dc-1:~$ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
  Максимальная длина имени пользователя: 32
  Максимальная длина имени хоста: 64
  Основа домашних каталогов: /home
  Оболочка по умолчанию: /bin/bash
  Группа пользователей по умолчанию: ipausers
  Почтовый домен по умолчанию: ald.company.lan
  Ограничение времени поиска: 5
  Ограничение размера поиска: 500
  ...
Детальный просмотр пользователя (ipa user-show)

Чтобы получить подробную информацию о пользователе, воспользуйтесь командой ipa user-show. Например, чтобы получить информацию о пользователе petrov.av выполните следующую команду:

admin@dc-1:~$ ipa user-show petrov.av
  Имя учётной записи пользователя: petrov.av
  Имя: Александр
  Фамилия: Петров
  Домашний каталог: /home/petrov.av
  Оболочка входа: /bin/bash
  Имя учётной записи: petrov.av@ALD.COMPANY.LAN
  Псевдоним учётной записи: petrov.av@ALD.COMPANY.LAN
  Адрес электронной почты: petrov.av@ald.company.lan
  UID: 491200007
  ID группы: 491200007
  Учётная запись отключена: False
  Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
  Link to head department: ald.company.lan
  Пароль: True
  Участник групп: ipausers
  Indirect Member of role: ALDPRO - Organization units
  Доступные ключи Kerberos: True

Выполняя команду ipa user-show с ключами --rights и --all, вы можете увидеть свои права доступа (effective rights) на изменение атрибутов выбранного пользователя. Однако примите во внимание, что параметр --all в этом случае обязателен, иначе вывод будет аналогичен команде ipa user-show без ключей.

ipa user-show iivanov --rights --all

Результат команды:

  admin@dc-1:~$ ipa user-show iivanov --rights --all
    dn: uid=iivanov,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
    Имя учётной записи пользователя: iivanov
    Имя: Иван
    Фамилия: Иванов
    ...
    Indirect Member of role: ALDPRO - Organization units
    Доступные ключи Kerberos: True
    attributelevelrights: {'objectclass': 'rscwo', 'aci': 'rscwo', 'sn': 'rscwo', ... 'ipanthomedirectorydrive': 'rscwo', 'nsaccountlock': 'rscwo'}
    ipantsecurityidentifier: S-1-5-21-3838112765-3762782768-2146355126-1008
    ipauniqueid: 904f6e98-2caf-11f0-bbdb-08002725086e
    ...

Права пользователя отображены в области attributelevelrights. Описание возможных значений вы найдете в табл. 17

табл. 17 Права на атрибуты для выбранного пользователя

Разрешение

Описание команды

r

Право на чтение атрибута для пользователя, запустившего команду

s

Право на поиск по атрибуту для пользователя, запустившего команду

w

Право записи в атрибут для пользователя, запустившего команду

o

Право на удаление атрибута для пользователя, запустившего команду

c

Право на сравнение атрибутов для пользователя, запустившего команду

W

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

O

Право на удаление для целевого пользователя, атрибуты которого просматриваются
Создание пользователя (ipa user-add)

Для создания пользователя используется команда ipa user-add с параметрами, см. табл. 18. Все доступные команды можно просмотреть в справке, вызвав команду:

admin@dc-1:~$ ipa help user-add
табл. 18 Список атрибутов для добавления пользователя

Атрибут

Описание

--first=STR

Имя пользователя. По умолчанию не задано.

--last=STR

Фамилия пользователя. По умолчанию не задана.

--cn=STR

Общее, распространенное имя. Если параметр не задан, автоматически формируется из имени и фамилии пользователя, например, Петр Иванов.

--displayname=STR

Отображаемое имя. Если не задано, создается из имени и фамилии пользователя, например, Петр Иванов.

--initials=STR

Инициалы. Если не задано, определяется автоматически из имени и фамилии, например, П.И.

--homedir=STR

Домашняя директория, по умолчанию /home/<user_login>, например, /home/ivanov.

--gecos=STR

Дополнительная информация о пользователе, которая может содержать номер телефона, домашний адрес, факс и др.

--shell=STR

Оболочка пользователя. Значение по умолчанию /bin/bash задается глобально в настройках контроллера домена.

--principal=PRINCIPAL

Уникальное имя пользователя, которое используется при аутентификации в домене. По умолчанию имеет значение user_login@{DOMAIN_SUFFIX}. Например, ivanov@ALD.COMPANY.LAN.

--principal-expiration=DATETIME

Окончание срока действия Kerberos-записи. Задается в формате GeneralizedTime ASN.1.

--password-expiration=DATETIME

Окончание срока действия Kerberos-пароля. Задается в том же формате, что и principal-expiration. Рассчитывается автоматически в момент изменения пароля в соответствии с действующей политикой паролей. По умолчанию срок действия паролей составляет 90 дней.

--email=STR

Электронная почта. По умолчанию равна user_login@{domain_suffix}. Например, ivanov.p@ald.company.lan.

--password

Запросить пароль пользователя в момент создания учетной записи.

--random

Сгенерировать пароль автоматически. Требования к паролю задаются политикой паролей контроллера домена. Пароль будет выведен после успешного выполнения команды по созданию пользователя.

--uid=INT

Назначить пользователю конкретный номер uidNumber. По умолчанию генерируется автоматически DNA-плагином.

--gidnumber=INT

Назначить пользователю конкретный номер первичной группы GidNumber. По умолчанию идентификатор первичной группы совпадает с идентификатором пользователя gidNumber=uidNumber.

--street=STR

Улица. По умолчанию значение не задано.

--city=STR

Город. По умолчанию значение не задано.

--state=STR

Область. По умолчанию значение не задано.

--postalcode=STR

Почтовый индекс. По умолчанию значение не задано.

--phone=STR

Рабочий телефон. По умолчанию значение не задано.

--mobile=STR

Мобильный телефон. По умолчанию значение не задано.

--pager=STR

Номер пейджера. По умолчанию значение не задано.

--fax=STR

Номер факса. По умолчанию значение не задано.

--orgunit=STR

Отдел. По умолчанию значение не задано.

--title=STR

Должность. По умолчанию значение не задано.

--manager=STR

Руководитель. По умолчанию значение не задано. Параметр должен совпадать с логином существующей учетной записи другого пользователя.

--carlicense=STR

Номер водительского удостоверения. По умолчанию значение не задано.

--sshpubkey=STR

Публичный ключ ssh. Для подключения к хостам по ssh-ключу. По умолчанию значение не задано.

--user-auth-type=['password', 'radius', 'otp', 'pkinit', 'hardened']

Тип авторизации пользователя. По умолчанию — по паролю (password).

--class=STR

Категория пользователя. Это поле может использоваться для автоматического назначения пользователю групп через механизм автоучастия (плагин automembership). По умолчанию значение не задано.

--radius=STR

Прокси-RADIUS-сервер. Для авторизации по RADIUS. По умолчанию значение не задано.

--radius-username=STR

Имя пользователя RADIUS. По умолчанию не задано.

--departmentnumber=STR

Служебная информация о департаменте. По умолчанию не задана.

--employeenumber=STR

Служебная информация о пользователе. По умолчанию не задана.

--employeetype=STR

Служебная информация о пользователе. По умолчанию не задана.

--preferredlanguage=STR

Предпочитаемый язык. Дополнительная информация о пользователе. По умолчанию значение не задано.

--certificate=CERTIFICATE

Сертификат пользователя для двухфакторной аутентификации. По умолчанию значение не задано.

--macmin=STR

Целое число для назначения минимального уровня конфиденциальности. По умолчанию равно 0.

--macmax=STR

Целое число для назначения максимального уровня конфиденциальности. По умолчанию равно 0.

--miclevel=INT

Целое число, задающее маску уровней целостности. По умолчанию равно 0.

--middlename=STR

Отчество пользователя. По умолчанию значение не задано.

--photo=BYTES

Фотография пользователя, можно загрузить через портал управления. По умолчанию значение не задано.

--country=STR

Код страны по стандарту ISO 3166, например RU. По умолчанию значение не задано.

--proxyaddresses=STR

Полный список адресов пользователя. Может содержать SMTP-, SIP-, X.500-адреса. Например, SMTP: ivanov@ald.company.lan. По умолчанию значение не задано.

--department=DNPARAM

Задает подразделение, к которому прикреплен пользователь. По умолчанию значение будет равно ou={domain_sufix},cn=orgunits,cn=accounts,{root_suffix}, например, ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan.

--setattr=STR

Присвоить значение атрибуту пользователя в формате «атрибут=значение». Если атрибут многозначный, он будет перезаписан.

--addattr=STR

Добавить атрибут для пользователя в формате «атрибут=значение».

--noprivate

Не создавать первичную группу пользователя. По умолчанию при создании пользователя создается одноименная группа, gidNumber которой равен uidNumber пользователя. POSIX-пользователь не может быть создан без POSIX-группы.

--all

Показать все атрибуты пользователя. Используется при выводе данных.

--raw

Показать всю информацию о пользователе. Используется при выводе данных.

--no-members

Не показывать группы, в которых состоит пользователь (атрибуты memberOf).

Уточним также:

  • {root_suffix} — это корневой суффикс LDAP-каталога, состоит из нескольких компонентов доменного имени (Domain Component, DC), например, dc=ald,dc=company,dc=lan.

  • {domain_suffix} — это суффикс домена в формате полного имени домена, например, ald.company.lan.

Рассмотрим создание пользователя на следующем примере. Для удобства каждый параметр будем задавать в отдельной строке с помощью символа переноса строки \ backslash:

ipa user-add isemenov \
  --first="Иван" --last="Семенов" --middlename="Иванович" \
  --cn="Семенов И.И." --displayname="Семенов И.И." --initials="И.И." \
  --principal-expiration="$(date +'%Y%m%d000000Z' -d '+90 days')" \
  --password-expiration="$(date +'%Y%m%d000000Z' -d '+90 days')" \
  --random --email="semenov.ii@ald.company.lan" \
  --addattr="memberof=cn=ipausers,cn=groups,cn=accounts,dc=ald,dc=company,dc=lan" \
  --country="RU" --street="Ленина, 1" --city="Москва" --state="Московская область" \
  --postalcode="101" --phone="+71234567890" --mobile="+71234567890" \
  --fax="+71234567890" --orgunit="Отдел АСУ" --title="Инженер первой категории" \
  --departmentnumber="Департамент 1" --employeenumber="1" --employeetype="Категория 1"

Результат выполнения команды:

 --------------------------------
 Добавлен пользователь "isemenov"
 --------------------------------
   Имя учётной записи пользователя: isemenov
   Имя: Иван
   Фамилия: Семенов
   Полное имя: Семенов И.И.
   Отображаемое имя: Семенов И.И.
   Инициалы: И.И.
   Домашний каталог: /home/isemenov
   GECOS: Иван Семенов
   Оболочка входа: /bin/bash
   Имя учётной записи: isemenov@ALD.COMPANY.LAN
   Псевдоним учётной записи: isemenov@ALD.COMPANY.LAN
   Окончание действия учётной записи Kerberos: 20250807000000Z
   Окончание действия пароля пользователя: 20250807000000Z
   Адрес электронной почты: semenov.ii@ald.company.lan
   Случайный пароль: 3Eg@Bx[G6m|aPP@KBgf3L9
   UID: 491200012
   ID группы: 491200012
   Адрес: Ленина, 1
   Город: Москва
   Область/республика: Московская область
   Индекс: 101
   Номер телефона: +71234567890
   Номер мобильного телефона: +71234567890
   Номер факса: +71234567890
   Отдел: Отдел АСУ
   Должность: Инженер первой категории
   Номер отдела: Департамент 1
   Номер сотрудника: 1
   Тип сотрудника: Категория 1
   Минимальный уровень конфиденциальности: 0
   Максимальный уровень конфиденциальности: 0
   Учётная запись отключена: FALSE
   nsuniqueid: 83778601-2cb011f0-81d3c33d-ecd7a769
   Middle name: Иванович
   Contry: RU
   proxy addresses: SMTP:SEMENOV.II@ALD.COMPANY.LAN
   Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
   Link to head department: ald.company.lan
   Пароль: True
   Участник групп: ipausers
   Роли: ALDPRO - Organization units
   Indirect Member of group: ipausers
   Доступные ключи Kerberos: True

Обратите внимание на случайный пароль 3Eg@Bx[G6m|aPP@KBgf3L9, который был сгенерирован системой автоматически. Он будет нужен пользователю для первого входа в систему.

Если вам нужно будет назначить пароль пользователя вручную, то вместо ключа --random используйте ключ --password. А если потребуется назначить пароль из командной строки, то воспользуйтесь перенаправлением вывода:

echo 'Pa$$w0rd' | ipa user-add apetrov \
  --first="Александр" --last="Петров" --middlename="Владимирович" \
  --password --password-expiration="$(date +'%Y%m%d000000Z' -d '+90 days')"

Результат выполнения команды:

 -------------------------------
 Добавлен пользователь "apetrov"
 -------------------------------
   Имя учётной записи пользователя: apetrov
   Имя: Александр
   Фамилия: Петров
   Полное имя: Александр Петров
   Отображаемое имя: Александр Петров
   Инициалы: АП
   Домашний каталог: /home/apetrov
   GECOS: Александр Петров
   Оболочка входа: /bin/bash
   Имя учётной записи: apetrov@ALD.COMPANY.LAN
   Псевдоним учётной записи: apetrov@ALD.COMPANY.LAN
   Окончание действия пароля пользователя: 20250807000000Z
   Адрес электронной почты: apetrov@ald.company.lan
   UID: 491200013
   ID группы: 491200013
   Минимальный уровень конфиденциальности: 0
   Максимальный уровень конфиденциальности: 0
   Учётная запись отключена: FALSE
   nsuniqueid: cafe1201-2cb011f0-81d3c33d-ecd7a769
   Middle name: Владимирович
   proxy addresses: SMTP:APETROV@ALD.COMPANY.LAN
   Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
   Link to head department: ald.company.lan
   Пароль: True
   Участник групп: ipausers
   Роли: ALDPRO - Organization units
   Доступные ключи Kerberos: True
Изменение параметров пользователя (ipa user-mod)

Сотрудники меняют номера телефонов и фамилии, получают повышения в должности, поэтому вам потребуется менять отдельные атрибуты. Для этого вам потребуется команда ipa user-mod. Параметры команды практически совпадают с параметрами команды ipa user-add, см. табл. 18.

В качестве примера: если пользователь перевелся из московского офиса в казанский, вам потребуется изменить параметр department в свойствах пользователя. С точки зрения LDAP-каталога это равносильно изменению атрибута rbtadp. Создайте департамент ou=kazan на портале ALD Pro и выполните команду:

ipa user-mod apetrov \
  --department="ou=kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"

Результат выполнения команды:

 ------------------------------
 Изменён пользователь "apetrov"
 ------------------------------
   Имя учётной записи пользователя: apetrov
   Имя: Александр
   Фамилия: Петров
   ...
   Link to department: ou=kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
   Link to head department: kazan
   ...

Пример изменения контактных данных пользователя:

ipa user-mod apetrov \
  --phone "+71122334455" --email "apetrov@kaz.ald.company.lan"

Результат выполнения команды:

 ------------------------------
 Изменён пользователь "apetrov"
 ------------------------------
   Имя учётной записи пользователя: apetrov
   Имя: Александр
   Фамилия: Петров
   ...
   Адрес электронной почты: apetrov@kaz.ald.company.lan
   ...
   Номер телефона: +71122334455
   ...

Аналогичным образом можно изменить любые другие атрибуты пользователя.

Установка нового пароля (ipa passwd)

Пользователь может сменить себе пароль с помощью команды passwd без параметров:

admin@dc-1:~$ ipa passwd
Текущий пароль:
Новый пароль:
Введите Новый пароль ещё раз для проверки:
--------------------------------------
Изменён пароль "admin@ALD.COMPANY.LAN"
--------------------------------------

С помощью этой же команды администраторы могут назначить новый пароль любой другой учетной записи, если у них достаточно прав доступа:

admin@dc-1:~$ ipa passwd apetrov
Новый пароль:
Введите Новый пароль ещё раз для проверки:
-----------------------------------------
Изменён пароль "apetrov@ALD.COMPANY.LAN"
-----------------------------------------

Аналогичный результат можно получить командой ipa user-mod с ключом --password:

admin@dc-1:~$ ipa user-mod --password apetrov
Пароль:
Введите Пароль ещё раз для проверки:
--------------------------------
Изменён пользователь "apetrov"
--------------------------------
Имя учётной записи пользователя: apetrov
...

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

ipa user-mod --random apetrov

Результат выполнения команды:

 ---------------------------------
 Изменён пользователь "apetrov"
 ---------------------------------
 Имя учётной записи пользователя: apetrov
 ...
 Случайный пароль: Vf}7-NsaWNnV.OlMl8]q^E
 ...

При назначении пользователю нового пароля из веб-интерфейса или из командной строки срок действия Kerberos-пароля автоматически проставляется равным текущей дате, поэтому пароль считается истекшим и требует изменения при следующем входе. Изменить значение этого атрибута можно, например, с помощью утилиты ipa, используя ключ --password-expiration:

ipa user-mod apetrov --password-expiration 20260101115110Z

Если пользователь сменит пароль самостоятельно, ему будет назначен срок действия в соответствии с установленными политиками (по умолчанию — 90 дней).

Активация/деактивация пользователя (ipa user-disable/user-enable)

С помощью команды ipa user-disable администратор может деактивировать учетную запись, чтобы заблокировать пользователю доступ, не удаляя учетную запись из домена. В этом случае атрибуту nsAccountLock устанавливается значение True:

admin@dc-1:~$ ipa user-disable apetrov
--------------------------------------------------
Учётная запись пользователя "apetrov" отключена
--------------------------------------------------

Текущее состояние учетной записи можно посмотреть командой ipa user-show:

admin@dc-1:~$ ipa user-show apetrov --all --raw | grep nsaccountlock
  nsaccountlock: TRUE

Состояние блокировки показывает так же команда ipa user-status, но ее лучше не использовать, т.к. она больше предназначена для получения информации об автоматической временной блокировки пользователя со всех контроллеров домена, что занимает значительно больше времени.

  admin@dc-1:~$ ipa user-status apetrov
  ----------------------
  Account disabled: True
  ----------------------
  ...

Деактивированный пользователь не сможет войти в операционную систему доменного компьютера, пока не будет активирован с помощью команды ipa user-enable:

admin@dc-1:~$ ipa user-enable apetrov
-------------------------------------------------
Учётная запись пользователя "apetrov" включена
-------------------------------------------------
Снятие блокировки пользователя (ipa user-unlock)

Кроме активации/деактивации в домене есть еще автоматическая временная блокировка по количеству ошибок, которая позволяет исключить перебор паролей.

В соответствии с настройками по умолчанию, если пользователь в течение 1 минуты 6 раз подряд введет неправильно пароль, то его учетная запись будет автоматически заблокирована на следующие 10 минут. Указанные параметры можно изменить с помощью политик паролей.

Текущее состояние учетной записи можно узнать с помощью команды ipa user-status. Следует учитывать, что количество неправильных попыток записывается в атрибуте krbLoginFailedCount, который для повышения производительности исключен из репликации, поэтому бэкенд команды ipa user-status для сбора необходимой информации опрашивает все контроллеры в домене, что может занять некоторое время:

admin@dc-1:~$ ipa user-status apetrov
-----------------------
Account disabled: False
-----------------------
  Сервер: dc-1.ald.company.lan
  Неудачные попытки входа: 6
  Последняя успешная аутентификация: N/A
  Последняя ошибка при аутентификации: 2025-04-04T09:15:18Z
  Время сейчас: 2025-04-04T09:19:01Z
...
  Сервер: dc-5.ald.company.lan
  Неудачные попытки входа: 0
  Последняя успешная аутентификация: N/A
  Последняя ошибка при аутентификации: 2025-04-04T09:15:18Z
  Время сейчас: 2025-04-04T09:19:01Z

---------------------------------
Количество возвращённых записей 5
---------------------------------

Можно увидеть, что число попыток на dc-1 равно 6. Поэтому пользователь не сможет пройти Kerberos-аутентификацию с помощью этого контроллера домена, но на работу других контроллеров домена эта блокировка никак не повлияет.

Чтобы разблокировать учетную запись пользователя, нужно воспользоваться командой ipa user-unlock. В этом случае выполняется сброс счетчика krbLoginFailedCount, а в атрибут krbLastAdminUnlock записывается текущее время системы:

admin@dc-1:~$ ipa user-unlock apetrov
------------------------------------------
Учётная запись "apetrov" разблокирована
------------------------------------------

Для снятия блокировки бэкенд команды ipa user-unlock обращается ко всем контроллерам в домене, поэтому выполнение команды может занять некоторое время.

Удаление пользователя (ipa user-del)

Удалить учетные записи пользователей из домена можно командой ipa user-del. По умолчанию используется ключ --no-preserve, поэтому запись удаляется безвозвратно. Если использовать ключ --preserve, то запись будет перемещена в контейнер хранимых пользователей cn=deleted users,cn=accounts,cn=provisioning.

admin@dc-1:~$ ipa user-del --preserve apetrov
--------------------------------
Удален пользователь "apetrov"
--------------------------------

В системе ALD Pro удаленные учетные записи можно будет найти в корзине, см. рис. 238, а в интерфейсе FreeIPA этот раздел называется «Хранимые пользователи».

../_images/aldpro_mod4_image7.png

рис. 238 Корзина с удаленными пользователями

Для поиска пользователей, помещенных в корзину, в команде ipa user-find нужно использовать ключ --preserved true:

admin@dc-1:~$ ipa user-find --preserved true
---------------------
найден 1 пользователь
---------------------
  Имя учётной записи пользователя: apetrov
  Имя: Александр
  Фамилия: Петров
  Домашний каталог: /home/apetrov
  Оболочка входа: /bin/bash
  Имя учётной записи: apetrov@ALD.COMPANY.LAN
  Псевдоним учётной записи: apetrov@ALD.COMPANY.LAN
  Адрес электронной почты: apetrov@kaz.ald.company.lan
  UID: 491200013
  ID группы: 491200013
  Номер телефона: +71122334455
  Учётная запись отключена: True
  Хранимый пользователь: True
---------------------------------
Количество возвращённых записей 1
---------------------------------

Для восстановления удаленной учетной записи пользователя из корзины используйте команду ipa user-undel:

admin@dc-1:~$ ipa user-undel apetrov
---------------------------------------------------------------
Учётная запись пользователя "apetrov" возвращена после удаления
---------------------------------------------------------------

Пользователи, находящиеся в корзине, блокируются автоматически, поэтому атрибут nsAccountLock для этих учетных записей устанавливается равным True. После восстановления учетной записи из корзины указанный атрибут также автоматически удаляется. Если на момент помещения в корзину учетная запись уже была заблокирована, то после восстановления такой записи она так и останется в заблокированном состоянии, для нее атрибут nsAccountLock удаляться не будет.

Утилита ipa-getkeytab

Для аутентификации по протоколу Kerberos V5 система использует хеши паролей, которые называются также Kerberos-ключами. Для повышения совместимости клиент и сервер могут хранить сразу несколько разных хешей для одного и того же пароля и договариваться об использовании наиболее безопасного их них в момент аутентификации.

Внутри LDAP-каталога Kerberos-ключи хранятся в атрибуте krbPrincipalKey, а на диске в keytab-файлах, которые называют также таблицами ключей (англ. Key Table). Следует понимать, что внутри одного keytab-файла может храниться сразу несколько ключей для одного и того же пароля, или несколько ключей для разных версий пароля одного и того же пользователя или даже несколько ключей для разных пользователей.

Чтобы сбросить пароль доменной учетной записи и выгрузить Kerberos-ключи в keytab-файл, можно воспользоваться утилитой ipa-getkeytab. Содержимое keytab-файла представляет собой бинарные данные, посмотреть которые можно утилитой klist.

Создадим в домене учетную запись для нового сервиса HTTP/pc-1.ald.company.lan и опробуем на нем работу этих утилит:

admin@dc-1:~$ sudo ipa service-add HTTP/pc-1.ald.company.lan
------------------------------------------------------------
Добавлена служба "HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN"
------------------------------------------------------------
  Имя учётной записи: HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN
  Псевдоним учётной записи: HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN
  Managed by: pc-1.ald.company.lan

admin@dc-1:~$ sudo ipa-getkeytab -s dc-1.ald.company.lan \
>  -p HTTP/pc-1.ald.company.lan -k /etc/http.keytab
Таблица ключей успешно получена и сохранена в: /etc/http.keytab

admin@dc-1:~$ sudo klist -ke /etc/http.keytab
Keytab name: FILE:/etc/http.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96)
   1 HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

При вызове утилиты ipa-getkeytab используются следующие ключи:

  • -s dc-1.ald.company.lan — задает имя KDC-сервера, к которому следует отправить запрос.

  • -p HTTP/pc-1.ald.company.lan — определяет имя сервиса.

  • -k /etc/http.keytab — задает путь для сохранения keytab-файла.

При вызове утилиты klist используются следующие ключи:

  • -k — задает путь до keytab-файла, который нужно прочитать.

  • -e — указывает, что нужно отобразить ключи с использованным алгоритмом хеширования.

Получить keytab-файл можно как для сервиса, так и для учетной записи обычного пользователя. Следует только учитывать, что в момент выгрузки keytab-файла система генерирует новый пароль, но не отображает его на экране, поэтому аутентифицироваться такой пользователь после этого сможет только по keytab-файлу.

Создадим keytab-файл для пользователя iivanov и пройдем аутентификацию в домене с помощью ключей из этого файла:

admin@dc-1:~$ sudo ipa-getkeytab -s dc-1.ald.company.lan \
>  -p apetrov@ALD.COMPANY.LAN -k /home/admin/apetrov.keytab
  Таблица ключей успешно получена и сохранена в: /home/admin/apetrov.keytab

admin@dc-1:~$ sudo kinit apetrov -kt /home/admin/apetrov.keytab

admin@dc-1:~$ sudo klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_9andJvL
Default principal: apetrov@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
02.05.2025 11:51:35  03.05.2025 11:39:08  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Утилиты ipa-backup и ipa-restore

Для резервного копирования и восстановления информации каталога предназначены утилиты ipa-backup и ipa-restore. Следует понимать, что на контроллере домена кроме службы каталога есть еще целый ряд сервисов, поэтому данная копия не позволит вам восстановить контроллер целиком, но зато вы можете застраховать себя от полной потери данных.

Следующей командой можно создать резервную копию каталога:

admin@dc-1:~$ sudo ipa-backup --data --online --verbose --log-file freeipa-backup.log
ipalib.sysrestore: DEBUG: Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
ipalib.sysrestore: DEBUG: Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state'
. . .
ipaserver.install.ipa_backup: INFO: Backing up userRoot in ALD-COMPANY-LAN to LDIF
ipaserver.install.ipa_backup: INFO: Waiting for LDIF to finish
ipaserver.install.ipa_backup: INFO: Backing up ALD-COMPANY-LAN
ipaserver.install.ipa_backup: INFO: Waiting for BAK to finish
ipapython.ipautil: DEBUG: Starting external process
ipapython.ipautil: DEBUG: args=['tar', '--xattrs', '--selinux', '-czf', '/var/lib/ipa/backup/ipa- data-2024-03-22-21-26-19/ipa-data.tar', '.']
ipapython.ipautil: DEBUG: Process finished, return code=0
ipapython.ipautil: DEBUG: stdout=
ipapython.ipautil: DEBUG: stderr=
ipaserver.install.ipa_backup: INFO: Backed up to /var/lib/ipa/backup/ipa-data-2024-01-22-21-26-19
ipapython.admintool: INFO: The ipa-backup command was successful

Где:

  • Ключ --data – указывает, что нужно выполнить резервную копию только данных. С помощью ключа --logs можно включить еще журналы изменений. Если не определять никакой ключ, то в резервную копию будут включены все данные.

  • Ключ --online – требует выполнить резервную копию без остановки служб.

  • Ключ --verbose – указывает, что нужно вывести отладочную информацию.

  • Ключ --log-file – задает имя файла, в который будет сохранен журнал о выполнении процедуры резервного копирования.

А вот так вы можете восстановить данные из копии:

admin@dc-1:~$ sudo ipa-restore --data --online --instance=ALD-COMPANY-LAN /var/lib/ipa/backup/ipa-data-2024-01-22-21-26-19
Directory Manager (existing master) password:
Preparing restore from /var/lib/ipa/backup/ipa-data-2024-01-22-21-26-19 on dc-1.ald.company.lan
Performing DATA restore from DATA backup
Temporary setting umask to 022
Restoring data will overwrite existing live data. Continue to restore? [no]: yes
Each master will individually need to be re-initialized or
re-created from this one. The replication agreements on
masters running IPA 3.1 or earlier will need to be manually
re-enabled. See the man page for details.
Disabling all replication.
Disabling replication agreement on dc-2.ald.company.lan to dc-1.ald.company.lan
Starting Directory Server
Restoring from userRoot in ALD-COMPANY-LAN
Waiting for LDIF to finish
Restoring umask to 18
The ipa-restore command was successful

Где:

  • Ключ --data – указывает, что требуется восстановить только данные.

  • Ключ --online – требует выполнить восстановление без остановки служб.

  • Ключ --instance – задает имя экземпляра службы каталога, т.к. на одном сервере их может быть несколько. Например, в ALD Pro реализован модуль глобального каталога, который представляет собой еще один экземпляр LDAP-каталога, который доступен по порту 3268/TCP.

    Глобальный каталог нужен для того, чтобы при работе в доверительных отношениях с MS AD вы могли из стандартных интерфейсов Windows назначать права доступа на объекты ALD Pro, выбирая их из списка. Без глобального каталога поиск по объектам доверенного домена работать не будет.

Однако при восстановлении каталога из резервной копии в домене из нескольких контроллеров вам потребуется сделать также полную реинициализацию остальных реплик, т.к. у восстановленного контроллера будет новое значение генератора CSN и он выпадет из инкрементальной репликации. Детали этой процедуры можно будет понять после подробного ознакомления с алгоритмом работы репликации, см. Модуль 7. Дополнительные подсистемы ALD Pro.

Сервер LDAP 389 Directory Server

Для распределенного хранения данных в домене используется LDAP-каталог 389 Directory Server (ранее Fedora Directory Server, а до этого Netscape Directory Server). Эта служба соответствует уровню предприятий и позволяет реплицировать данные на сотни серверов, обеспечивая сотни тысяч операций чтения/записи в секунду.

Служба 389 DS позволяет хранить в базе миллионы записей, имеет мощный механизм разграничения доступа вплоть до уровня отдельных атрибутов, поддерживает протокол LDAP v3, в том числе с шифрованием SSL/TLS и SASL (при выполнении Kerberos-аутентификации).

В качестве встроенной базы данных 389 DS использует очень популярную библиотеку BDB (Berkeley DB), но в предстоящих релизах ожидается его замена на LMDB (Lightning Memory-Mapped Database), что повысит производительность отдельных операций в несколько раз.

Каталог LDAP

Каталог - это специализированная иерархическая нереляционная база данных для хранения информации о людях, компьютерах, группах и других объектах.

Изначально по стандарту X.500 доступ к каталогам предполагался через компьютерную сеть OSI, а разработанный в дальнейшем облегченный протокол доступа к данным каталога (Lightweight Directory Access Protocol, LDAP) дал возможность взаимодействия с каталогами по сетям TCP/IP.

Функции LDAP-каталога на контроллере домена реализованы средствами 389 Directory Server, файлы которого вы найдете в папке /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/db. Информация каталога представлена в виде древовидной структуры, которую также называют Directory Information Tree или сокращенно DIT, см. рис. 239.

../_images/aldpro_mod4_image9.png

рис. 239 Структура каталога Directory Information Tree

Корень каталога называется Root DSE, где DSE означает Directory System Agent Specific Entry, то есть специализированная запись агента системы директорий. Эта запись не имеет родителя, и она описана в файле /etc/dirsrv/slapd-ALD-COMPANY-LAN/dse.ldif, где slapd-ALD-COMPANY-LAN - это директория сервиса slapd для домена ALD-COMPANY-LAN.

Корень Root DSE является родителем для записей dc=ald,dc=company,dc=lan и cn=changelog, которые называют также базовыми записями, корневыми суффиксами или контекстами именования (от англ. base entry, root suffix, naming context). В контексте dc=ald,dc=company,dc=lan хранятся все записи каталога, а в cn=changelog — журнал изменений для работы плагина Retro Changelog Plugin. Все контексты, определенные в каталоге, указаны в операционном атрибуте namingContexts записи Root DSE, однако спецификация LDAP позволяет также использовать служебные контексты. Например, в записи cn=config представлены настройки каталога, а через запись cn=monitor можно получить доступ к информации о состоянии сервера в режиме реального времени.

От корневого суффикса dc=ald,dc=company,dc=lan ответвляются дочерние записи (от англ. entry), которые, в свою очередь, могут быть контейнерами для других записей, за счет чего и образуется древовидная структура. Таким образом, записи каталога можно сравнить с директориями файловой системы.

Записи каталога называют так же объектами или контейнерами. У каждого объекта есть имя, которое должно быть уникальным в пределах родительского контейнера, поэтому это имя называется относительно уникальным именем (англ. relative distinguished name или кратко RDN). Учетные записи пользователей, например, имеют имена uid=admin, uid=ivan.kuznetsov и т.д. Особенность имен записей в LDAP заключается в том, что они хранят не конкретные значения, а только ссылки на хранимые атрибуты записей, которые используются для идентификации записей. Например, для идентификации учетных записей пользователей используют атрибут uid, для учетных записей компьютеров — fqdn (от англ. fully qualified domain name, полное доменное имя хоста), а в именах контейнеров обычно присутствует cn (от англ. common name, общее имя).

В приведенном примере RDN учетной записи доменного администратора uid=admin состоит из названия атрибута uid, после которого идет символ присвоения = и далее значение атрибута admin. Вся эта запись вместе называется определением значения атрибута (от англ. attribute value assertion, AVA). Обычно имена записей задаются значением одного атрибута, но могут использоваться и несколько, тогда в имени RDN эти определения AVA будут объединяться знаком сложения +. Например, при конфликтах репликации запись переименовывается в формате nsuniqueid=0a950601...+uid=Ivan.

Для идентификации записи в пределах всего каталога используют уникальное отличительное имя (англ. distinguished name или сокращенно DN). Отличительное имя представляет собой цепочку RDN, которые записывают через запятую слева направо, начиная с целевой записи и до корневого суффикса вверх по иерархии, см. рис. 240.

Если привести аналогию с объектами файловой системы, то RDN будет соответствовать относительному пути, а DN — полному абсолютному пути до объекта. И так же как на одном диске не может быть двух директорий с одинаковыми полными именами, в каталоге LDAP не может быть двух записей с одинаковыми DN. Описание формата DN можно найти в RFC 4514.

../_images/aldpro_mod4_image10.png

рис. 240 Пример формирования уникального отличительного имени записи DN

Запись каталога может хранить не только дочерние записи, но и набор атрибутов, описывающий свойства записи. Например, для учетной записи пользователя атрибутами могут быть Ф.И.О., должность, номер телефона и т.д. Продолжая аналогию с файловой системой, можно сказать, что запись соответствует папке на диске, а атрибут - файлу, поэтому внутри папки могут быть другие папки (записи), а файлы (атрибуты) являются конечными листьями в этом дереве.

Обычные атрибуты называются «хранимыми», но в LDAP-каталоге кроме них есть еще служебные «операционные» атрибуты, которые содержат вспомогательную информацию для обеспечения работы каталога и связи между записями. Например, чтобы не пересчитывать вручную количество дочерних записей, вы можете воспользоваться операционным атрибутом numSubordinates, который кэширует для вас это значение.

Рассмотрим несколько интересных операционных атрибутов:

  • entrydn или dsEntryDN — позволяют получить уникальное отличительное имя записи в секции атрибутов, что очень требуется иногда для подключения к каталогу внешних информационных систем. Например, сервису VK Почта для интеграции очень нужно видеть в атрибутах полное значение отличительного имени пользователя.

  • nsUniqueId и entryUUID — определяют уникальный идентификатор записи в пределах домена. Для каталога 389 Directory Server, как потомка Netscape Directory Server (NS), нативным атрибутом является nsUniqueId, а дополнительный атрибут entryUUID был добавлен упрощения миграции с OpenLDAP на 389 Directory Server после того, как два основных корпоративных дистрибутива Linux (SUSE и Red Hat) решили удалить OpenLDAP из своих репозиториев.

  • entryid и parentid — хранят идентификатор текущей и родительской записи, который уникален для каждого экземпляра 389 Directory Server.

  • entryusn — номер обновления записи в последовательности изменений (англ. Update Sequence Number, USN), который уникален для каждого экземпляра 389 Directory Server.

  • creatorsName, modifiersName, createTimestamp и modifyTimestamp — хранят соответственно имена тех пользователей, которые создали и изменили запись в каталоге, а так же дату и время этих событий. Значения будут одинаковыми на всех серверах в домене.

    Обратите внимание, если вам потребуется забирать из каталога последние изменения простым LDAP-запросом, то правильно будет сортировать и фильтровать записи по атрибуту entryusn и не использовать modifyTimestamp, т.к. изменения, сделанные на других серверах, будут реплицироваться с задержками.

  • numSubordinates — хранит текущее значение количества дочерних записей. Следует учитывать, что значение показывает общее количество всех записей, включая и скрытые операционные записи, отмеченные классом ldapsubentry.

Данные в LDAP-каталоге должны быть строго структурированы, поэтому при включенной проверке целостности новые атрибуты должны быть определены в схеме каталога заранее. Перечень атрибутов, доступных для конкретного объекта, определяется списком назначенных ему классов, см. атрибут objectClass. Например, учетные записи пользователей могут иметь атрибуты uidNumber и gidNumber, так как им присвоен класс объектов posixAccount, см. рис. 241.

../_images/aldpro_mod4_image11.png

рис. 241 Наличие атрибута gidNumber определяется классом объекта posixAccount

Всем объектам каталога прямо или через наследование назначен как минимум один класс top, т.к. в нем описан атрибут objectClass, с помощью которого работает механизм назначения классов. Но практической пользы от объектов с одним классом немного, поэтому обычно в каталоге у объектов два и более классов.

В качестве примера рассмотрим класс объектов posixGroup, который определен в схеме следующим образом:

( 1.3.6.1.1.1.2.2 NAME 'posixGroup' DESC 'Standard LDAP objectclass' SUP top STRUCTURAL MUST ( cn $ gidNumber ) MAY ( userPassword $ memberUid $ description ) X-ORIGIN 'RFC 2307' )

Где:

  • 1.3.6.1.1.1.2.2 – это идентификатор объекта (object id, OID). Глобальные идентификаторы присваиваются международными организациями (IANA, ISO, ITU-T, ANSI, BSI).

    Для расширения схемы в прикладных системах используется пространство номеров с префиксом «1.3.6.1.4.1.<X>», где <X> – это внутренний номер организации. Например, объекты РусБИТех-Астра имеют префикс «1.3.6.1.4.1.52616.*».

  • NAME '...' – инструкция NAME задает имя класса.

  • DESC '...' – инструкция DESC задает описание класса.

  • SUP '...' – инструкция SUP указывает родительский класс. В приведенном примере наследование идет от класса top, поэтому объектам будет доступен его атрибут objectClass.

  • STRUCTURAL – инструкция указывает, что класс будет относиться к виду структурных. Существуют также абстрактные (ABSTRACT) и вспомогательные (AUXILIARY) классы.

  • MUST и MAY – инструкции, которые позволяют задать списки обязательных и дополнительных атрибутов соответственно. Полный перечень атрибутов, доступных объекту, расширяется атрибутами, которые наследуются от всех родительских классов.

  • X-ORIGIN '...' – инструкция, которая позволяет задать комментарий с ссылкой на документацию, из которой можно почерпнуть дополнительную информацию об этом классе. В приведенном примере информацию следует искать в документе RFC 2307.

Обратите внимание на то, что один и тот же атрибут может быть использован в нескольких классах, поэтому пользователям можно задать значение gidNumber, т.к. им назначен класс posixAccount, и в то же время он может быть задан у групп, т.к. им назначен класс posixGroup, см. рис. 242.

../_images/aldpro_mod4_image12.png

рис. 242 Использование атрибута gidNumber классами posixAccount и posixGroup

Теперь рассмотрите описание атрибута gidNumber подробнее:

( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'Standard LDAP attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE X-ORIGIN 'RFC 2307' )

Где:

  • 1.3.6.1.1.1.1.1 – это уникальный идентификатор атрибута.

  • NAME '...' – инструкция NAME задает имя атрибута.

  • DESC '...' – инструкция DESC задает описание атрибута.

  • SYNTAX '...' – инструкция задает тип хранимого в атрибуте значения. В приведенном примере 1.3.6.1.4.1.1466.115.121.1.27 соответствует целым числам. Описание всех типов данных можно найти в RFC 4517.

  • SINGLE-VALUE – инструкция указывает, что атрибут может хранить только одно значение. Если этой инструкции не будет, то объектам можно будет присваивать несколько значений этого атрибута.

  • X-ORIGIN '...' – инструкция, которая позволяет задать комментарий со ссылкой на документацию.

Если вы хотите подробнее ознакомиться с доступными классами и атрибутами, то при обращении к каталогу по LDAP информацию можно получить из операционного DIT cn=schema. На диске эта информация хранится в директориях:

  • /usr/share/dirsrv/schema/

  • /etc/dirsrv/schema/

  • /usr/share/dirsrv/updates/

  • /etc/dirsrv/slapd-ALD-COMPANY-LAN/

Вот полная информация обо всех файлах 389 Directory Server на диске:

  • Папка /usr/sbin/ содержит исполнимые файлы:

    • Файл /usr/sbin/ns-slapd – исполнимый файл сервиса.

    • Файл /usr/sbin/dsctl – утилита управления сервисом.

    • Файл /usr/sbin/dsсonf – утилита настройки и мониторинга.

  • Папка /usr/lib/systemd/system/ содержит файлы сервиса:

    • Файл /usr/lib/systemd/system/dirsrv.target – это “целевой” файл, используемый для совместной работы со всеми экземплярами dirsrv.

    • Файл /usr/lib/systemd/system/dirsrv@<название-Экземпляра>.service (если экземпляр только один, то имя сервиса будет dirsrv@.service).

  • Папка /var/lock/dirsrv/slapd-<название-Экземпляра>/ содержит файлы блокировок базы данных.

  • Папка /var/lib/dirsrv/slapd-<название-Экземпляра>/` содержит файлы резервных копий, базы данных, журналов изменений и LDIF-файлы:

    • Папка /var/lib/dirsrv/slapd-<название-Экземпляра>/bak/ содержит резервные копии LDAP-каталога, созданные командой dsconf -D "cn=Directory Manager" ldap://localhost backup create.

    • Папка /var/lib/dirsrv/slapd-<название-Экземпляра>/db/ содержит базу данных каталога.

    • Папка /var/lib/dirsrv/slapd-<название-Экземпляра>/ldif/ содержит LDIF-файлы, которые создаются, например, при резервном копировании каталога командой sudo dsctl ALD-COMPANY-LAN db2ldif userRoot.

  • Папка конфигураций /etc/dirsrv/ содержит:

    • Папка /etc/dirsrv/config/ содержит конфигурационные файлы.

    • Папка /etc/dirsrv/schema/ содержит файлы файлы схемы LDAP-каталога.

    • Папка /etc/dirsrv/ssca/ содержит сертификаты и ключи самоподписанного центра сертификации (англ. Simple Self-Signed Certificate Authority, SSCA).

    • Папка /etc/dirsrv/slapd-<название-Экземпляра>/schema/ содержит файлы схемы LDAP-каталога для конкретного экземпляра сервера. В этом каталоге находится в том числе файл 99user.ldif с изменениями схемы каталога, которые вносятся через LDAP-запросы и реплицируются автоматически между всеми контроллерами в домене.

  • Папка /usr/share/dirsrv/schema/ содержит схему каталога по умолчанию.

В нашем случае корневой суффикс каталога был задан как dc=ald,dc=company,dc=lan, а название экземпляра, соответственно, ALD-COMPANY-LAN. Рассмотрите самостоятельно содержимое папок /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/ и /etc/dirsrv/slapd-ALD-COMPANY-LAN/

Управление LDAP-каталогом

Для управления каталогом по протоколу LDAP можно использовать различные инструменты:

  • Apache Directory Studio — графический инструмент, который позволяет просматривать и редактировать записи и атрибуты записей;

  • ldapsearch — утилита, которая позволяет просматривать и редактировать записи и атрибуты записей;

  • dsctl – утилита управления сервисом;

  • dsconf – утилита настройки и мониторинга.

Работа с каталогом из Apache Directory Studio

Для работы с LDAP-каталогом из графического интерфейса — просмотра структуры каталога, редактирования записей, импорта и экспорта данных — можно воспользоваться таким бесплатным инструментом, как Apache Directory Studio, см. рис. 243.

../_images/aldpro_mod4_image13.png

рис. 243 Интерфейс Apache Directory Studio

Загрузить приложение можно с официального сайта. На контроллерах запускать приложение можно будет сразу, а на клиентской машине потребуется установить виртуальную машину Java (англ. Java Runtime Environment, JRE).

Для установки Apache Directory Studio необходимо:

  1. Получить актуальную ссылку на архив с программой на сайте разработчика и скачать этот архив на клиентскую виртуальную машину, например, с помощью утилиты wget.

wget https://dlcdn.apache.org/directory/studio/2.0.0.v20210717-M17/ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz

  1. Распаковать архив в текущий каталог:

tar -xvzf ApacheDirectoryStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz

  1. Установите виртуальную машину Java:

sudo apt install default-jre

Для запуска Apache Directory Studio просто кликните дважды по исполняемому файлу программы в окне файлового менеджера или выполните в окне терминала следующую команду:

~/ApacheDirectoryStudio/ApacheDirectoryStudio
Настройка соединения

Чтобы подключиться к LDAP-каталогу, нужно создать новое подключение через меню LDAP ‣ New connection…. Откроется окно для создания нового подключения, см. рис. 244.

../_images/aldpro_mod4_image14.png

рис. 244 Настройка нового LDAP-подключения

Важно

По умолчанию Apache Directory Studio предлагает создать незащищенное подключение на порт 389, что допустимо только при обращении к каталогу по localhost, т.е. приложение должно быть установлено непосредственно на контроллере домена, т.к. при подключении пароль будет передаваться в открытом виде.

Если вы подключаетесь к каталогу с другого компьютера в сети, обязательно используйте порт 636 и метод шифрования SSL, чтобы перехват пароля был невозможен.

Аутентификация по паролю называется также привязкой (от англ. bind), поэтому поле для ввода имени пользователя называется Bind DN or user, см. рис. 245. В этом поле можно указать как имя суперпользователя каталога cn=Directory Manager, так и полное отличительное имя пользователя, например, доменного администратора uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan.

Перед закрытием окна проверьте настройку текущего подключения нажатием кнопки Check Authentication, см. рис. 245.

../_images/aldpro_mod4_image16.png

рис. 245 Настройка аутентификации для нового LDAP-подключения

После добавления подключения новый сервер появится в списке Connections. Вы сможете подключиться к нему, кликнув дважды по строке с названием подключения. В зависимости от выбранной учетной записи у вас будут разные права на доступ к записям и атрибутам.

Давайте разберем три типовых операции: просмотр и экспорт объектов каталога, просмотр схемы каталога.

Просмотр и экспорт объектов каталога

Вы можете просмотреть записи в дереве каталога, выбрав нужный RDN на вкладке LDAP Browser. Например, если вы выберите в дереве узел cn=accounts, то основные атрибуты этой записи отобразятся в центральном окне с заголовком cn=accounts,dc=ald,dc=company,dc=lan, см. рис. 246.

../_images/aldpro_mod4_image17.png

рис. 246 Окно LDAP Browser

Если вы знаете полное имя записи, то сможете перейти к ней сразу из меню Navigate ‣ Go to DN. Например, если вы подключились к каталогу с помощью учетной записи суперпользователя cn=Directory Manager, то сможете таким образом открыть ветку cn=config с настройками сервера, которая по умолчанию скрыта.

Рассмотрим несколько полезных DN:

  • cn=users,cn=accounts,суффикс_домена — содержит учетные записи пользователей домена. У каждого пользователя есть атрибуты uid (логин), uidNumber (идентификатор безопасности), gidNumber (идентификатор безопасности первичной группы), userPassword (хеш пароля для LDAP-аутентификации), krbPrincipalKey (ключи для Kerberos-аутентификации), ipaNTHash (хеш пароля для NTLM-аутентификации).

  • cn=groups,cn=accounts,суффикс_домена — содержит записи групп пользователей. Список участников группы задается множественным атрибутом member. В учетных записях пользователей эта информация кэшируется в атрибуте memberof, что позволяет существенно ускорить получение информации об участии пользователя в группах.

    В службе каталогов MS AD у пользователей тоже есть атрибут memberof для ускорения запросов, но он содержит только группы прямого участия, то есть не учитывает механизм наследования участия для вложенных групп. Полным аналогом будет атрибут tokenGroups, который содержит идентификаторы SID всех групп, участником которых является пользователь прямо или опосредованно. Учтите только, что ни один из этих атрибутов не отображается на вкладке Attribute Editor в окне свойств пользователя и вы не сможете увидеть атрибут tokenGroups в Apache Directory Studio.

  • cn=computers,cn=accounts,суффикс_домена — содержит учетные записи компьютеров, которые используют атрибут krbPrincipalKey так же как пользователи для хранения Kerberos-ключей, а атрибут userPassword в качестве одноразового пароля для присоединения компьютеру к домену без использования учетной записи привилегированного пользователя домена.

  • cn=hostgroups,cn=accounts,суффикс_домена — содержит записи групп компьютеров, например, ipaservers.

  • cn=orgunits,cn=accounts,суффикс_домена — содержит записи структурных подразделений ALD Pro, ссылки на которые есть у пользователей, компьютеров и групп, см. атрибут rbtadp.

  • cn=dns,суффикс_домена — содержит записи службы доменных имен.

Используя Apache Directory Studio, вы можете также экспортировать объекты каталога, см. рис. 247:

  1. Щелкните по RDN cn=users в дереве правой кнопкой мыши.

  2. В контекстном меню выберите пункт Export.

  3. В дополнительном меню выберите нужный формат — CSV Export.

../_images/aldpro_mod4_image18.png

рис. 247 Экспорт объектов в CSV

Просмотр схемы каталога

В программе Apache Directory Studio можно легко посмотреть структуру каталога, которую называют схемой. Выберите Root DSE в дереве LDAP Browser и выполните команду меню LDAP ‣ Open Schema Browser, см. рис. 248:

../_images/aldpro_mod4_image19.png

рис. 248 Меню Open Schema Browser

По умолчанию в Schema Browser открывается страница для просмотра классов объектов (Object Classes). Вы можете делать поиск и просматривать детали (Details). Например, введите в фильтр «posix», и вы найдете обсуждаемые ранее классы posixAcccount и posixGroup, как показано на рисунке рис. 249:

../_images/aldpro_mod4_image20.png

рис. 249 Schema Browser и вкладка Object Classes

Для перехода к другим группам объектов используйте ярлычки в нижней части вкладки. Для просмотра атрибутов откройте страницу :menuselection:Attribute Types. В этом окне можно искать по списку всех атрибутов и просматривать детали выбранного атрибута. Например, введите в поле фильтра «gid», и вы увидите несколько атрибутов, в именах которых содержится эта подстрока, см. рис. 250:

../_images/aldpro_mod4_image21.png

рис. 250 Schema Browser и вкладка Attribute Types

Утилиты ldap-utils

Для работы с LDAP-каталогом из командной строки используются утилиты пакета ldap-utils:

  • Утилита ldapwhoami — выполняет подключение к каталогу и возвращает имя текущего пользователя.

  • Утилита ldapsearch — выполняет поиск по каталогу с указанными параметрами.

  • Утилита ldapadd — позволяет создать новые записи в каталоге.

  • Утилита ldapdelete — позволяет удалить записи из каталога.

  • Утилита ldapmodify — позволяет изменить атрибуты существующей записи в каталоге.

  • Утилита ldapcompare — позволяет сравнить текущее значение атрибута конкретной записи с желаемым значением и получить результат в формате TRUE/FALSE.

  • Утилита ldapexop — позволяет выполнять расширенные операции, добавленные разработчиками конкретного LDAP-сервера. Расширенные операции подобны хранимым процедурам SQL и позволяют расширять возможности взаимодействия с сервером без внесения изменений в LDAP-протокол.

  • Утилита ldappasswd — позволяет сбросить пароль для учетной записи.

  • Утилита ldapmodrdn — позволяет переименовывать существующие объекты каталога.

Подключение к LDAP-каталогу

Подключение к LDAP-каталогу происходит в рамках каждого вызова указанных выше утилит. Вы можете задавать параметры подключения в явном виде либо полагаться на настройки по умолчанию, описанные в файле /etc/ldap/ldap.conf.

admin@dc-1:~$ cat /etc/ldap/ldap.conf
...
TLS_CACERT      /etc/ssl/certs/ca-certificates.crt

URI ldaps://dc-1.ald.company.lan
BASE dc=ald,dc=company,dc=lan
SASL_MECH GSSAPI

Где:

  • TLS_CACERT — путь к сертификату для установления безопасного соединения по протоколу LDAPS или для включения шифрования STARTTLS внутри небезопасного соединения.

  • URI — адрес сервера для подключения по умолчанию.

  • BASE — отличительное имя базовой записи по умолчанию.

  • SASL_MECH — механизм для простого уровня аутентификации и безопасности (англ. Simple Authentication and Security Layer, SASL). По умолчанию используется .

При вводе компьютера в домен файл /etc/ldap/ldap.conf настраивается автоматически. По умолчанию подключение будет выполняться по протоколу LDAPS с использованием Kerberos-аутентификации через общий программный интерфейс сервисов безопасности (англ. Generic Security Services API, GSSAPI). В качестве сервера для подключения будет использоваться тот контроллер, через который хост был введен в домен.

Удалите кэш из связки ключей и проверьте возможность подключения к каталогу командой ldapwhoami:

admin@dc-1:~$ kdestroy
admin@dc-1:~$ ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
        additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (No Kerberos credentials available (default cache: KEYRING:persistent:491200000))

Ошибка «No Kerberos credentials available» говорит о том, что вы не имеете Kerberos-билета в связке ключей. Выполните Kerberos-аутентификацию и попробуйте запустить команду ldapwhoami еще раз:

admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:******
admin@dc-1:~$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: admin@ALD.COMPANY.LAN
SASL SSF: 256
SASL data security layer installed.
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan

Теперь у нас получилось выполнить запрос к LDAP-серверу, т.к. в связке ключей был валидный TGT-билет, и система смогла с его помощью успешно получить сервисный билет на доступ к LDAP-серверу. Проверить кэш можно командой klist без параметров:

admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_JxM2PBY
Default principal: admin@ALD.COMPANY.LAN

Valid starting      Expires             Service principal
02.05.2025 09:58:25 03.05.2025 09:58:01 ldap/dc-1.ald.company.lan@ALD.COMPANY.LAN
02.05.2025 09:58:08 03.05.2025 09:58:01 krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Как вы видите, в кэше появился билет ldap/dc-1.ald.company.lan, поэтому вы можете обращаться к LDAP-каталогу с помощью утилит из пакета ldap-utils без необходимости ввода учетных данных.

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

ldapwhoami -H ldap://dc-1.ald.company.lan -ZZ -x -W \
  -D "uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan"

Где:

  • Ключ -H — позволяет указать хост для подключения и протокол в явном виде, например, ldaps://dc-1.ald.company.lan.

    В качестве протокола можно использовать нешифрованный LDAP или шифрованный LDAPS. Вы можете выполнять подключение к LDAP-каталогу также через UNIX-сокет, если утилита запускается на том же сервере. Тогда нужно указать ldapi://%2fvar%2frun%2fslapd-ALD-COMPANY-LAN.socket.

  • Ключ -ZZ — позволяет включить шифрование внутри небезопасного протокола LDAP. Устанавливает требование использовать только шифрованное соединение, поэтому если сервер не поддерживает TLS, то соединение будет разорвано.

    Есть еще ключ -Z, который означает необходимость отправки серверу запроса STARTTLS, но если сервер не поддерживает TLS, обмен продолжится по небезопасному протоколу.

    Рекомендуется использовать ключ -ZZ или явно указывать протокол LDAPS.

  • Ключ -x — указывает на необходимость выполнить простую аутентификацию по логину/паролю вместо SASL.

  • Ключ -W — указывает, что пароль должен быть предоставлен в интерактивном режиме (а если нужно передать пароль в параметре, то это можно сделать с помощью ключа -w).

  • Ключ -D — задает отличительное имя DN пользовательской записи, которую нужно использовать для аутентификации, например:

    • для администратора домена uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan;

    • для суперпользователя каталога cn=Directory Manager.

Поиск по каталогу ldapsearch

Для поиска информации вы можете использовать утилиту ldapsearch, которая извлекает из каталога набор записей с указанными атрибутами в соответствии с заданными критериями фильтрации. Синтаксис команды в общем виде выглядит следующим образом:

ldapsearch [options] [filter [attributes…]]

Где:

  • options — определяют параметры подключения, для простоты мы будем использовать параметры по умолчанию.

  • filter — задает точные критерии поиска записей.

  • attributes — список атрибутов, которые нужно извлечь из каталога.

Для примера напишем запрос, который будет выдавать список всех пользователей домена из записи cn=users, которая, в свою очередь, является потомком записи cn=accounts, и все они находятся в пространстве корневого суффикса dc=ald,dc=company,dc=lan. Таким образом, полным уникальным именем записи, в которой хранятся пользователи, будет cn=users,cn=accounts,dc=ald,dc=company,dc=lan.

Выполните поиск по каталогу с помощью команды ldapsearch:

ldapsearch -Q -s sub -b "cn=users,cn=accounts,dc=ald,dc=company,dc=lan" \
  '(uid=*)' uid givenName sn

Где:

  • Ключ -Q — включает тихий режим SASL, в котором не выводится информация о SASL-подключении. Режим полезен при автоматизации для того, чтобы исключить техническую информацию.

    Можно дополнительно указать ключ -LLL, который определяет формат вывода: первый ключ -L ограничит формат до LDIFv1, второй отключит комментарии, а третий уберет вывод версии LDIF.

  • Ключ -s — определяет область поиска (scope), параметр может принимать следующие значения:

    • one — поиск выполняется по дочерним записям на один уровень ниже в иерархии;

    • sub — поиск выполняется по всем дочерним записям (значение по умолчанию);

    • children — то же, что и sub, но ограничивает поиск только прямыми потомками базовой записи;

    • base — ограничивает поиск базовой записью, которая задана параметром -b.

  • Ключ -b — задает базовую запись (base), которая будет использоваться в качестве начального узла для поиска по дереву.

  • Параметр '(uid=*)' — определяет критерий поиска. В приведенном примере запрашиваются все записи, у которых задано значение атрибута uid. Фильтры и составные фильтры мы рассмотрим далее.

  • Параметры uid givenName sn — определяют список атрибутов, которые нужно извлечь из каталога для найденных записей. Если этот список не задать явно, то по умолчанию будут извлечены все хранимые атрибуты, как если бы был указан символ '*'. Чтобы извлечь все операционные атрибуты, нужно указать символ '+'. Если вы хотите извлечь сразу и хранимые и операционные атрибуты, то нужно указать оба символа подряд '*' '+'.

Дополнительно можно использовать ключ -d для изменения уровня отладки, предствляющий собой битовую маску от 0 до 65535, в которой каждый бит соответствует определенной категории сообщений отладки:

  • 1 — LDAP_DEBUG_TRACE

  • 2 — LDAP_DEBUG_PACKETS

  • 4 — LDAP_DEBUG_ARGS

  • 8 — LDAP_DEBUG_CONNS

  • 16 — LDAP_DEBUG_BER

  • 32 — LDAP_DEBUG_FILTER

  • 64 — LDAP_DEBUG_CONFIG

  • 128 — LDAP_DEBUG_ACL

  • 256 — LDAP_DEBUG_STATS

  • 512 — LDAP_DEBUG_STATS2

  • 1024 — LDAP_DEBUG_SHELL

  • 2048 — LDAP_DEBUG_PARSE

  • 16384 — LDAP_DEBUG_SYNC

  • 32768 — LDAP_DEBUG_NONE

После выполнения запроса вы получите следующий результат:

# extended LDIF
#
# LDAPv3
# base <cn=users,cn=accounts,dc=ald,dc=company,dc=lan> with scope subtree
# filter: (uid=*)
# requesting: uid givenName sn
#

# admin, users, accounts, ald.company.lan
dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
uid: admin
sn: Administrator

# iivanov, users, accounts, ald.company.lan
dn: uid=iivanov,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
uid: iivanov
givenName:: 0JjQstCw0L0=
sn:: 0JjQstCw0L3QvtCy

# ppetrov, users, accounts, ald.company.lan
dn: uid=ppetrov,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
uid: ppetrov
givenName:: 0J/QtdGC0YA=
sn:: 0J/QtdGC0YDQvtCy

#...

# search result
search: 4
result: 0 Success

# numResponses: 8
# numEntries: 7

Результат выполнения запроса выводится в поток stdout в формате LDIF, и его можно передавать по конвейеру (pipeline) или перенаправить в файл для последующей обработки. Подробнее о формате LDIF мы поговорим далее.

Как уже упоминалось ранее, кроме обычных хранимых атрибутов, есть еще служебные атрибуты, которые встроены в LDAP-сервер и называются операционными атрибутами. Большинство операционных атрибутов доступны только для чтения, и, чтобы их увидеть, необходимо указать '+' в списке атрибутов. Например, с помощью следующего запроса вы можете увидеть, что запись cn=users имеет операционный атрибут numSubordinates, в котором содержится число дочерних записей:

ldapsearch -Q -LLL -s base \
  -b "cn=users,cn=accounts,dc=ald,dc=company,dc=lan" '+'

Результат выполнения команды:

  admin@dc-1:~$ ldapsearch -Q -LLL -s base \
  >  -b "cn=users,cn=accounts,dc=ald,dc=company,dc=lan" '+'
  dn: cn=users,cn=accounts,dc=ald,dc=company,dc=lan
  creatorsName: cn=Directory Manager
  modifiersName: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
  createTimestamp: 20250428191035Z
  modifyTimestamp: 20250428192224Z
  nsUniqueId: 7662c78e-246411f0-81d3c33d-ecd7a769
  parentid: 2
  entryid: 3
  entryUUID: b969ca8f-78f1-43f7-bf07-662a779383bf
  entryusn: 11700
  numSubordinates: 7
  ...

О том, как составлять фильтры, добавлять записи, изменять атрибуты, вы сможете узнать в нашем расширенном курсе «Автоматизация задач администрирования через LDAP-запросы».

Утилита управления сервисом dsctl

Как мы уже говорили, для запуска, остановки и перезагрузки служб FreeIPA следует использовать утилиту ipactl. Но для управления отдельными экземплярами LDAP-каталога вам нужно будет воспользоваться утилитой dsctl. С ее помощью вы сможете:

  • Запускать, перезапускать, останавливать, получать статус и уничтожать экземпляр каталога (команды start, restart, stop, status, remove).

  • Управлять базой данных: выполнять переиндексацию базы данных, резервное копирование и восстановление, выгружать дамп в LDIF-файл и восстанавливать каталог из дампа, выполнять проврку целостности каталога (db2index, db2bak, bak2db, db2ldif, ldifdb2, dbverify).

  • Производить проверку здоровья экземпляра (healthcheck).

  • И многое другое.

Произведем проверку здоровья нашего экземпляра ALD-COMPANY-LAN:

admin@dc-1:~$ sudo dsctl ALD-COMPANY-LAN healthcheck
Beginning lint report, this could take a while ...
Checking config:hr_timestamp ...
Checking config:passwordscheme ...
Checking backends:changelog:cl_trimming ...
Checking backends:changelog:mappingtree ...
...
No issues found.

Сравним db2bak и db2ldif. Обе команды для создания резервной копии требуют остановки службы каталога. Файлы по умолчанию будут сохранены в подкаталогах /bak/ и /ldif/ директории /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/. Принципиальное отличие между командами только в формате бэкапа: команда db2bak создает полную резервную, в которую попадают в том числе бинарные файлы индексов, а команда db2ldif создает один ldif-файл просто с данными.

Создадим резервную копию и дамп:

admin@dc-1:~$ sudo ipactl stop
Stopping ipa-dnskeysyncd Service
...
ipa: INFO: The ipactl command was successful

admin@dc-1:~$ sudo dsctl ALD-COMPANY-LAN db2bak
...
db2bak successful

admin@dc-1:~$ sudo dsctl ALD-COMPANY-LAN db2ldif userRoot
...
db2ldif successful

admin@dc-1:~$ sudo ipactl start
...
ipa: INFO: The ipactl command was successful

Проверим созданные файлы:

admin@dc-1:~$ sudo ls -l /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/bak
итого 4
drwx------ 4 dirsrv dirsrv 4096 ср  2 11:23 ALD-COMPANY-LAN-2025_04_02_11_23_51

admin@dc-1:~$ sudo ls -l /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/ldif
итого 6104
-rw------- 1 dirsrv dirsrv 3120670 ноя  2 11:35 ALD-COMPANY-LAN-userroot-2025_04_02_11_35_21.ldif

Утилита настройки и мониторинга dsconf

Утилита dsconf — это мощное средство для настройки и мониторинга сервера 389 Directory Server, у которого только справка под 7 тысяч строк, см. man dsconf. Мы не будем подробно разбирать все возможности этой утилиты, но покажем пару полезных приемов.

Резервное копирование

Утилита dsconf в отличии от dsctl позволяет выполнять резервное копирование без остановки службы каталога:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN backup create
The backup create task has finished successfully

Проверим созданный нами файл:

admin@dc-1:~$ sudo ls -l /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/bak
итого 8
drwx------ 4 dirsrv dirsrv 4096 ср  2 11:23 ALD-COMPANY-LAN-2025_11_02_11_23_51
drwx------ 4 dirsrv dirsrv 4096 ср  2 11:48 ALD-COMPANY-LAN-2025_11_02_11_48_56
Просмотр и изменение настроек сервера 389ds

Для просмотра настроек сервера можно воспользоваться командой config get. Настроек довольно много, поэтому выведем на экран только те из них, которые относятся к управлению паролями:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN config get | grep password
nsslapd-allow-hashed-passwords: on
passwordAdminDN:
passwordBadWords:
passwordChange: on
passwordCheckSyntax: off
passwordDictCheck: off
passwordDictPath:
passwordExp: off
passwordGraceLimit: 0
passwordInHistory: 6
passwordIsGlobalPolicy: off
passwordLegacyPolicy: on
passwordLockout: off
passwordLockoutDuration: 3600
passwordMaxAge: 8640000
passwordMaxClassChars: 0
passwordMaxFailure: 3
passwordMaxRepeats: 0
passwordMaxSeqSets: 0
passwordMaxSequence: 0
passwordMin8bit: 0
passwordMinAge: 0
passwordMinAlphas: 0
passwordMinCategories: 3
passwordMinDigits: 0
passwordMinLength: 8
passwordMinLowers: 0
passwordMinSpecials: 0
passwordMinTokenLength: 3
passwordMinUppers: 0
passwordMustChange: off
passwordPalindrome: off
passwordResetFailureCount: 600
passwordSendExpiringTime: off
passwordStorageScheme: PBKDF2-SHA512
passwordTPRDelayExpireAt: -1
passwordTPRDelayValidFrom: -1
passwordTPRMaxUse: -1
passwordTrackUpdateTime: off
passwordUnlock: on
passwordUserAttributes:
passwordWarning: 86400

Следует учитывать, что политики паролей в службе каталога FreeIPA реализованы собственными средствами, поэтому не все параметры 389 Directory Server будут работать так, как ожидается. Например, фильтром запрещенных слов passwordBadWords воспользоваться у вас не получится, но эту функцию для FreeIPA команда ALD Pro планирует адаптировать уже в одном из следующих релизов.

Давайте изменим схему хранения паролей passwordStorageScheme с безопасного, но ресурсоемкого алгоритма PBKDF2-SHA512 на алгоритм попроще и побыстрее SSHA512, чтобы существенно увеличить скорость LDAP Bind операции.

Текущее значение настройки можно посмотреть следующей командой:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN config get passwordStorageScheme
passwordStorageScheme: PBKDF2-SHA512

Установить новое значение можно следующей командой:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN config replace passwordStorageScheme=SSHA512
selinux is disabled, will not relabel ports or files.
Successfully replaced "passwordStorageScheme"

С помощью следующей команды вы можете убедиться, что изменение схемы хранения не повлияло на пароль пользователя admin, который был установлен ранее:

ldapsearch -H ldaps://dc-1.ald.company.lan \
  -o ldif-wrap=no -D 'cn=Directory Manager' -W \
  -b 'uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan' \
  | grep 'userPassword::' | cut -d" " -f 2 | base64  -d

Результат выполнения:

{PBKDF2-SHA512}10000$Dtq6lpYFcu1uLuUMs3lYFswkAermaOln$KRCzVfS3IUIv7zN+jvlbEe7DIXLDfsShEod4H5FADXDfZUv1UUBVqCpTxSzlXlMoMg5LHzlbWSh0rT0Ndh1ZaA==

Смените пароль пользователю, например, с помощью утилиты kpasswd, повторите выполнение команды и убедитесь, что способ хеширования действительно изменился на SSHA512:

{SSHA512}3vQIJJDlA5mmj/ouIFjY1uuyHcuiDuQdiNTaEt9thneV5ZK6seJAWdaibAZpfcmeB63poARbQTRanckARmYzEOU5FB3YWFNu

Кроме команд get и replace доступны также add и delete. Дополнительную справку по командам можно получить с помощью ключа -h:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN config -h
usage: dsconf instance config [-h] {get,add,replace,delete} ...

positional arguments:
{get,add,replace,delete}
                      action
  get                 get
  add                 Add attribute value to configuration
  replace             Replace attribute value in configuration
  delete              Delete attribute value in configuration

Сервер MIT Kerberos krb5-kdc

Основным протоколом аутентификации в службе каталога FreeIPA является Kerberos V5, работу которого обеспечивает эталонная реализация центра распространения ключей (англ. Key Distribution Center, KDC) от Массачусетского технологического института (агл. Massachusetts Institute of Technology, MIT).

Когда пользователь делает вход в операционную систему доменного компьютера или выполняет аутентификацию утилитой kinit, запрос отправляется службе KDC. При успешной проверке аутентичности клиенту выдается TGT-билет, с помощью которого он может в дальнейшем проходить прозрачную аутентификацию на любом контроллере домена без повторного ввода пароля, чтобы получать сервисные билеты для аутентификации в керберизированных сервисах.

В основе протокола Kerberos лежит идея доверия:

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

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

  • Сервис транзитивно доверяет клиенту, т.к. ему доверяет контроллер, которому доверяет сам сервис.

В дальнейшем это доверие может быть расширено на взаимодействие между доменами или, как говорят, областями действия Kerberos, тогда мы получаем следующую схему:

  • Контроллер из домена А доверяет клиенту из домена А, т.к. они оба владеют общим ключом, в роли которого выступает пароль пользователя.

  • Сервис из домена Б доверяет контроллеру из домена Б, т.к. они оба владеют общим ключом, в роли которого выступает пароль сервиса.

  • Сервис из домена Б доверяет клиенту из домена A, т.к. оба домена владеют общим ключом, в роли которого выступает пароль объекта доверительных отношений, который создается в момент установления доверительных отношений между доменами.

Запутанно? А в лесу доменов MS AD может быть вообще несколько уровней доменов, между которыми устанавливаются транзитивные доверительные отношения, тогда возникает целая цепочка рекурсивных Kerberos-запросов, как в детской песенке:

Вот дом, который построил Джек.

А это пшеница, которая в тёмном чулане хранится в доме, который построил Джек.

А это весёлая птица-синица, которая часто ворует пшеницу, которая в тёмном чулане хранится в доме, который построил Джек.

…

Центр распространения ключей MIT KDC тесно интегрирован с LDAP-каталогом с помощью плагина ipa-kdb, который позволяет извлекать из службы каталога не только аутентификационную информацию, но и поддерживает генерацию авторизационной структуры данных MS-PAC с информацией об участии пользователя в группах, что требуется для интеграции с MS AD.

В архитектуре KDC иногда выделяют две отдельные службы:

  • Сервер аутентификации (Authentication Server, AS), который отвечает за аутентификацию пользователей и выдачу TGT-билетов, поэтому должен иметь доступ к паролям пользователей.

  • Сервер выдачи разрешений (Ticket Granting Server, TGS), который отвечает за выдачу сервисных TGS-билетов, поэтому должен иметь доступ к паролям сервисов.

Однако на практике обе службы обычно реализованы вместе под общим названием Центра распространения ключей (KDC) и такие детали можно считать несущественными.

Если не вдаваться в детали, которых будет предостаточно в следующем модуле, то процедура аутентификации по протоколу Kerberos состоит из следующих шагов, см. рис. 251:

  1. Клиент отправляет контроллеру запрос на аутентификацию (AS_REQ).

  2. Контроллер выдает клиенту TGT-билет (AS_REP). Билет зашифрован мастер-ключом KDC, поэтому может быть проверен любым контроллером в домене.

  3. Клиент отправляет контроллеру запрос на получение сервисного билета для аутентификации, например, на файловом сервере (TGS_REQ), прилагая полученный ранее TGT-билет. Запрос может быть обработан любым контроллером в домене, т.к. все они располагают мастер-ключом, которым зашифрован TGT-билет.

  4. Контроллер выдает клиенту TGS-билет (TGS_REP). Билет зашифрован паролем сервиса, поэтому может быть проверен сервисом самостоятельно без обращения к контроллеру.

  5. Клиент обращается к сервису (AP_REQ), прилагая полученный ранее TGS-билет. Запрос может быть обработан сервисом, т.к. он располагает своим ключом, которым зашифрован TGS-билет.

  6. Сервис подтверждает аутентичность пользователя и устанавливает с ним сессию (AP_REP).

../_images/aldpro_mod4_image22.png

рис. 251 Взаимодействие клиента с компонентами KDC в ходе аутентификации по протоколу Kerberos V5

Как вы можете заметить, ответственность за передачу билетов по протоколу Kerberos V5 возлагается на клиента, а для проверки аутентичности пользователя сервису не требуется обращаться к контроллеру домена. Керберизированные сервисы могут, конечно, обращаться к контроллеру по протоколу LDAP для извлечения авторизационной информации об участии пользователя в группах, но при использовании MS-PAC даже этого не требуется — пользователь приходит с билетом, в котором уже содержится вся необходимая информация.

Подробно Kerberos-аутентификацию мы рассмотрим в следующем модуле, а сейчас давайте сведем все новые технические термины в один список:

  • Аутентификация — процедура проверки подлинности, т.е аутентичности пользователя, например, на основании того, что обеим сторонам известен общий секрет.

  • Авторизация — процедура предоставления пользователю прав доступа на выполнение определённых действий. Обычно права доступа назначаются не на конкретных пользователей, а на группы, поэтому информацию об участии пользователей в группах считают авторизационной информацией.

  • Область действия Kerberos (англ. Realm) — совокупность пользователей и компьютеров, пароли которых хранятся в единой базе данных. Совпадает с DNS-именем домена, но пишется заглавными буквами, например, ALD.COMPANY.LAN.

  • Имя принципала (англ. Principal) — это строка, уникально идентифицирующая учетную запись пользователя, компьютера или керберизированной службы в домене. Принадлежность принципала к области Kerberos задается как в адресе электронной почты с помощью символа собачки @, например, admin@ALD.COMPANY.LAN.

  • Имя сервиса (англ. Service Principal Name, SPN) — это имя принципала для сервиса, которое уникально идентифицирует учетную запись сервиса в домене. В именах сервисов может указываться имя хоста, на котором эта служба работает в домене, например, HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN.

  • TGT-билет (Ticket-Granting Ticket) — билет, который позволяет клиенту проходить прозрачную аутентификацию на контроллерах домена без ввода пароля для получения сервисных билетов, которые необходимы для аутентификации в керберизированных сервисах. Называется также билетом для получения других билетов, удостоверением или мандатом.

  • TGS-билет (Ticket-Granting Service Ticket) — билет, который позволяет клиенту проходить прозрачную аутентификацию без ввода пароля в керберизированном сервисе, для которого этот билет был выдан. Называется так же сервисным билетом, удостоверением или мандатом сервиса.

  • AS_REQ/AS_REP – запрос к серверу аутентификации (Authentication Server, AS) центра распространения ключей Kerberos для получения TGT-билета и ответ от него соответственно.

  • TGS_REQ/TGS_REP – запрос к серверу выдачи разрешений (Ticket Granting Server, TGS) центра распространения ключей Kerberos для получения TGS-билета и ответ от него соответственно.

Как мы уже сказали, более подробно процесс Kerberos-аутентификации мы рассмотрим в следующем модуле, см. Модуль 5. Работа Linux-компьютера в домене.

Сервер Samba

Разработчики компании Red Hat изначально работали над развитием службы каталога Samba AD и только когда поняли, что, подстраиваясь под Windows, хорошую службу каталога для Linux не сделать, запустили проект FreeIPA. В то же время, когда им потребовалось реализовать интеграцию с MS AD, они задействовали свои старые наработки, поэтому в контроллер FreeIPA интегрирована служба Samba AD, которая обеспечивает NTLM-аутентификацию и обслуживает SMB RPC вызовы.

Протокол SMB позволяет выполнять RPC-вызовы, поэтому с его помощью можно предоставить доступ не только к файлам и принтерам, но и выполнять другие типы запросов, которые представляются как доступ к «файлам» через общий ресурс IPC$. Существует несколько интерфейсов, которые предоставляются контроллерами домена, наиболее известными из которых являются локальная служба безопасности (англ. Local Security Authority, LSA) и служба аутентификации пользователей NETLOGON.

В момент установления доверительных отношений с MS AD контроллер FreeIPA через SMB RPC согласовывает общий секрет и другие настройки. В дальнейшем Samba участвует в формировании структуры данных MS-PAC для Kerberos-билетов, в которой содержится информация об участии пользователя в группах.

Удаленные вызовы LSA используются также для преобразования имен. Например, когда вы в Windows открываете свойства папки, в списке доступа ACL хранятся только идентификаторы безопасности SID, но они автоматически преобразуются в имена пользователей через обращение к контроллеру по SMB протоколу на порт 445/TCP. Если контроллер будет в этот момент недоступен, то в списке так и останутся только числа.

На рис. рис. 252 показана схема взаимодействия компонентов при обработке запросов из домена Active Directory при интеграции через механизм доверительных отношений.

../_images/aldpro_mod4_image23.png

рис. 252 Схема взаимодействия компонентов FreeIPA при работе в доверительных отношениях с доменом Active Directory

Приведем краткое описание назначения компонентов:

  • DNS (bind) — служба, которая обрабатывает DNS-запросы (порты 53/UDP и 53/TCP). Взаимодействие между доменами осуществляется в первую очередь по доменным именам.

  • KDC (MIT) — служба, которая обрабатывает запросы на Kerberos-аутентификацию (порт 88/TCP).

  • IPA-KDB - плагин к MIT KDC от разработчиков FreeIPA для получения информации из LDAP-каталога с сопоставлением атрибутов и записей по схеме Kerberos.

  • EPM (Endpoint Mapper) - служба, которая предоставляет клиентам RPC-сервис для определения параметров дальнейшего подключения к другим RPC-сервисам, таким как NETLOGON, LSA, SAMR (порт 135/TCP).

  • NETLOGON/LSARPC/SAMR — сервисы RPC для обработки запросов клиентов на NTLMSSP-аутентификацию, преобразование идентификаторов и другие операции (динамические порты).

    В преобразовании идентификаторов участвует также служба winbind, которая является клиентской частью Samba и обеспечивате работу Linux-клиента в домене. В службе каталога FreeIPA большую часть этих задач для Samba выполняет уже собственная служба sssd, с которой winbind взаимодействует через плагины.

  • IPASAM — плагин к Samba от разработчиков FreeIPA для получения информации из LDAP-каталога с сопоставлением атрибутов по схеме Active Directory.

  • libndr_krb5 - библиотека для формирования структуры данных MS-PAC с авторизационной информацией об участии пользователя в группах.

  • SMBD — служба, которая предоставляет клиентам сервисы по протоколам SMB на порту 445/TCP. Клиенты могут выполнять RPC-запросы по протоколу SMB через обращение к общему ресурсу IPC$.

Более подробно мы обсудим роль компонентов Samba в модуле, который будет посвящен интеграции с Microsoft Active Directory.

Идентификаторы безопасности

Диапазоны идентификаторов

Мы уже знаем, что для идентификации субъектов безопасности в Linux используются идентификаторы POSIX, а в Windows эту роль выполняют идентификаторы SID (англ. Security Identifiers). Однако, в то время как в Windows идентификаторы пользователей и групп находятся в одном пространстве SID, идентификаторы POSIX представляют собой два непересекающихся множества: идентификаторы пользователей находятся в пространстве UID (англ. User Identifier), а идентификаторы групп в пространстве GID (англ. Group Identifier) соответственно.

Если взять SID с номером S-1-5-21-1491017894-2377586105-2170988794-500, то по нему никак не понять, принадлежит ли он пользователю или группе, если только вы не знаете хорошо известные идентификаторы (англ. well-known SIDs), в соответствии с которыми идентификатор 500 всегда назначается администратору.

Если разложить SID на составляющие, то последнее число 500 однозначно идентифицирует субъект относительно домена, поэтому это число называется относительным идентификатором (англ. Relative Identifier, RID), а предшествующие ему три числа 1491017894-2377586105-2170988794 идентифицируют домен, поэтому для всех SID в домене эти числа имеют одно и то же значение.

Идентификаторы POSIX, так же как RID’ы, представляют собой натуральные числа в диапазоне от 0 до 2 32 (4 млрд), но не имеют уникальной доменной части, поэтому получается, что все компьютеры работают как бы в одном общем пространстве идентификаторов. Чтобы решить обозначенную проблему, в FreeIPA используют диапазоны идентификаторов (англ. ID Range), определяющие часть общего пространства идентификаторов, которые будут использоваться конкретным доменом.

Половину диапазона из 4 млрд служба каталога FreeIPA резервирует на подчиненные (subordinate) идентификаторы, и мы не будем их затрагивать, т.к. они не используются в повседневных задачах. Вторую половину служба использует для обычных пользователей и групп, но делает это крайне экономно. При установке первого контроллера система случайным образом выбирает себе ID Range емкостью 200к идентификаторов, поэтому вероятность пересечения с другим доменом будет крайне мала, всего 1 к 10 тысячам. А если 200к вам будет мало, вы сможете создать себе дополнительный диапазон любой емкости.

Как вы знаете, в MS AD одному из контроллеров назначается FSMO-роль «RID Master», после чего он получает в свое управление весь диапазон свободных идентификаторов и выдает их другим контроллерам пачками по 500 штук. Как только у кого-то из контроллеров свободных идентификаторов становится меньше 100 единиц, этот контроллер обращается к Мастеру RID, и тот выдает ему следующую пачку из 500 идентификаторов.

В службе каталога FreeIPA любой контроллер может стать Мастером RID, для этого достаточно с помощью этого контроллера создать пользователя или группу, чтобы ему потребовался идентификатор безопасности. В этом случае контроллер обратится к соседу, заберет у него половину свободного диапазона и сможет использовать эти идентификаторы для своих нужд и передавать другим контроллерам в домене по запросу.

За работу этого механизма отвечает плагин распределенного назначения идентификаторов (англ. Distributed Numeric Assignment, DNA), а часть диапазона ID Range, которым владеет конкретный контроллер домена, называется DNA ID Range. Таким образом, в домене FreeIPA мы работаем с двумя типами диапазонов идентификаторов:

  • ID Range — диапазон идентификаторов, который зарезервирован за доменом в целом.

  • DNA ID Range — диапазон распределенного назначения идентификаторов, который является подмножеством диапазона ID Range и закреплен за конкретным контроллером домена, чтобы тот мог создавать пользователей и группы автономно.

Для совместимости с Active Directory в FreeIPA всем пользователям и группам назначаются также идентификаторы SID в стиле Windows. Их значения рассчитываются математически. Сложность этих расчетов состоит в том, что в Linux мы имеем дело с двумя пространствами идентификаторов, а в Windows пространство общее. Поэтому для идентификаторов групп, которые могут совпадать с идентификаторами пользователей, резервируется дополнительно еще один диапазон RID, который называется вторичным, см. рис. 253.

../_images/aldpro_mod4_image24.png

рис. 253 Преобразование POSIX-идентификаторов (UID и GID) в идентификаторы безопасности Windows (SID)

Примерно так же работает пересчет идентификаторов SID из доверенного домена MS AD в идентификаторы POSIX. В момент установления доверительных отношений в домене FreeIPA для каждого домена из леса MS AD создается ID Range, настройки которого используются для пересчета. По умолчанию емкость этих диапазонов тоже 200к идентификаторов, но, в отличие от обычного ID Range, диапазон для доверенного домена MS AD можно расширить.

Примечание

Если в лесу MS AD после установления доверительных отношений с доменом FreeIPA будут созданы новые поддомены, то на стороне FreeIPA нужно будет повторить процедуру извлечения информации о поддоменах следующей командой:

ipa trust-fetch-domains <имя_корневого_домена_AD>

Это позволит создать для новых поддоменов диапазоны ID Range и сделает их доступными для клиентов службы каталога FreeIPA.

Просмотр диапазонов идентификаторов

Посмотреть текущие диапазоны идентификаторов домена (ID Range) можно как из веб-интерфейса ALD Pro, так и через утилиту командной строки ipa.

Для просмотра через веб-интерфейс необходимо открыть страницу Управление доменом ‣ Пользователи и группы ‣ POSIX идентификаторы. Как вы помните, существующий диапазон невозможно расширить, можно только добавить новый.

https://dc-1.ald.company.lan/ad/ui/#/domainmgmt/users-and-group-settings/id-ranges

../_images/aldpro_mod4_image26.png

рис. 254 Настройка диапазонов в веб-интерфейсе

Список всех диапазонов идентификаторов домена и их параметры можно посмотреть из окна терминала, используя команду ipa idrange-find:

admin@dc-2:~$ ipa idrange-find
-----------------
найден 1 диапазон
-----------------
  Имя диапазона: ALD.COMPANY.LAN_id_range
  Первый идентификатор POSIX диапазона: 491200000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 1000
  Первый RID вторичного диапазона RID: 100000000
  Тип диапазона: local domain range
---------------------------------
Количество возвращённых записей 1
---------------------------------

Чтобы вывести параметры определенного диапазона идентификаторов домена, следует использовать команду ipa idrange-show <Имя_Диапазона>:

admin@dc-2:~$ ipa idrange-show ALD.COMPANY.LAN_id_range
  Имя диапазона: ALD.COMPANY.LAN_id_range
  Первый идентификатор POSIX диапазона: 491200000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 1000
  Первый RID вторичного диапазона RID: 100000000
  Тип диапазона: local domain range

Просмотреть список диапазонов распределенного назначения идентификаторов (DNA ID Range) на всех контроллерах домена можно командой sudo ipa-replica-manage dnarange-show:

admin@dc-1:~$ sudo ipa-replica-manage dnarange-show
dc-1.ald.company.lan: 491200009-491399999
dc-2.ald.company.lan: No range set
...

Вывести список диапазонов только на конкретном контроллере можно так:

admin@dc-1:~$ sudo ipa-replica-manage dnarange-show dc-1.ald.company.lan
dc-1.ald.company.lan: 491200009-491399999

Выделение диапазона идентификатора вручную

В некоторых случаях вы можете захотеть создать еще один диапазон идентификаторов домена в дополнение к исходному. Например, когда исходный диапазон идентификаторов уже исчерпан. Для этого нужно выполнить следующие команды:

  1. Создадим новый диапазон идентификаторов командой sudo ipa idrange-add на dc-1:

ipa idrange-add ALD.COMPANY.LAN_second_id_range \
  --base-id=1000000 --range-size=200000 --rid-base 201000 \
  --secondary-rid-base 100200000

Результат выполнения команды

admin@dc-1:~$ ipa idrange-add ALD.COMPANY.LAN_second_id_range \
>   --base-id=1000000 --range-size=200000 --rid-base 201000 \
>   --secondary-rid-base 100200000
-------------------------------------------------------------------
Добавлен диапазон идентификаторов "ALD.COMPANY.LAN_second_id_range"
-------------------------------------------------------------------
  Имя диапазона: ALD.COMPANY.LAN_second_id_range
  Первый идентификатор POSIX диапазона: 1000000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 201000
  Первый RID вторичного диапазона RID: 100200000
  Тип диапазона: local domain range

  1. Проверим доступные диапазоны идентификаторов домена:

admin@dc-1:~$ ipa idrange-find
-------------------
найдено 2 диапазона
-------------------
  Имя диапазона: ALD.COMPANY.LAN_id_range
  Первый идентификатор POSIX диапазона: 491200000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 1000
  Первый RID вторичного диапазона RID: 100000000
  Тип диапазона: local domain range

  Имя диапазона: ALD.COMPANY.LAN_second_id_range
  Первый идентификатор POSIX диапазона: 1000000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 201000
  Первый RID вторичного диапазона RID: 100200000
  Тип диапазона: local domain range
---------------------------------
Количество возвращённых записей 2
---------------------------------

При создании диапазона идентификаторов ID Range соответствующий ему динамический диапазон DNA ID Range не создается автоматически, поэтому его нужно будет создать вручную. Для управления диапазонами DNA ID Range предназначены команды утилиты ipa-replica-manage.

Текущие настройки диапазона можно посмотреть командой dnarange-show:

admin@dc-1:~$ sudo ipa-replica-manage dnarange-show dc-1.ald.company.lan
dc-1.ald.company.lan: 491200009-491399999

Давайте назначим dc-1 новый диапазон, для этого воспользуемся командой dnarange-set:

admin@dc-1:~$ sudo ipa-replica-manage dnarange-set dc-1.ald.company.lan 1000000-1199999

У реплик может быть не только основной, но и дополнительный диапазон идентификаторов DNA ID Range, который они начнут использовать, когда в текущем диапазоне закончатся свободные идентификаторы. Давайте в качестве следующего диапазона назначим оставшиеся идентификаторы из диапазона, который был создан при установке системы. Чтобы назначить следующий диапазон идентификаторов DNA конкретному серверу, используйте команду dnanextrange-set.

admin@dc-1:~$ sudo ipa-replica-manage dnanextrange-set dc-1.ald.company.lan 491200009-491399999

Посмотрим, что у нас получилось:

admin@dc-1:~$ sudo ipa-replica-manage dnarange-show dc-1.ald.company.lan
dc-1.ald.company.lan: 1000000-1199999
admin@dc-1:~$ sudo ipa-replica-manage dnanextrange-show dc-1.ald.company.lan
dc-1.ald.company.lan: 491200009-491399999

Примечание

Как правило, служба sssd может работать с новым диапазоном службы каталога FreeIPA сразу без выполнения дополнительных действий. Если у вас появятся какие-либо проблемы с новыми пользователями, то выполните очистку кэша службы sssd на проблемном компьютере командой sudo sssctl cache-remove (потребуется установить пакет apt install sssd-tools).

Практика и тестирование

Заключение

В этом модуле мы познакомились с составом службы каталога ALD Pro, рассмотрели ее компоненты и научились с ними работать. Мы узнали, что такое идентификаторы безопасности и диапазоны идентификаторов, и в общих чертах посмотрели на процесс Kerberos-аутентификации.

В следующем модуле мы познакомимся со способами аутентификации и с устройством службы sssd, обеспечивающей работу компьютера в домене.

Дополнительные источники информации

Обратная связь

Если остались вопросы, то их всегда можно задать в специальной теме.