Модуль 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. Общая архитектура решения представлена на рис. 206.

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

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

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

../_images/aldpro_mod4_image4.png

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

Внешние клиенты, например, агент групповых политик 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 для построения своего домена, команда разработчиков проекта FreeIPA ставит сейчас своей целью заимствовать у Microsoft лучшие бизнес-решения для построения домена для Linux-инфраструктуры. Именно по этой причине система унаследовала от Active Directory многие концепции, такие как:

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

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

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

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

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

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

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

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

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

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

  • Дополнительно с помощью Samba AD может быть активирована интеграция с Active Directory, а с помощью DogTag реализована работа с сертификатами.

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

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

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

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

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

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

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

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

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

../_images/aldpro_mod4_image5.png

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

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

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

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

  • Политика – политики паролей, билетов Kerberos, HBAC-правила, SUDO-правила, Parsec.

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

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

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

Утилита ipactl

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

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

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

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

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

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

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

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, который устанавливается на всех компьютерах в домене. Для ее использования ничего дополнительно устанавливать не требуется.

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

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

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

Параметры подключения задаются в конфигурационном файле /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 = Non

Где параметры определяют:

  • basedn — DN базовой записи для выполнения запросов по умолчанию. Если параметр не задан, то basedn вычисляется из параметра domain. Используется, например, утилитой ipa-client-automount.

  • realm — Область Kerberos, параметр является обязательным на IPA-сервере.

  • domain — Домен IPA-сервера для извлечения SRV-записей вида _ldap._tcp.domain. Кроме того, из domain вычисляется basedn, если basedn не настроен. Параметр является обязательным

  • server — fqdn-имя IPA-сервера для подключения.

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

  • xmlrpc_uri — URL-адрес для отправки XML-RPC запросов на сервер. Используется как утилитой IPA, так и дополнительными инструментами, например, утилитой ipa-getcert.

При выборе FreeIPA-сервера для подключения утилита руководствуется следующим алгоритмом:

  1. Проверяет доступность сервера, который задан параметром xmlrpc_uri.

  2. Проверяет сервер, который задан параметром server.

  3. Выполняет автоматическое обнаружение LDAP-сервиса через DNS по SRV-записям вида _ldap._tcp.domain.

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

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;

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

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

На контроллерах домена с конфигурационным файлом /etc/ipa/default.conf работает не только утилита IPA, но и API-бэкенд, поэтому его содержимое несколько отличается:

[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

Где параметры сервера определяют:

  • ldap_uri — Путь к файлу сокета LDAP-сервера, по которому API будет взаимодействовать с каталогом.

  • mode — Режим, в котором работает IPA-сервер. При работе в режиме production не выполняются некоторые функции самотестирования, что повышает производительность бэкенда.

  • enable_ra — Возможность сервера выполнять функции агента, удостоверяющего центр для регистрации сертификатов. Для использования этой функции на сервере должен быть установлен CA DogTag

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

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                         Диапазоны идентификаторов
...

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

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

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

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

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

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

Команда

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

ipa user-add

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

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

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 — Глобальные параметры; например, ключ -d включает вывод отладки, который можно просмотреть командой ipa -h;

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

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

Запрос к серверу можно отследить в журнале access, см. рис. 208.

../_images/aldpro_mod4_image6.png

рис. 208 Проверка поиска в журнале access

Давайте запросим информацию о пользователе с логином 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:

admin@dc-1:~$ 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: 198800000
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
  Поля поиска пользователей: uid,givenname,sn,telephonenumber,ou,title
  Поля поиска групп: cn,description
  Включить режим миграции: FALSE
  Основа субъекта сертификата: O=ALD.COMPANY.LAN
  Уведомление об окончании действия пароля (в днях): 4
  Возможности подключаемого модуля паролей: AllowNThash, KDC:Disable Last Success
  Порядок применения списка пользователей SELinux: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Пользователь SELinux по умолчанию: unconfined_u:s0-s0:c0.c1023
  Типы PAC по умолчанию: MS-PAC, nfs:NONE
  Главные IPA-серверы: dc-1.ald.company.lan
  Главный IPA-сервер с поддержкой PKINIT: dc-1.ald.company.lan
  DNS-серверы IPA: dc-1.ald.company.lan
Просмотр информации об учетной записи пользователя ipa user-show

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

admin@dc-1:~$ ipa user-show svetlakovi
Имя учётной записи пользователя: svetlakovi
Имя: Иван
Фамилия: Светлаков
Домашний каталог: /home/svetlakovi
Оболочка входа: /bin/bash
Имя учётной записи: svetlakovi@ALD.COMPANY.LAN
Псевдоним учётной записи: svetlakovi@ALD.COMPANY.LAN
Адрес электронной почты: svetlakovi@ald.company.lan
UID: 296400023
ID группы: 296400023
Учётная запись отключена: 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: Organization units
Доступные ключи Kerberos: True

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

admin@dc-1:~$ ipa user-show semenov.ii --rights --all

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

dn: uid=semenov.ii,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
Имя учётной записи пользователя: semenov.ii
Имя: Иван
Фамилия: Семенов
...
Indirect Member of role: Organization units`
Доступные ключи Kerberos: True
attributelevelrights: {'objectclass': 'rscwo', 'aci': 'rscwo', 'sn': 'rscwo', 'cn': 'rscwo', 'userpassword': 'swo', 'telephonenumber': 'rscwo', 'seealso': 'rscwo', 'description': 'rscwo', 'title': 'rscwo', 'x121address': 'rscwo', 'registeredaddress': 'rscwo', 'destinationindicator':
...
'ipantsecurityidentifier': 'rscwo', 'ipanthash': 'wo', 'ipantlogonscript': 'rscwo',
'ipantprofilepath': 'rscwo', 'ipanthomedirectory': 'rscwo', 'ipanthomedirectorydrive': 'rscwo',
'nsaccountlock': 'rscwo'}`
ipantsecurityidentifier: S-1-5-21-2487214781-2721300798-1427603078-1022
ipauniqueid: 9a6804e2-9509-11ee-88d1-9a8351765b26
krbextradata: AAII0XFlcm9vdC9hZG1pbkBBTEQuQ09NUEFOWS5MQU4A
krbprincipalkey: MIHeoAMCAQGhAwIB4......zx2QRSivSy8TN0eotHcVzqXA
mepmanagedentry: cn=semenov.ii,cn=groups,cn=accounts,dc=ald,dc=company,dc=lan
objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount,
krbprincipalaux, krbticketpolicyaux,
ipaobject, ipasshuser, x-ald-user, x-ald-user-parsec14, x-ald-audit-policy, rbta-unit, rbta-address,
rbtaCustomUserAttrs, rbta-inetorgperson-ext, ruPostMailAccount, rbtaUserMeta,
ipaSshGroupOfPubKeys, mepOriginEntry,
ipantuserattrs
x-ald-aud-mask: 0x0:0x0
x-ald-user-mac: 0:0x0:0:0x0

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

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

Разрешение

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

r

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

s

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

w

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

o

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

c

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

W

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

O

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

Создание пользователя ipa user-add

Для создания пользователя используется команда ipa user-add c параметрами, см. табл. 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-каталога, состоит из нескольких компонентов доменного имени dc (domain component), например: dc=ald,dc=company,dc=lan.

{domain_suffix}

Это суффикс домена в формате fqdn-имени: ald.company.lan.

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

admin@dc-1:~$ ipa user-add semenov.ii \
--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"

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

----------------------------------
Добавлен пользователь "semenov.ii"
----------------------------------
  Имя учётной записи пользователя: semenov.ii
  Имя: Иван
  Фамилия: Семенов
  Полное имя: Семенов И.И.
  Отображаемое имя: Семенов И.И.
  Инициалы: И.И.
  Домашний каталог: /home/semenov.ii
  GECOS: Иван Семенов
  Оболочка входа: /bin/bash
  Имя учётной записи: semenov.ii@ALD.COMPANY.LAN
  Псевдоним учётной записи: semenov.ii@ALD.COMPANY.LAN
  Окончание действия учётной записи Kerberos: 20240306000000Z
  Окончание действия пароля пользователя: 20240306000000Z
  Адрес электронной почты: semenov.ii@ald.company.lan
  Случайный пароль: 9MpD,DN3AkAqdj-L!+vaP
  UID: 296400022
  ID группы: 296400022
  Адрес: Ленина, 1
  Город: Москва
  Область/республика: Московская область
  Индекс: 101
  Номер телефона: +71234567890
  Номер мобильного телефона: +71234567890
  Номер факса: +71234567890
  Отдел: Отдел АСУ
  Должность: Инженер первой категории
  Номер отдела: Департамент 1
  Номер сотрудника: 1
  Тип сотрудника: Категория 1
  Минимальный уровень конфиденциальности: 0
  Максимальный уровень конфиденциальности: 0
  Middle name: Иванович
  Contry: RU
  proxy addresses: SMTP:SEMENOV.II@ALD.COMPANY.LAN
  Пароль: True
  Участник групп: ipausers
  Роли: Organization units
  Indirect Member of group: ipausers
  Доступные ключи Kerberos: True

Обратите внимание на случайный пароль 9MpD,DN3AkAqdj-L!+vaP, который был сгенерирован системой автоматически. Он будет нужен пользователю для первого входа в систему.

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

admin@dc-1:~$ echo AstraLinux_174 | ipa user-add semenov.ia \
--first="Иван" --last="Семенов" \
--password --password-expiration="$(date +'%Y%m%d000000Z' -d '+90 days')"

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

----------------------------------
Добавлен пользователь "semenov.ia"
----------------------------------
  Имя учётной записи пользователя: semenov.ia
  Имя: Иван
  Фамилия: Семенов
  Полное имя: Иван Семенов
  Отображаемое имя: Иван Семенов
  Инициалы: ИС
  Домашний каталог: /home/semenov.ia
  GECOS: Иван Семенов
  Оболочка входа: /bin/bash
  Имя учётной записи: semenov.ia@ALD.COMPANY.LAN
  Псевдоним учётной записи: semenov.ia@ALD.COMPANY.LAN
  Окончание действия пароля пользователя: 20240925000000Z
  Адрес электронной почты: semenov.ia@ald.company.lan
  UID: 310400013
  ID группы: 310400013
  Минимальный уровень конфиденциальности: 0
  Максимальный уровень конфиденциальности: 0
  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
  Роли: Organization units
  Доступные ключи Kerberos: True
Изменение параметров пользователя ipa user-mod

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

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

admin@dc-1:~$ ipa user-mod semenov.ii \
--department="ou=kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan"

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

---------------------------------
Изменён пользователь "semenov.ii"
---------------------------------
  Имя учётной записи пользователя: semenov.ii
  Имя: Иван
  Фамилия: Семенов
...
  Link to department: ou=kazan,ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
...

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

admin@dc-1:~$ ipa user-mod semenov.ii \
--phone "+71122334455" --email "semenov.ii@kaz.ald.company.lan"

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

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

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

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

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

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

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

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

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

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

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

admin@dc-1:~$ ipa user-mod --random svetlakovi

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

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

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

admin@dc-1:~$ ipa user-mod svetlakovi --password-expiration 20250101115110Z

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

Активация и деактивация учетной записи ipa user-disable/user-enable

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бэкенд команды 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 svetlakovi
--------------------------------
Удален пользователь "svetlakovi"
--------------------------------

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

../_images/aldpro_mod4_image7.png

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

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

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

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

ipa user-undel svetlakovi
-----------------------------------------------------------------
Учётная запись пользователя "svetlakovi" возвращена после удаления
-----------------------------------------------------------------

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

Утилита ipa-getkeytab

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

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

Содержимое keytab файла представляет собой бинарные данные, содержащий один или несколько записей Kerberos. Посмотреть содержимое можно утилитой klist.

В качестве примера использования утилиты добавим сервисный принципал HTTP/pc-1.ald.company.lan в IPA, а затем используем утилиту ipa-getkeytab для получения keytab-файла для этого принципала:

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 -k /etc/http.keytab
Keytab name: FILE:/etc/http.keytab
KVNO Principal
---- -----------------------------------------------------------
  1 HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN
  1 HTTP/pc-1.ald.company.lan@ALD.COMPANY.LAN

Где в команде ipa-getkeytab:

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

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

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

При вызове утилиты klist ключ -k позволяет прочитать указанный keytab-файл.

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

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

admin@dc-1:~$ sudo klist -k /home/admin/iivanov.keytab
Keytab name: FILE:/home/admin/iivanov.keytab
KVNO Principal
---- ------------------------------------------------------------
   2 iivanov@ALD.COMPANY.LAN
   2 iivanov@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, выбирая их из списка. Без глобального каталога поиск по объектам доверенного домена работать не будет.

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

../_images/aldpro_mod4_image8.png

рис. 210 Переинициализация контроллера домена

Сервер 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), что повысит производительность бэкенда до 10 раз.

Каталог LDAP

Облегченный протокол доступа к данным каталога (Lightweight Directory Access Protocol, LDAP) является упрощенной модификацией более строгих стандартов для построения службы распределенного каталога сети X.500.

Каталог LDAP является специализированной нереляционной базой данных, файлы которой вы найдете в папке /var/lib/dirsrv/slapd-ald-company-lan/db. Информация каталога представлена в виде древовидной структуры, которую также называют Directory Information Tree или сокращенно DIT, см. рис. 211.

../_images/aldpro_mod4_image9.png

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

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

Корень 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, которые записывают через запятую слева направо, начиная с целевой записи и до корневого суффикса вверх по иерархии, см. рис. 212. Если привести аналогию с объектами файловой системы, то RDN будет соответствовать имени объекта директории или файла, а DN — полному имени объекта файловой системы, которое включает путь к родительскому объекту и имени объекта. И так же как на одном диске не может быть двух директорий с одинаковыми полными именами, в каталоге LDAP не может быть двух записей с одинаковыми DN. Описание формата DN можно найти в RFC 4514.

../_images/aldpro_mod4_image10.png

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

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

Помимо хранимых атрибутов, в каталоге LDAP есть также служебные или операционные атрибуты. Они не содержат пользовательских данных, а вместо этого обеспечивают структуру каталога и связи между объектами. Примеры служебных атрибутов включают objectClass, objectCategory, entryUUID и другие.

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

../_images/aldpro_mod4_image11.png

рис. 213 Наличие атрибута 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, см. рис. 214.

../_images/aldpro_mod4_image12.png

рис. 214 Использование атрибута 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 соответствует целым числам. Описание всех типов данных можно найти в RFC4517.

  • 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/ содержит резервные копии

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

    • /var/lib/dirsrv/slapd-<название-Экземпляра>/ldif/

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

    • /etc/dirsrv/config/ – конфигурационные файлы.

    • /etc/dirsrv/schema/ – схема каталога.

    • /etc/dirsrv/ssca/ – самоподписанный сертификат, сертификаты и ключи.

    • /etc/dirsrv/slapd-<название-Экземпляра>/schema/ – схема экземпляра, в том числе и определяемая пользователем (файл 99user.ldif).

  • Каталог /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 – утилита управления сервисом;

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

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

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

../_images/aldpro_mod4_image13.png

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

Загрузить приложение можно с официального сайта. На контроллерах можно будет запускать приложение сразу, а на клиентской машине потребуется установить пакет jre командой sudo apt install default-jre.

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

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

  2. Скачать этот архив на клиентскую виртуальную машину pc-1.ald.company.lan, воспользовавшись, например, программой curl, в домашний каталог пользователя.

admin@pc-1:~$ curl https://dlcdn.apache.org/directory/studio/2.0.0.v20210717-M17/ApacheDirector
yStudio-2.0.0.v20210717-M17-linux.gtk.x86_64.tar.gz --out ApacheDirectoryStudio.tar.gz
 % Total    % Received % Xferd  Average Speed   Time    Time     Time   Current
                                Dload  Upload   Total   Spent    Left   Speed
 100  133M  100  133M    0    0  8582k      0  0:00:15  0:00:15 --:--:-- 10.2M
  1. Распаковать архив.

admin@pc-1:~$ tar -xvzf ApacheDirectoryStudio.tar.gz
ApacheDirectoryStudio/
ApacheDirectoryStudio/plugins/
ApacheDirectoryStudio/plugins/org.eclipse.osgi.nl_fr_4.7.0.v20171231020002.jar
ApacheDirectoryStudio/plugins/org.eclipse.osgi.util.nl_de_4.7.0.v20171231020002.jar
. . .
admin@pc-1:~$ ls ./ApacheDirectoryStudio
ApacheDirectoryStudio      artifacts.xml  features LICENSE  p2
ApacheDirectoryStudio.ini  configuration  icon.xpm  NOTICE  plugins

Для запуска Apache Directory Studio просто вызовите этот исполнимый файл без параметров.

admin@pc-1:~$ ~/ApacheDirectoryStudio/ApacheDirectoryStudio
Настройка соединения

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

../_images/aldpro_mod4_image14.png

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

Важно

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

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

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

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

../_images/aldpro_mod4_image16.png

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

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

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

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

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

../_images/aldpro_mod4_image17.png

рис. 218 Окно LDAP Browser

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

Изучите некоторые полезные DN:

cn=accounts,dc=ald,dc=company,dc=lan

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

cn=groups,cn=accounts,суффикс_домена

Содержит записи групп пользователей.

cn=computers,cn=accounts,суффикс_домена

Содержит учетные записи компьютеров.

cn=hostgroups, cn=accounts,суффикс_домена

Содержит записи групп компьютеров, например, ipaservers.

cn=users,cn=accounts,суффикс_домена

Содержит учетные записи пользователей домена.

cn=orgunits,cn=accounts,суффикс_домена

Содержит записи структурных подразделений ALD Pro, ссылки на которые есть у пользователей, компьютеров и групп, см. атрибут rbtadp.

cn=dns,суффикс_домена

Содержит записи службы доменных имен.

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

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

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

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

../_images/aldpro_mod4_image18.png

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

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

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

../_images/aldpro_mod4_image19.png

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

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

../_images/aldpro_mod4_image20.png

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

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

../_images/aldpro_mod4_image21.png

рис. 222 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.

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

Проверьте доступ в каталог командой ldapwhoami:

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:1000))

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

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ldapwhoami
Password for admin@ALD.COMPANY.LAN:
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:1000:1000
Default principal: admin@ALD.COMPANY.LAN

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

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

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

admin@dc-1:~$ ldapsearch -H dc-1.ald.company.lan -ZZ -x -W \
-D "uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan" \
-b "cn=users,cn=accounts,dc=ald,dc=company,dc=lan" \
'(uid=\*)' uid givenName sn

Где:

  • Ключ -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

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

    • Для пользователя admin: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan.

    • Или суперпользователя Directory Manager: cn=Directory Manager.

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

Поиск по каталогу 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:

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

Где:

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

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

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

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

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

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

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

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

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

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

# 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

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

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

# search result
search: 4
result: 0 Success

# numResponses: 4
# numEntries: 3

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

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

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: 20230324160645Z
modifyTimestamp: 20230324161206Z
nsUniqueId: df91d884-ca5d11ed-b5f0ee72-e6acffe1
parentid: 2
entryid: 3
entryusn: 6055
numSubordinates: 6
...

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

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

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

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

  • Управлять базой данных: переиндексация базы данных, резервное копирование и восстановление, дамп в LDIF-файл и восстановление из дампа, проверка (db2index, db2bak, bakdb2, db2ldif, ldifdb2, dvverify)

  • Производить проверку здоровья экземпляра (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:

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

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

  • При вызове команды dsctl <экземпляр> db2ldif необходимо указать бэкенд и файл для записи, например, cоздадим резервную копию и дамп:

admin@dc-1:~$ sudo ipactl stop
Stopping ipa-dnskeysyncd Service
Stopping ipa-otpd Service
Stopping winbind Service
Stopping smb Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping named Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory 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
ldiffile: /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/ldif/userroot.ldif
db2ldif successful
admin@dc-1:~$ sudo ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting named Service
Starting httpd Service
Starting ipa-custodia Service
Starting smb Service
Starting winbind Service
Starting ipa-otpd Service
Starting ipa-dnskeysyncd Service
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-2023_11_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-2023_11_02_11 _35_21.ldif

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

Утилита dsconf — это мощное средство с обширным функционалом для настройки и мониторинга сервера 389ds. Одних строк справочных страниц по этой утилите более 7500 man dsconf. Конечно, мы не будем подробно разбирать работу с ней в рамках данного курса, однако несколько приемов работы с ней мы рассмотрим.

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

Как и dsctl, 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-2023_11_02_11_23_51
drwx------ 4 dirsrv dirsrv 4096 ноя  2 11:48 ALD-COMPANY-LAN-2023_11_02_11_48_56
Просмотр и изменение настроек сервера 389ds

Для просмотра настроек сервера воспользуемся командой config get:

sudo dsconf ALD-COMPANY-LAN config get
nsslapd-lookthroughlimit: 100000
nsslapd-mode: 600
nsslapd-idlistscanlimit: 100000
nsslapd-directory: /var/lib/dirsrv/slapd-ALD-COMPANY-LAN/db
nsslapd-import-cachesize: 16777216
nsslapd-idl-switch: new
. . .

Как видите, их довольно много:

admin@dc-1:~$ sudo dsconf ALD-COMPANY-LAN config get | wc
   370     939   17707

Например, выведем только те, что относятся к настройкам паролей:

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

Давайте изменим один из параметров. Например, в истории паролей, зададим значение 10 вместо 6. Для этого воспользуемся командой dsconf ALD-COMPANY-LAN config replace:

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

Кроме команд get и replace существуют еще add и delete:

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, работу которого обеспечивает центр распространения ключей MIT Kerberos KDC.

Когда пользователь выполняет вход в систему или запускает команду kinit, запрос на аутентификацию уходит на сервер Kerberos или так называемый Центр распространения ключей (англ. Key Distribution Center, 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-билетов, поэтому должен располагать информацией о паролях сервисов.

    При этом оба сервера должны располагать общим мастер-ключом, чтобы TGT-билеты, зашифрованные AS-сервером, могли быть расшифрованы на стороне TGS-сервера.

../_images/aldpro_mod4_image22.png

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

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

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

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

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

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

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

  5. Клиент обращается к сервису (AP_REQ).

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

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

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

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

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

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

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

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

  • Имя сервиса (англ. Service Principal Name, SPN) — это имя принципала для сервиса, которое уникально идентифицирует учетную запись службы на контроллере домена.

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

  • TGS-билет, сервисный билет, удостоверение или мандат (ticket-granting service ticket) — билет, который позволяет клиенту проходить аутентификацию в керберизированном сервисе, для которого этот билет был выдан.

  • AS_REQ – запрос к службе аутентификации (AS).

  • AS_REP – ответ от службы аутентификации (AS).

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

Более подробно процесс Kerberos-аутентификации мы рассмотрим в следующем модуле, посвященном работе компьютера в домене.

Сервер Samba

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

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

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

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

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

../_images/aldpro_mod4_image23.png

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

Кратко перечислим назначение компонентов:

  • smbd — служба предоставляет клиентам сервисы по протоколам SMB на порту 445/TCP.

  • nmbd — служба обеспечивает клиентам поддержку сервера имен NetBIOS.

  • Winbind — служба обеспечивает работу клиента в домене. В доверительных отношениях сервер FreeIPA является клиентом по отношению к домену MS AD и наоборот. Функции Winbind в домене FreeIPA практически полностью заменены службой SSSD, за исключением таких атавизмов, как NTLM, поэтому Winbind пока еще остается.

  • Netlogon/LSARPC/SAMR — модули для обслуживания RPC-вызовов.

  • IPASAM — плагин, который позволяет Samba AD получить доступ к основным данным каталога FreeIPA с сопоставлением атрибутов по схеме Active Directory.

  • libndr_krb5 - библиотека для формирования MS-PAC сертификата.

Более подробно мы обсудим роль компонентов Samba в модуле, который будет посвящен интеграции c 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 до 232 (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, который называется вторичным, см. рис. 225.

../_images/aldpro_mod4_image24.png

рис. 225 Соотношение диапазонов ID Range и DNA ID Range

Примерно так же работает пересчет идентификаторов 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

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

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

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

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

admin@dc-1:~$ ipa idrange-show ALD.COMPANY.LAN_id_range
Имя диапазона: ALD.COMPANY.LAN_id_range
Первый идентификатор POSIX диапазона: 1902000000
Количество идентификаторов в диапазоне: 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: 1902000008-1902199999
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: 1902000008-1902199999

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

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

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

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

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

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

Чтобы назначить текущий DNA диапазон идентификаторов конкретному серверу, используйте команду ipa-replica-manage dnarange-set:

root@dc-1:~# ipa-replica-manage dnarange-set serverA.example.com 1250-1499

Чтобы определить следующий DNA диапазон идентификаторов конкретному серверу, используйте команду ipa-replica-manage dnanextrange-set:

root@dc-1:~# ipa-replica-manage dnanextrange-set serverB.example.com 1500-5000

Примечание

Как правило, служба SSSD может работать с новым диапазоном службы каталога FreeIPA сразу без выполнения дополнительных действий. Если у вас появятся какие-либо проблемы с новыми пользователями, то выполните следующее:

  1. Сделайте очистку кэша службы SSSD на проблемном компьютере командой sudo sss_cache -E (может потребоваться установить пакет sudo apt install sssd-tools).

  2. Перезапустите службу SSSD: systemctl restart sssd

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

Заключение

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

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

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