Модуль 3. Базовые функции и настройка ALD Pro

Введение

В этом модуле мы будем ближе знакомиться с порталом управления и разбираться, как в домене работают базовые сетевые сервисы NTP и DNS. Если вы ранее администрировали домен Active Directory, то эти технологии и концепции должны быть вам вполне знакомы и нужно будет только понять принципиальные отличия.

Хотелось бы уже захватить работу групповых политик, но ввиду важности этой темы мы все-таки лучше посвятим ей отдельный модуль. Как говорится, лучше меньше да лучше, а слишком хорошо – тоже нехорошо.

Портал управления ALD Pro

Архитектура портала управления

Основным интерфейсом администратора в ALD Pro является Портал управления, который покрывает функции таких оснасток Windows, как Server Manager, Users and Computers, Group Policy Management Editor, Domains and Trusts и многих других.

Портал управления представляет собой веб-приложение, разработанное на языке Python с использованием фреймворка Django. Запросы пользователей принимает веб-сервер Apache и передает Python-приложению через WSGI (англ. Web Server Gateway Interface), а клиентская часть написана на React и взаимодействует с сервером через JSON API.

Программные интерфейсы бэкенда могут быть использованы сторонними разработчиками для интеграции своих собственных приложений со службой каталога. Например, с помощью API был написан скрипт policy.py для импорта дополнительных параметров групповых политик. А еще в плейбуках продукта Astra Automation через обращение к API выполняется установка дополнительных контроллеров домена.

В соответствии с диаграммой развертывания портал управления устанавливается на каждом контроллере домена ALD Pro, и вы можете обращаться к любому из этих экземпляров, так как все они работают с данными из общего LDAP-каталога, см. рис. 204. Любые изменения в части пользователей, групп, настроек домена будут автоматически реплицированы на все контроллеры в домене средствами LDAP-каталога 389 Directory Server.

рис. 204 Архитектура портала управления

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

Вместе с тем, у каждого экземпляра веб-портала есть и собственная СУБД реляционного типа, в роли которой выступает PostgreSQL, но с версии ALD Pro 2.4.x в ней хранятся только вспомогательные данные, поэтому любой портал управления покажет вам актуальную информацию, которая уже стала доступна контроллеру через механизм репликации.

Начиная с версии ALD Pro 2.4.x, продукт не использует больше компонент Salt Master на контроллере домена и установка дополнительных подсистем выполняется автономной службой aldpro-salt-minion, которая получает всю необходимую информацию через LDAP.

При назначении доменному компьютеру какой-то из ролей ALD Pro, бэкенд портала управления вносит соответствующие изменения в его учетную запись. Для этого учетным записям серверов назначается класс rbta-subsystem, который объединяет целый ряд атрибутов с префиксом rbtaSubsystem* (rbtaSubsystemConfig, rbtaSubsystemLog, rbtaSubsystemMetainfo, rbtaSubsystemRole, rbtaSubsystemSite, rbtaSubsystemState и rbtaSubsystemVersionAld).

Через некоторое время после внесения изменения на портале управления служба aldpro-salt-minion, работающая на целевом хосте, обратится в LDAP-каталог и проверит значения этих атрибутов, чтобы привести сервер к указанному состоянию. Таким образом выполняется установка, обновление или удаление подсистемы, более детально об этом процессе, см. Модуль 7. Дополнительные подсистемы ALD Pro.

Вход в портал управления

Портал управления поддерживает два способа входа: по логину/паролю и через прозрачную Kerberos-аутентификацию.

Аутентификация по паролю

Портал управления реализует собственную веб-форму для входа по логину/паролю, которая передает данные на сервер через POST-запрос в открытом виде, поэтому при использовании такого способа аутентификации нужно обязательно защищать соединение шифрованием SSL, см. рис. 205.

рис. 205 Данные при аутентификации по паролю передаются POST-запросом в открытом виде, поэтому требуется защищенное HTTPS-соединение

Шифрование нужно еще и по той причине, что после аутентификации в каждом запросе к серверу будет передаваться CSRF-токен, который является временным аутентификатором пользователя, поэтому для обеспечения безопасности портал ALD Pro запрещает работу по протоколу HTTP и автоматически перенаправляет пользователей на протокол HTTPS, защищенный шифрованием.

Прозрачная Kerberos-аутентификация

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

1. Пользователь нажимает на кнопку Вход с Kerberos, которая расположена в правом нижнем углу формы аутентификации.

2. Браузер клиента отправляет POST-запрос на адрес https://dc-1.ald.company.lan/ad/api/ds/login/kerberos, для которого в настройках веб-сервера включена Kerberos-аутентификация.

3. Веб-сервер видит, что для запрашиваемой страницы требуется Kerberos-аутентификация, поэтому возвращает ответ со статусом 401 Unauthorized и заголовком «WWW-Authorization: Negotiate», который указывает на необходимость аутентификации с использованием механизма SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) через NTLM или Kerberos.

   

   рис. 206 Аутентификация на портале через SPNEGO по Kerberos V5

4. Браузер проверяет, что на веб-сайте с адресом https://dc-1.ald.company.lan можно выполнять аутентификацию по механизму SPNEGO, и запрашивает через GSSAPI билет для аутентификации в сервисе HTTP/dc-1.ald.company.lan. Если в связке ключей нет требуемого TGS-билета, но есть TGT-билет, то GSSAPI сделает запрос TGS-REQ на контроллер домена для получения запрашиваемого билета.

5. Контроллер домена, получив валидный запрос TGS-REQ, возвращает ответ TGS-REP, внутри которого находится TGS-билет и сессионный ключ из этого билета для аутентификации в сервисе.

6. Браузер, получив TGS-билет от GSSAPI, формирует запрос AP-REQ, кодирует его в base64 и передает веб-серверу в заголовке «WWW-Authorization: Negotiate base64(AP-REQ)». Адрес запроса остается прежний, как на втором шаге https://dc-1.ald.company.lan/ad/api/ds/login/kerberos.

7. Веб-сервер извлекает AP-REQ из заголовка и передает его службе GSS-Proxy, которая имеет доступ к keytab-файлу службы HTTP/dc-1.ald.company.lan и может проверить валидность запроса. Служба GSS-Proxy подтверждает веб-серверу, что запрос валиден, тогда веб-сервер генерирует новый CSRF-токен и передает его в ответе с успешным статусом 200 OK.

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

Обратите внимание, что в инспекторе браузера на вкладке Сеть шаги #3 и #6 отображаться не будут. На запрос #2 мы сразу получим ответ #7, так как запросы SPNEGO обрабатываются на уровне GSSAPI и не доходят до веб-страницы.

Как было сказано ранее, на шаге #4 браузер должен был проверить, что сайту разрешено запрашивать аутентификацию по механизму SPNEGO. На контроллерах домена штатным браузером является Firefox, и эта настройка задается в файле /usr/lib/firefox/distribution/policies.json следующим образом:

cat /usr/lib/firefox/distribution/policies.json
{
   "policies": {
      "BlockAboutAddons": true,
      "BlockAboutConfig": true,
      "Authentication": {
         "SPNEGO": ["ald.company.lan"]
      },
      "Certificates": {
         "ImportEnterpriseRoots": true,
         "Install": ["/etc/ipa/ca.crt"]
      },
      "Homepage": {
         "URL": "https://dc-1.ald.company.lan/",
         "Locked": true,
         "StartPage": "homepage-locked"
      }
   }
}

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

На том же четвертом шаге программный интерфейс GSSAPI должен был запросить TGS-билет, но сделать он это сможет только в том случае, если в связке ключей будет валидный TGT-билет. Проверить связку ключей пользователя можно с помощью команды klist. Если билета нет, его можно получить командой kinit <имя_пользователя>.

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

klist

Команда очистки кэша связки ключей:

kdestroy

Команда получения TGT-билета для пользователя admin:

kinit admin

Продемонстрируем полную очистку кэша и повторную аутентификацию, в результате выполнения команд видим новый krbtgt-билет:

admin@dc-1:~$ kdestroy
Other credential caches present, use -A to destroy all
admin@dc-1:~$ klist
klist: Credentials cache keyring 'persistent:491200000:krb_ccache_djyB8Wd' not found`
admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:491200000:krb_ccache_djyB8Wd
Default principal: admin@ALD.COMPANY.LAN

Valid starting        Expires              Service principal
02.04.2025 20:13:22   03.04.2025 20:13:18  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN`

При наличии действительного TGT-билета в связке ключей вы можете на портале управления кликнуть по ссылке Вход с Kerberos. После успешного входа в связке ключей вы увидите TGS-билет для аутентификации в службе HTTP/dc-1.ald.company.lan.

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

Valid starting       Expires Service      principal
02.04.2025 20:13:29  03.04.2025 20:13:18  HTTP/dc-1.ald.company.lan@ALD.COMPANY.LAN
02.04.2025 20:13:22  03.04.2025 20:13:18  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN`

Как уже было сказано, дальнейшая проверка аутентичности пользователя подтверждается CSRF-токеном, который отправляется на веб-сервер в каждом запросе, поэтому Kerberos-ключи больше не потребуются, и их можно даже удалить.

Интерфейс портала управления

Итак, вы открыли портал управления, см. рис. 207.

рис. 207 Портал управления ALD Pro

В правом верхнем углу есть пять иконок:

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

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

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

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

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

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

Управление доменом

• Общая информация

  • Работоспособность домена — отображает основные показатели серверной группировки, если установлена и работает подсистема мониторинга.

  • Состав системы — отображает список хостов, роль которых была повышена до одной из подсистем. В версии 2.4.0 появилась активная ссылка, которая ведет на карточку подсистемы, см. рис. 208.

    

    рис. 208 Карточка контроллера dc-1.ald.company.lan

  • Граф топологии — показывает принадлежность контроллеров домена к сайтам (локациям) и как они связаны соглашениями о репликации. По умолчанию отображаются контроллеры только из сайта «Головной офис». Чтобы изменить критерии отбора, воспользуйтесь кнопкой Фильтр.

  • Параметры домена — тут вы найдете версию ALD Pro, имя Kerberos-области и уровень домена FreeIPA.

• Сайты и службы

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

    При обращении клиента к SRV-записям _kerberos._tcp.полное_имя_домена DNS-сервер из сайта hq перенаправит запрос на _kerberos._tcp.hq._locations.полное_имя_домена с помощью CNAME-записи, где для серверов из того же сайта hq приоритет будет равен нулю, поэтому клиент отдаст им предпочтение.

  • Контроллеры домена — на этой странице можно увидеть полный перечень всех контроллеров домена и выполнить повышение роли сервера до контроллера домена.

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

• Доп. параметры групповых политик — раздел позволяет создавать кастомные параметры групповых политик, которые являются аналогом ADMX-шаблонов Microsoft Active Directory. Вы можете определить перечень атрибутов и задать Salt-скрипт, с помощью которого этот параметр будет применяться на рабочих станциях.

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

• Службы и параметры Kerberos

  • Службы — на этой странице вы можете создать служебную учетную запись для Kerberos-аутентификации пользователей в вашем приложении. По умолчанию в домене есть учетные записи для DNS, HTTP, CIFS, LDAP, ipa-dnskeysyncd.

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

  • Политика билетов Kerberos — на этой странице вы можете задать срок жизни Kerberos-билетов (по умолчанию 24 часа или 86400 секунд), и максимальный срок обновления, на протяжении которого клиент сможет продлевать их действие (по умолчанию 7 дней или 604 800 секунд).

    Обратите внимание, что на доменных компьютерах в файле /etc/sssd.conf параметры krb5_lifetime, krb5_renewable_lifetime и krb5_renew_interval не заданы, поэтому служба SSSD по умолчанию запрашивает необновляемые билеты.

• Пользователи и группы

  • Параметры пользователей — на этой странице вы можете определить параметры для новых пользователей. Будьте осторожны с назначением дополнительных объектных классов — если вы добавите объектный класс, который определяет обязательный атрибут, то создание и редактирование пользователей через веб-интерфейс станет невозможным.

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

  • POSIX идентификаторы — на этой странице вы можете настроить диапазоны идентификаторов для пользователей и групп. По умолчанию в домене создается диапазон емкостью в 200k идентификаторов, поэтому при превышении этого значения нужно будет создать дополнительный диапазон вручную.

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

    Фактические значения будут храниться в атрибуте user-custom-attr в json-формате. В момент создания атрибута вы можете определить тип данных, который определит внешний вид поля на карточке пользователя: логическое значение, дата и время, строка, номер телефона, число.

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

  Модуль миграции похож на инструмент ADMT (Active Directory Migration Tool) и рекомендуется для выполнения разовых миграций небольших организаций, в которых не более 2k сотрудников. Модуль синхронизации обеспечивает поддержание целостности информации в двух доменах, включая пароли пользователей, и рассчитан на длительное гибридное развертывание инфраструктур любого масштаба.

• Роли и права доступа — на этой странице вы можете создавать «метароли» системы ALD Pro, привилегии которых поддерживают привязку к структурным подразделениям. При активации метароли создаются соответствующие привилегии и разрешения системы FreeIPA, которые регулируют права доступа к объектам LDAP-каталога на уровне инструкций доступа ACI (англ. Access Control Instructions).

Пользователи и компьютеры

• Организационная структура — на этой странице вы можете создавать подразделения (англ. organizational unit, OU), выстраивая организационно-штатную структуру компании. Структурные подразделения являются доработкой ALD Pro, этой функции нет в службе каталога FreeIPA. Через структурные подразделения назначаются групповые политики и выполняется разделение зон ответственности между системными администраторами.

• Пользователи, группы пользователей, компьютеры, группы компьютеров — на этих страницах вы можете создавать объекты каталога, редактировать их атрибуты и выполнять с ними ряд других действий. Эти вкладки выполняют функции, аналогичные тем, что предоставляет оснастка Users and Computers в Active Directory.

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

Групповые политики

• Групповые политики — в этом разделе вы можете создавать объекты групповых политик ALD Pro, наполнять их параметрами и назначать на структурные подразделения. Механизм наследования и суммирования параметров приближен к Active Directory. На стороне рабочих станций параметры применяются с использованием Salt-скриптов.

• Политики доступа к узлу — в этом разделе вы можете настраивать HBAC-правила FreeIPA для ограничения доступа к узлам. Механизм работает на основе PAM.

• Политики повышения привилегий — на этой странице вы можете настраивать SUDO-правила FreeIPA для предоставления пользователям прав на выполнение отдельных команд с повышенными привилегиями через утилиту sudo.

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

Установка и обновление ПО

• Политики ПО — в этом разделе вы можете создавать объекты групповых политик ALD Pro для установки программного обеспечения, наполнять их параметрами из каталога ПО и назначать их на структурные подразделения.

• Каталог ПО — раздел позволяет создавать параметры групповых политик для установки программного обеспечения. Вы можете добавить deb-пакеты для установки, определить перечень атрибутов и задать шаблоны конфигурационных файлов.

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

• Репозитории ПО — в этом разделе можно выполнить повышение роли сервера до подсистемы репозиториев программного обеспечения (Reprepro) и увидеть перечень таких серверов.

• Политики обновления ALD Pro — в этом разделе вы можете создавать объекты групповых политик ALD Pro для обновления клиентской части продукта до последней версии из указанных репозиториев. Политики обновления можно назначать на компьютеры или группы компьютеров.

Автоматизация

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

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

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

• Установка ОС по сети — в этом разделе можно выполнить повышение роли сервера до подсистемы установки ОС по сети (TFTP HPA + PXE) и увидеть перечень таких серверов. Вы сможете создавать профили загрузки и назначать их на устройства с указанием MAC-адреса. Как только устройство с указанным MAC-адресом обратится к PXE-серверу, ему будет передан индивидуальный конфигурационный файл, содержание которого определяется настройками профиля.

Роли и службы сайта

• Служба разрешения имен — в этом разделе вы можете настроить работу встроенного DNS-сервера (BIND9). По умолчанию в домене создаются как минимум прямая и обратная зоны, вы можете настроить также перенаправление зон для интеграции с MS AD и разрешение публичных имен через внешний глобальный перенаправитель.

• Служба динамической настройки узла — в этом разделе можно выполнить повышение роли сервера до подсистемы динамической настройки узлов (ISC DHCP) и увидеть перечень таких серверов.

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

• Служба синхронизации времени — в этом разделе можно настроить внешний источник времени и перечень контроллеров, которые будут выполнять функцию корневых NTP-серверов домена (NTP Chrony). В части синхронизации времени корневые NTP-серверы работают как ePDC, т.е. берут время только от внешнего источника. Настройки синхронизации времени будут доставлены на рабочие станции через групповую политику «Настройки сервиса сетевого времени Chrony».

• Служба печати — в этом разделе можно выполнить повышение роли сервера до подсистемы печати (CUPS) и увидеть перечень таких серверов. Вы можете создавать принтеры, загружать драйверы, и т.д.

• Общий доступ к файлам — в этом разделе можно выполнить повышение роли сервера до подсистемы общего доступа к файлам (Samba) и увидеть перечень таких серверов. Вы можете создавать общие папки и определять права доступа на уровне SMB-подключения.

• Служба глобального каталога — в этом разделе на контроллер домена можно установить модуль глобального каталога (англ. Global Catalog, GC), который является собственной разработкой ALD Pro. Модуль GC необходим для возможности полноценного использования двусторнонних доверительных отношений.

Мониторинг

В этом разделе можно выполнить повышение роли сервера до подсистемы мониторинга (Zabbix) и увидеть перечень таких серверов. Вы сможете просматривать журнал событий и витрины мониторинга.

Журнал событий

В этом разделе можно выполнить повышение роли сервера до подсистемы аудита (syslog-ng) и увидеть перечень таких серверов. Вы сможете создавать правила сбора событий, но для просмотра журналов вам нужно будет перейти на сервер и воспользоваться, например, графическим приложением Ksystemlog или настроить интеграцию с SIEM.

Модуль синхронизации

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

Управление организационной структурой

Перейдем на портал управления в раздел Пользователи и компьютеры далее Организационная структура и выберем корневое подразделение ald.company.lan, как показано на рисунке ниже:

рис. 209 Организационная структура компании

Если выбрано какое-то подразделение, вам будут доступны следующие кнопки:

• Кнопка + Подразделение — добавить подразделение.

• Кнопка + Пользователь — создать пользователя в подразделении.

• Кнопка + Группа пользователей — создать группу пользователей в подразделении.

• Кнопка + Группа компьютеров — создать группу компьютеров в подразделении.

• Кнопка Редактировать — перейти к карточке подразделения для ее редактирования.

Мы уже отмечали, что в службе каталога FreeIPA нет подразделений, в этой системе все объекты расположены в плоской структуре и для назначения групповых политик используются обычные группы пользователей и компьютеров. Для возможности назначения групповых политик по схеме LSDOU (англ. Local, Site, Domain, OU), т.е. на группы объектов в соответствии с их логическим размещением, в ALD Pro была реализована иерархия организационных подразделений.

Физически учетные записи пользователей, компьютеров и групп остаются в тех же контейнерах FreeIPA, а принадлежность к организационному подразделению определяется через ссылку, которая задается в атрибуте rbtadp (англ. RusBITech Astra Division Path — путь до организационного подразделения).

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

Если же вы удалите запись организационного подразделения в обход интерфейса ALD Pro, то будут удалены только дочерние подразделения, а пользователи, компьютеры и группы, принадлежащие этим подразделениям, останутся нетронутыми. Вы сможете найти их в списках соответствующих типов объектов или через командную строку, например, ipa user-find <подстрока>.

Настроим простую организационную структуру, как показано на рис. 210.

рис. 210 Пример организационной структуры

Для этого с помощью кнопки + Подразделение создайте несколько структурных подразделений и не забудьте сохранить изменения.

рис. 211 Сохранение нового организационного подразделения

Теперь рассмотрим подробнее карточку организационного подразделения.

• Основное — на этой вкладке вы можете изменить основные атрибуты организационного подразделения и применить к нему определенные действия. Кнопка Сохранить доступна в правом верхнем углу страницы всегда (см. рис. 211), а кнопка Удалить подразделение находится в правом нижнем углу на вкладке с основными сведениями.

  • Описание — позволяет сделать уточнение, какие объекты каталога следует размещать в этом организационном подразделении.

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

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

рис. 212 Основные свойства подразделения

• Пользователи — на этой вкладке вы можете изменить список пользователей и групп пользователей, принадлежащих этому организационному подразделению.

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

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

• Групповые политики — на этой вкладке вы можете создавать новые, просматривать и удалять существующие назначения объектов групповой политики, которые эквивалентны ссылкам GPO из MS AD (англ. GPO Link).

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

Управление пользователями

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

рис. 213 Карточка сотрудника

Вы увидите ряд вкладок, с помощью которых можно редактировать следующую информацию:

• Основные — на этой вкладке доступны основные атрибуты пользователя.

  • Персональные данные — раздел позволяет задать ФИО, отображаемое имя и фотографию сотрудника.

  • Учетная запись — раздел позволяет задать UID учетной записи или заблокировать ее. UID является аналогом SID, и в домене FreeIPA его действительно можно изменить. В этом же разделе вы можете посмотреть срок действия пароля и сбросить его на новое значение.

    Если администратор назначит новый пароль не себе, а любому другому пользователю, то такой пароль будет считаться с истекшим сроком действия, как будто был установлен флажок «Требовать смены пароля при следующем входе в систему» (англ. User must change password at next logon).

    Если вам потребуется «снять этот флажок», чтобы пароль был сразу активен, то вам потребуется продлить срок действия пароля вручную из окна терминала, например, командой ipa user-mod kuznetsov --password-expiration 20250101115110Z.

  • Организационные данные — раздел позволяет указать должность, определить руководителя и задать принадлежность к организационному подразделению.

    Информация о руководителе носит справочный характер и не влияет на какие-либо права доступа. Вы можете использовать ее в заданиях автоматизации для построения отчетов или рассылки уведомлений об истечении срока действия паролей.

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

  • Сертификат пользователя — позволяет добавить сертификат, который будет использоваться для двухфакторной аутентификации через PKINIT (англ. Public Key Cryptography for Initial Authentication in Kerberos) — расширения протокола Kerberos, которое позволяет при аутентификации использовать криптографию с открытым ключом вместо пароля.

    На данный момент реализована интеграция с USB-токенами JaCarta и приложением для входа SecureLogon, которое заменяет стандартное окно, чтобы предоставить дополнительные возможности для удобной работы с токенами.

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

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

  Напоминаем, что в Linux (как и в Windows) локальные группы не поддерживают вложенности, поэтому в состав их участников нельзя включать другие группы. Доменные группы FreeIPA (как MS AD) снимают это ограничение, поэтому на данной странице есть раздел Состоит в группах непрямое наследование, в котором указаны те группы, участником которых пользователь является опосредованно через механизм наследования.

• Дополнительные сведения — на этой вкладке вы можете просматривать и редактировать значения кастомных атрибутов, список которых можно определить на странице Управление доменом ‣ Пользователи и группы ‣ Атрибуты пользователей. Значения этих атрибутов хранятся в атрибуте user-custom-attr в json-формате.

• Групповые политики — на этой вкладке вы найдете список параметров групповых политик, которые должны быть применены к данному пользователю. Это чем-то похоже на инструмент RSoP из MS AD, который выдает прогнозируемый результат суммирования параметров в зависимости от настроек групповых политик и расположения пользователя в иерархии организационных подразделений.

• Расширенные настройки – на этой вкладке вы можете задать основной и дополнительные адреса SMTP, x500 и SIP для интеграции с почтовыми системами, например, РуПост.

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

  В службе FreeIPA реализована трехуровневая модель, в которой есть роли, привилегии и разрешения. Разрешения соответствуют инструкциям доступа ACI (англ. Access Control Instructions). Подробнее о ролях и их назначении вы можете узнать в справочном центре https://dc-1.ald.company.lan/ad/help/ui/73.

  Система ALD Pro предоставляет несколько десятков преднастроенных ролей, например:

  • ALDPRO - Main Administrator — администратор домена обладает полными правами.

  • ALDPRO - Domain Viewer — участники роли получают набор привилегий для просмотра всех разделов портала ALD Pro.

  • ALDPRO - RuPost Service Integrations — эта роль необходима для того, чтобы предоставить учетной записи почтовой службы Рупост необходимые права доступа.

  • и другие.

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

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

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

  • Security Architect — архитектор безопасности, который обладает правами на администрирование политик паролей и др.

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

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

Атрибут	Пользователь1	Пользователь2	Пользователь3	Пользователь4
Логин	iivanov	ppetrov	asidorov	vsidorova
Фамилия	Иванов	Петров	Сидоров	Сидорова
Имя	Иван	Петр	Александр	Виктория
Отчество	Иванович	Петрович	Александрович	Александровна
Подразделение	Отдел ИТ	Отдел маркетинга	Производство	Бухгалтерия
Пароль	Pa$$w0rd	Pa$$w0rd	Pa$$w0rd	Pa$$w0rd

рис. 214 Список сотрудников

Управление компьютерами

Перейдем на страницу Пользователи и компьютеры ‣ Компьютеры и откроем карточку объекта с именем pc-1.ald.company.lan.

рис. 215 Карточка компьютера pc-1.ald.company.lan

Вы увидите ряд вкладок, с помощью которых можно редактировать следующую информацию:

• Основные – в этом разделе представлены атрибуты с основной информацией о компьютере. Вы можете изменить принадлежность компьютера к организационному подразделению, задать дополнительное описание, добавить уточнения по платформе и установленной операционной системе. Поля, за исключением «имя компьютера», «псевдоним учетной записи» и «расположение подразделения в организационной структуре» доступны для редактирования.

• Группы — на этой вкладке вы можете посмотреть и изменить информацию об участии компьютера в группах, с помощью которых можно назначать базовые политики FreeIPA, например, политики доступа к узлу (HBAC-правила) и политики повышения привилегий (SUDO-правила).

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

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

Удаленный доступ для оказания поддержки

Портал управления ALD Pro предоставляет инструмент удаленного доступа к рабочему столу по протоколу VNC, который вы можете использовать для оказания помощи сотрудникам. Для того чтобы включить удаленный доступ, пользователь должен запустить приложение Пуск ‣ ALD Pro ‣ Удаленный рабочий стол и сообщить администратору временный пароль, см. рис. 216.

рис. 216 Временный пароль для удаленного подключения

Администратор сможет выбрать активную сессию из списка на вкладке Удаленный доступ карточки компьютера и подключиться к рабочему столу пользователя по предоставленному паролю, см. рис. 216. Информацию об активных сессиях портал управления получает, обращаясь к рабочей станции по порту 30000/TCP. Удаленный доступ работает по протоколу VNC, подключение выполняется по портам, начиная с 6080/TCP.

рис. 217 Управление удаленным рабочим столом пользователя с портала управления ALD Pro

Попробуйте сами, как это работает. Включите виртуальную машину с pc-1, войдите в операционную систему под учетной записью пользователя Петр Петров (ppetrov) и запустите приложение для удаленного доступа. После этого перейдите на портал управления и воспользуйтесь этим паролем для удаленного подключения, см. рис. 218.

рис. 218 Подключение к удаленному рабочему столу пользователя с портала управления ALD Pro

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

рис. 219 Панель управления сессией удаленного подключения

Если вы по ошибке закроете карточку компьютера, то удалённый доступ не прервётся, и вы сможете вернуться назад, чтобы продолжить оказание технической поддержки. Пользователь может прервать удаленное подключение по своему усмотрению, для этого ему достаточно закрыть окно приложения «Удаленный рабочий стол».

Управление группами

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

рис. 220 Группы пользователей

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

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

  Обратите внимание, что пользователь admin по умолчанию включен в локальную группу astra-admin на всех компьютерах ALSE в домене, что дает ему право локального администратора системы. Другие участники группы admins таких прав иметь не будут, т.к. участником локальной группы могут быть только конкретные пользователи системы.

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

• ipausers — специальная группа, в которую автоматически включаются все новые пользователи домена, что делает ее похожей на группу Domain Users из Active Directory.

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

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

• Trust admins и ald trust admin — имена этих групп используются в скриптах ipa-adtrust-install и ipa-aldtrust-install. Если при повышении роли сервера до контроллера домена пользователь не будет включен в группу ald trust admin, то контроллер не сможет стать контроллером доверия и придется запускать утилиту ipa-aldtrust-install вручную еще раз.

Рассмотрим атрибуты, доступные на карточке группы:

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

• Пользователи и Группы – на этих вкладках вы можете изменить состав участников группы и участие самой группы в других группах.

• Роли — на этой вкладке вы можете назначить группе какие-нибудь роли, через которые участники группы получат права доступа на управление объектами каталога.

Подробнее о группах вы можете узнать в справочном центре https://dc-1.ald.company.lan/ad/help/ui/29.

Служба синхронизации времени

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

Механизм синхронизации времени в ALD Pro

Функцию сервера времени выполняет каждый контроллер домена. Источники времени задаются через параметры групповой политики «Настройки сервиса сетевого времени Chrony» и, если параметр не задан, то по умолчанию используется иерархия, как в домене Active Directory, которая работает следующим образом:

• Корневым контроллерам домена, которые являются аналогом ePDC, в качестве источника времени назначается внешний пул NTP-серверов. Первый контроллер домена автоматически становится корневым NTP-сервером.

  Обратите внимание, что внешний пул должен обязательно содержать доступные источники, иначе корневой NTP посчитает себя недоверенным источником времени и синхронизация времени в домене работать не будет.

• Обычным контроллерам домена в качестве источника времени устанавливаются корневые NTP-серверы домена.

• Остальным серверам и рабочим станциям в качестве источника времени устанавливается любой контроллер домена.

Скрипт политики времени и даты находится в папке rbta_ldap_date_time_h в директории политик хоста /srv/aldpro-salt/roots/states/policies/host-policies/ (до версии ALD Pro 2.4.0 политика находилась в каталоге /srv/salt/standalone/roots/states/policies/host-policies/rbta_ldap_date_time_h).

Изменения в работе NTP в версии 2.5.0

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

• minstratum 12 - корневые источники времени из своего сайта;

• minstratum 13 - обычные контроллеры из своего сайта;

• minstratum 14 - корневые источники времени из других сайтов;

• minstratum 15 - обычные контроллеры из других сайтов.

Группы источников времени задаются с помощью динамических DNS-записей, настройка которых выполняется службой aldpro-ntp-management автоматически. Обновление записей происходит при следующих изменениях в домене:

• изменение состава корневых NTP-серверов;

• добавление или удаление контроллера домена;

• изменение привязки контроллера к сайту.

Служба aldpro-ntp-management устанавливается на все контроллеры домена, но должна быть запущена только на одном из них. Она выполняет проверку healthcheck NTP каждые 2 минуты, в ходе которой получает данные из LDAP-каталога, выполняет расчет того, какие DNS-записи должны присутствовать в домене, после чего сверяет полученные результаты с фактическим состоянием. Если проверка обнаружит какие-то расхождения, то служба автоматически внесет соответствующие изменения в каталог.

Протокол синхронизации времени

Протокол NTP (англ. Network Time Protocol) — это протокол для синхронизации времени между вычислительными устройствами по компьютерным сетям с переменной задержкой. Для вычисления точного времени выполняется расчет задержки и смещения, см. рис. 221.

рис. 221 Алгоритм синхронизации NTP

Клиент регулярно опрашивает один и более NTP-серверов, рассчитывает задержку и смещение для каждого из них и пропускает полученные значения через статистические фильтры для смягчения последствий ошибок. Чем более симметричной окажется задержка на исходящей и входящей части маршрута, тем выше будет точность определения времени. Однако следует понимать, что NTP-клиент не использует время одного «лучшего» сервера — для повышения точности он использует данные сразу нескольких серверов.

Серверы NTP выстраиваются в иерархию, где каждый последующий уровень или слой (англ. stratum) обладает меньшей точностью, см. рис. 222:

• stratum 0 — это авторитетные источники времени, такие как атомные часы. Серверы NTP не соответствуют этому уровню по определению, поэтому значение 0 интерпретируется как «уровень не задан».

• stratum 1 — это серверы, которые напрямую подключены к авторитетному источнику времени уровня 0, например, к атомным часам (точность time-a.nist.gov составляет триллионные доли секунды), GPS-приемнику (точность ntpx.imvp.ru составляет миллиардные доли секунды) и др. Серверы первого уровня могут взаимодействовать между собой для проверки работоспособности.

• stratum 2 — вторичные серверы, которые получают время от серверов stratum 1. Серверы stratum 2 обычно запрашивают время у нескольких серверов stratum 1 и могут взаимодействовать с другими серверами stratum 2, чтобы обеспечить более стабильное и достоверное время для всех устройств в одноранговой группе. При правильной настройке и выборе серверов-источников точное время имеет погрешность менее 1 миллисекунды.

• stratum 3 — серверы, синхронизированные с серверами stratum 2. Они используют те же алгоритмы для пиринга и выборки данных, что и stratum 2, и сами могут выступать в качестве серверов для компьютеров stratum 4.

• и так далее до stratum 15 включительно.

рис. 222 Иерархия NTP-серверов

В качестве источника внешнего времени можно выбрать сервера stratum 2 от проекта ntp.org. По состоянию на январь 2024 года пулы содержат порядка 200 публичных серверов, из которых ~150 работают по протоколу IPv4 и ~50 по протоколу IPv6. Российские пулы доступны по следующим адресам:

• 0.ru.pool.ntp.org

• 1.ru.pool.ntp.org

• 2.ru.pool.ntp.org

• 3.ru.pool.ntp.org

Есть так же проект эталонного времени от ФГУП «ВНИИФТРИ», где находится аппаратный комплекс эталонного времени, с помощью которого формируется независимая национальная шкала времени РФ. По состоянию на 2022 год около полумиллиарда потребителей ежесуточно синхронизировали время через NTP-серверы этого проекта. Доменные адреса этих серверов:

• Москва:

  • ntp1.vniiftri.ru

  • ntp2.vniiftri.ru

  • ntp3.vniiftri.ru

  • ntp4.vniiftri.ru

• Иркутск:

  • ntp1.niiftri.irkutsk.ru

  • ntp2.niiftri.irkutsk.ru

• Хабаровск:

  • vniiftri.khv.ru

  • vniiftri2.khv.ru

• Новосибирск:

  • ntp.sstf.nsk.ru

Пакет chrony и служба chronyd

При установке ALD Pro (как клиентской, так и серверной части) в системе появляется служба chrony, содержание конфигурационного файла которой устанавливается автоматически через механизм групповых политик в соответствии с текущими настройками домена из раздела Роли и службы сайта ‣ Служба синхронизации времени.

В состав пакета chrony входят:

• chronyd — это служба, которая может работать как в режиме NTP-клиента, так и NTP-сервера, обеспечивая синхронизацию времени в инфраструктуре предприятия;

• chronyc — это утилита, с помощью которой можно управлять службой chronyd, в том числе по сети, если эта служба работает на удаленном сервере;

• chrony-helper — вспомогательный скрипт /usr/libexec/chrony/chrony-helper, который позволяет, например, создать в операционной системе службу, которая будет извлекать имена NTP-серверов из SRV-записей.

Приведем несколько советов по работе с этой службой:

• Текущие настройки службы синхронизации времени на хосте можно посмотреть в файле /etc/chrony/chrony.conf.

• Текущее значение времени можно узнать в приложении «Дата и Время» или из терминала командой timedatectl.

• Принудительно запустить синхронизацию времени можно перезапуском службы с помощью команды systemctl restart chrony.

• Для взаимодействия со службой chronyd во время ее работы предназначен интерфейс командной строки chronyc. Чтобы увидеть, с какими серверами служба устанавливает соединение, через него можно отправить команду sources. Символом звездочки будет отмечен сервер, который был выбран в качестве основного источника времени.

  chronyc sources -v
  

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

  root@dc-1:~# chronyc sources -v
  ...
  ^\* dc-1.ald.company.lan 2 6 377 51 +4571ns[ -48us] +/- 19ms
  ...
  

• Система ALD Pro использует параметр makestep, поэтому при синхронизации времени компьютер сразу устанавливает требуемое значение. Форсировать переход к целевому значению можно вызовом команды chronyc makestep.

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

• Система ALD Pro использует параметр rtcsync, поэтому клиенты сверяют часы каждые 11 минут, но что более важно, при синхронизации времени служба chrony сбрасывает флаг STA_UNSYNC, поэтому в приложении «Дата и время» у вас нет предупреждения об отсутствии синхронизации.

• Если вам требуется проверить работу NTP на сервере, вы можете воспользоваться командой ntpdate -qvd dc-1.ald.company.lan. Ключ -q (англ. query only — только запросить), говорит о том, что нужно только отправить запрос на сервер, но не менять значение системных часов. Крайне полезными являются также ключи -v и -d, включающие подробный вывод (verbose) и отладку (debugging) соответственно.

• После синхронизации команда timedatectl может показывать расхождение между системным временем операционной системы (Universal time) и значением времени в BIOS (RTC time, real time clock), так как запись в BIOS происходит только при выключении компьютера. Форсировать запись в BIOS можно командой hwclock --systohc.

И не забывайте, что при значительном изменении времени, например, после восстановления виртуальной машины из горячего снимка, все ранее выданные билеты Kerberos могут оказаться недействительными.

Служба разрешения имен

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

В качестве DNS-сервера в FreeIPA взяли проверенную временем службу BIND9 (англ. Berkeley Internet Name Domain version 9), которая тесно интегрирована с каталогом, что` выражается в следующем:

• При присоединении компьютера к домену или повышении роли сервера до контроллера домена все необходимые DNS-записи создаются скриптами FreeIPA автоматически.

• Все DNS-записи хранятся в LDAP-каталоге, поэтому синхронизируются между серверами в рамках штатной процедуры репликации контроллеров домена. Доступ к каталогу BIND9 получает через плагин bind-dyndb-ldap.

• Средствами BIND9 реализована географическая балансировка нагрузки.

Протокол DNS

Система доменных имен (англ. Domain Name System, DNS) — это не что иное, как глобальная телефонная книга Интернета, в которой в колонке с номерами телефонов указаны IP-адреса, а в колонке с именами абонентов — доменные имена серверов, или правильнее сказать ресурсов, которые они предоставляют, поэтому DNS-записи называются так же ресурсными.

Когда системный администратор легко ориентируется в IP-адресах своей инфраструктуры, это традиционно уважается. Но адресов все-таки чуть больше, чем желания их запоминать, поэтому уже с первых дней ARPANET существовал файл /etc/hosts, сопоставляющий имена узлов с числовыми адресами.

Файл hosts был очень хорошим решением — простой, удобный, в общем, очень хороший файл. Правда, для внесения изменений в глобальную копию этого файла нужно было в рабочие часы дозвониться до Стэнфорда, а в остальном очень хороший файл. Проблема с внесением изменений стала действительно ПРОБЛЕМОЙ уже очень скоро, поэтому в дополнение к hosts разработали систему доменных имен.

На уровне клиента DNS-протокол довольно прост. Информация является общедоступной, поэтому никакая аутентификация не требуется и можно ограничиться UDP-протоколом. Достаточно отправить запрос к DNS-серверу на порт 53/UDP, и тут же получишь ответ, см. рис. 223.

рис. 223 Пример обычного DNS-запроса с получением данных по UDP

Но процесс немного усложняется, когда размер сообщения выходит за пределы 512 байт, так как в этом случае DNS-сервер вместо нормального ответа вернет пакет с флагом TC (англ. truncated — усеченный), и клиенту нужно будет повторить запрос, но уже на порт 53/TCP.

Например, при исследовании SRV-записей с помощью nslookup в доменах на десять контроллеров и больше вы будете сталкиваться с предупреждением о каком-то усечении (англ. Truncated, retrying in TCP mode — усечено, повторная попытка в режиме TCP):

nslookup -q=srv _kerberos._tcp.ald.company.lan

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

admin@dc-1:~$ nslookup -q=srv _kerberos._tcp.ald.company.lan
;; Truncated, retrying in TCP mode.
Server:         127.0.0.1
Address:        127.0.0.1#53

_kerberos._tcp.ald.company.lan canonical name = _kerberos._tcp.hq._locations.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-5.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-3.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-1.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-9.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-4.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-7.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-2.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-8.ald.company.lan.
_kerberos._tcp.hq._locations.ald.company.lan   service = 0 100 88 dc-6.ald.company.lan.

Размер полезной нагрузки для ответа по UDP был ограничен лимитом в 512 байт для оптимизации работы по сети, так как в то время преобладали сети X.25, у которых MTU был 576 байт, и такой размер позволял гарантированно избежать фрагментации UDP-пакетов. После переключения на TCP-протокол клиент сможет получить ответ любого размера, даже если это будут огромные записи с сертификатами.

рис. 224 Пример DNS-запроса с переключением на TCP

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

рис. 225 Иерархическое пространство DNS-имен

В самом верху иерархии находится корневая (root) зона, которая обозначается символом точки. Обычно мы не пишем адреса сайтов с точкой на конце «yandex.ru.», но эта последняя точка как бы предполагается.

За работу корневой зоны отвечают тринадцать корневых серверов, имена которых имеют вид {a..m}.root-servers.net, но клиентам, которым требуется разрешать DNS-имена самостоятельно, нужно знать их «по IP-адресам». Например, в том же BIND9 эта информация находится в файле /usr/share/dns/root.hints:

cat /usr/share/dns/root.hints | grep ROOT-SERVERS | grep A

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

admin@dc-1:~$ cat /usr/share/dns/root.hints | grep ROOT-SERVERS | grep A
.                        3600000       NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000       A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000       AAAA  2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.      3600000       A     199.9.14.201
B.ROOT-SERVERS.NET.      3600000       AAAA  2001:500:200::b
C.ROOT-SERVERS.NET.      3600000       A     192.33.4.12
C.ROOT-SERVERS.NET.      3600000       AAAA  2001:500:2::c
...

В целях упрощения обычные DNS-клиенты не имеют информации root.hints и отправляют запросы не напрямую к NS-серверам, которые обслуживают соответствующие зоны, а через так называемые DNS-резолверы, которые выполняют всю эту работу за них. Однако, несмотря на то, что BIND9 является резолвером и может рекурсивно обходить все NS-сервера, начиная с корневой зоны, в домене для снижения нагрузки рекомендуется все-таки использовать глобальные перенаправители, например, DNS-сервер от Яндекса с IP-адресом 77.88.8.8.

Совсем сложным процесс становится, когда мы хотим защитить доменные имена от MITM-атак (англ. Man in the middle — человек посередине) и добавляем технологию DNSSEC, которая позволяет подтвердить подлинность DNS-информации с использованием цифровых подписей.

Очень упрощенно это выглядит примерно так: есть корневая зона «.», которая содержит в себе записи о доменах первого уровня, таких как «ru.», «com.» и т.д. Каждая запись подписывается закрытым ключом, а открытый ключ предоставляется всем желающим, что позволяет легко проверить получаемые ответы. Например, с помощью следующего запроса вы можете получить RRSIG-запись с цифровой подписью, которая подтверждает, что зону «ru.» действительно обслуживают сервера ripn.net:

dig -t any +dnssec @k.root-servers.net ru.

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

admin@dc-1:~$ dig -t any +dnssec @k.root-servers.net ru.
...
ru.                   172800 IN      NS      d.dns.ripn.net.
ru.                   172800 IN      NS      a.dns.ripn.net.
ru.                   172800 IN      NS      b.dns.ripn.net.
ru.                   172800 IN      NS      f.dns.ripn.net.
ru.                   172800 IN      NS      e.dns.ripn.net.
ru.                   86400  IN      DS      43786 8 2
3C59747544090BC74419D5F69E32D8C9B18EA48CBDAA33C094356191 20CED431
ru. 86400 IN RRSIG DS 8 1 86400 20240707170000 20240624160000 5613 .
HaAdFkvkNMV8gHrgX6dTTR+MLAWwy2HOSJTJTbu1dTR9m8DgnAPgUhS4
uMr61zbORe8hOFlqnUTXuEtjH1gmVaIPEmW76aGMiG07LgnKVsMDVSq9
1K2A8J4cm4/t+wru/sAidVINcyxZ7YInLhLccMR+wBRIcusvq9dlpqtA
TcT8FAFT7uxZ2j+JvnwRC2vmxLd0CXW25GPJ20mFklp8ipQZ+kBUHdTc
sBHbmyVBXSyK63T6/3wdHsWBt33z2OCnZrSm/1koMVsZ4l8/2BEMZY6S
MpZ4o22NLOkP+RHwBp7LYOmoYn5n21QQ3cKUcsXh/JyweBlIShc0Yvx8 KMp3PQ==...

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

Технология DNSSEC является крайне непростой и в локальной сети, которая защищена от внешнего воздействия, использование этой технологии видится излишним, поэтому мы не будем на ней сильно останавливаться. Лучше мы расскажем немного о том, как выполнить базовую проверку работы DNS.

Самый простой способ проверить работу системы разрешения имен – это сделать пинг по доменному имени сервера. Утилита предназначена, конечно, для проверки целостности и качества соединений, но и в этом случае отлично подходит:

ping -c 4 yandex.ru

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

admin@dc-1:~$  ping -c 4 yandex.ru
PING yandex.ru (77.88.55.88) 56(84) bytes of data.
64 bytes from yandex.ru (77.88.55.88): icmp_seq=1 ttl=247 time=9.34 ms
64 bytes from yandex.ru (77.88.55.88): icmp_seq=2 ttl=247 time=9.21 ms
64 bytes from yandex.ru (77.88.55.88): icmp_seq=3 ttl=247 time=9.19 ms
64 bytes from yandex.ru (77.88.55.88): icmp_seq=4 ttl=247 time=9.26 ms

--- yandex.ru ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7ms
rtt min/avg/max/mdev = 9.187/9.247/9.336/0.112 ms

Гораздо больше информации можно получить с помощью утилиты nslookup, причем и в Linux, и в Windows интерфейс этой утилиты практически одинаковый. Для получения A-записей достаточно передать утилите просто имя сайта:

nslookup yandex.ru

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

admin@dc-1:~$  nslookup yandex.ru
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: yandex.ru
Address: 77.88.44.55
Name: yandex.ru
Address: 77.88.55.88
Name: yandex.ru
Address: 5.255.255.77
Name: yandex.ru
Address: 2a02:6b8:a::a

И тут возникает вопрос: а что значит неавторитетный ответ (англ. Non-authoritative answer)? Вспоминаем, что мы обращаемся к NS-серверу не напрямую, а через вспомогательный резолвер, поэтому ответ от резолвера утилита считает недостаточно авторитетным. То есть авторитетным ответ будет только от серверов, которые указаны в NS-записях.

Как мы уже сказали, по умолчанию nslookup возвращает A-записи, и поменять тип записи можно с помощью ключа -q (query):

nslookup -q=ns yandex.ru

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

admin@dc-1:~$  nslookup -q=ns yandex.ru
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
yandex.ru      nameserver = ns1.yandex.ru.
yandex.ru      nameserver = ns2.yandex.ru.

Authoritative answers can be found from:
ns1.yandex.ru internet address = 213.180.193.1
ns2.yandex.ru internet address = 93.158.134.1
ns1.yandex.ru has AAAA address 2a02:6b8::1
ns2.yandex.ru has AAAA address 2a02:6b8:0:1::1

Как мы видим, зону yandex.ru обслуживает в том числе сервер ns1.yandex.ru с IP-адресом 213.180.193.1, поэтому если мы спросим про яндекс у него, то ответ уже будет считаться авторитетным. Для этого нужно указать адрес DNS-сервера после доменного имени:

nslookup yandex.ru 213.180.193.1

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

admin@dc-1:~$  nslookup yandex.ru 213.180.193.1
Server: 213.180.193.1
Address: 213.180.193.1#53

Name: yandex.ru
Address: 77.88.55.88
Name: yandex.ru
Address: 77.88.44.55
Name: yandex.ru
Address: 5.255.255.77
Name: yandex.ru
Address: 2a02:6b8:a::a

Утилита nslookup может порадовать вас также интерактивным режимом, если вы запустите ее без параметров. Чтобы переключиться на другой DNS-сервер, вам нужно воспользоваться командой server, а чтобы запрашивать другой тип записей, установите переменную type с помощью команды set. Вот пример работы с утилитой в интерактивном режиме:

admin@dc-1:~$ nslookup
> yandex.ru
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
Name: yandex.ru
Address: 77.88.44.55
Name: yandex.ru
Address: 77.88.55.88
Name: yandex.ru
Address: 5.255.255.77
Name: yandex.ru
Address: 2a02:6b8:a::a
>
> server 213.180.193.1
Default server: 213.180.193.1
Address: 213.180.193.1#53
>
> set type=mx
>
> mail.yandex.ru
Server: 213.180.193.1
Address: 213.180.193.1#53

Non-authoritative answer:
*** Can't find mail.yandex.ru: No answer

Authoritative answers can be found from:
mail.yandex.ru nameserver = ns4.yandex.ru.
mail.yandex.ru nameserver = ns3.yandex.ru.
> exit

Вроде бы все работает, но почему полученный результат опять не является авторитетным, если мы запрашиваем информацию напрямую у сервера Yandex? Ответ на самом деле прост: почтовому сервису Яндекса делегирована вся зона целиком и обслуживается она на других серверах, чтобы команда проекта могла управлять ей самостоятельно. Поэтому повторите запрос к серверу ns4.yandex.ru, и все будет уже вполне авторитетно:

ping -c 1 ns4.yandex.ru
nslookup -q=mx mail.yandex.ru 77.88.21.1

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

admin@dc-1:~$ ping -c 1 ns4.yandex.ru
PING ns4.yandex.ru (77.88.21.1) 56(84) bytes of data.
64 bytes from ns4.yandex.ru (77.88.21.1): icmp_seq=1 ttl=56 time=3.18 ms

--- ns4.yandex.ru ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.179/3.179/3.179/0.000 ms

admin@dc-1:~$ nslookup -q=mx mail.yandex.ru 77.88.21.1
Server: 77.88.21.1
Address: 77.88.21.1#53
mail.yandex.ru mail exchanger = 0 mx.yandex.ru.

Утилита nslookup отлично подходит для решения большинства вопросов, т.к. через нее можно получить основную информацию о работе доменной службы, но гораздо больше информации вы сможете получить с помощью утилиты dig. Многие считают, что название утилиты dig означает «копать», что недалеко от истины, но на самом деле это название является аббревиатурой от Domain Information Groper (сборщик информации о домене). Мы настоятельно рекомендуем переходить к утилите dig только после того, как вы станете уверенно работать с утилитой nslookup.

Конфигурационные файлы службы разрешения имен

В каталоге /etc/bind на контроллере домена содержатся следующие конфигурационные файлы:

• Файл named.conf — основной конфигурационный файл с настройками BIND9. Как раз в этом файле подключается плагин bind-dyndb-ldap.

• Файл named.conf.options — содержит параметры DNS-сервера.

• Файл /etc/bind/named.conf.default-zones — содержит зоны по умолчанию. Тут нас в первую очередь должны интересовать настройки корневой зоны «.», где указано, что нужно использовать файл /usr/share/dns/root.hints.

  В файле root.hints перечислены IP-адреса всех корневых DNS-серверов, обслуживающих Интернет, поэтому BIND9 даже при отсутствии глобального перенаправителя способен самостоятельно разрешать доменные имена.

• Файл /etc/bind/zones.rfc1918 — содержит список частных обратных зон (10.x.x.x и так далее).

• Файл /etc/bind/bind.keys — файл с ключами для обеспечения работы DNSSEC. Технология DNSSEC еще не получила большого распространения и требует отдельного рассмотрения, поэтому ее предлагается не использовать.

• Файл /etc/bind/db.* — файлы зон DNS.

• Файл /etc/bind/rndc.key — файл с ключами для аутентификации DHCP-сервера (если мы захотим, чтобы DHCP мог автоматически обновлять DNS-записи хостов).

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

• Файл /etc/bind/ipa-ext.conf — подключается в named.conf и предназначен для определения дополнительных настроек службы BIND9, которые не будут изменены при обновлении сервера FreeIPA. Например, в этом файле вы можете определить перечень доверенных сетей. По умолчанию все строки в этом файле закомментированы:

admin@dc-1:~$ sudo cat /etc/bind/ipa-ext.conf
/* User customization for BIND named
*
* This file is included in /etc/bind/named.conf and is not modified during IPA
* upgrades.
* "options" settings must be configured in /etc/bind/ipa-options-ext.conf.
*
* Example: ACL for recursion access:
*
* acl "trusted_network" {
*   localnets;
*   localhost;
*   234.234.234.0/24;
*   2001::co:ffee:babe:1/48;
*  };
*/

• Файл /etc/bind/ipa-options-ext.conf — подключается в секции options файла named.conf и предназначен для определения дополнительных опций службы BIND9, которые не будут изменены при обновлении сервера FreeIPA.

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

admin@dc-1:~$ sudo cat /etc/bind/ipa-options-ext.conf
dnssec-validation no;
allow-recursion { any; };
allow-query-cache { any; };

Содержимое файла /etc/bind/named.conf управляется службой FreeIPA. Тут наибольший интерес представляют следующие настройки:

• Секция logging — указывает, что журнал работы BIND9 будет доступен по адресу /var/cache/bind/named.run;

• Инструкции include — подключают дополнительные конфигурационные файлы.

• Секция dyndb — настраивает LDAP-плагин для подключения к каталогу по unix-сокету.

/* WARNING: This config file is managed by IPA.
*
* DO NOT MODIFY! Any modification will be overwritten by upgrades.
*
*
* - /etc/bind/ipa-options-ext.conf (for options)
* - /etc/bind/ipa-ext.conf (all other settings)
*/

options {
      // Put files that named is allowed to write in the data/ directory:
      directory "/var/cache/bind"; // the default
      dump-file               "cache_dump.db";
      statistics-file         "named_stats.txt";
      memstatistics-file      "named_mem_stats.txt";

      tkey-gssapi-keytab "/etc/bind/named.keytab";

      pid-file "/run/named/named.pid";

      managed-keys-directory "/var/cache/bind/dynamic";

      /* user customizations of options */
      include "/etc/bind/ipa-options-ext.conf";

      /* crypto policy snippet on platforms with system-wide policy. */
      // not available
};

/* If you want to enable debugging, eg. using the 'rndc trace' command,
* By default, SELinux policy does not allow named to modify the /var/named directory,
* so put the default debug log file in data/ :
*/
logging {
      channel default_debug {
               file "named.run";
               severity dynamic;
               print-time yes;
      };
};

//zone "." IN {
//      type hint;
//      file "named.ca";
//};

include "/etc/bind/named.conf.default-zones";
include "/etc/bind/bind.keys";

/* user customization */
include "/etc/bind/ipa-ext.conf";

dyndb "ipa" "/usr/lib/bind/ldap.so" {
      uri "ldapi://%2fvar%2frun%2fslapd-ALD-COMPANY-LAN.socket";
      base "cn=dns,dc=ald,dc=company,dc=lan";
      server_id "dc-1.ald.company.lan";
      auth_method "sasl";
      sasl_mech "GSSAPI";
      sasl_user "DNS/dc-1.ald.company.lan";
};

Если заглянуть в LDAP-каталог с помощью Apache Directory Studio, см рис. 226, то вы сможете увидеть, что в атрибутах записи с DN «cn=dns,dc=ald,dc=company,dc=lan», хранятся настройки, которые мы задаем на странице Роли и службы сайта ‣ Служба разрешения имен вкладка Глобальная конфигурация DNS, см. рис. 227.

рис. 226 Содержимое записи «cn=dns,dc=ald,dc=company,dc=lan»

рис. 227 Глобальная конфигурация DNS

Зоны DNS и параметры зоны

На вкладке «Зоны DNS» представлен список прямых и обратных зон, которые вы можете создавать, удалять и редактировать, см. рис. 228. Однако следует учитывать, что встроенный DNS-сервер ориентирован в первую очередь на потребности домена и целый ряд настроек BIND9 вам будет недоступен. Поэтому, если вам потребуются зоны со специфическими настройками, рекомендуется развернуть отдельную DNS-инфраструктуру, а в домене настроить перенаправление.

рис. 228 Список DNS-зон

Откроем прямую зону «ald.company.lan» и перейдем на вкладку «Параметры зоны», см. рис. 229:

• Полномочный сервер имен (primary name server) — сервер, который является владельцем этой DNS-зоны.

• Адрес электронной почты администратора (Responsible Person) — значение является обязательным, но не имеет значения для доменной зоны предприятия.

• Номер SOA (Serial Number) – серийный номер зоны, который может быть использован подчиненными DNS-серверами для синхронизации.

  Обратите внимание, что в домене FreeIPA серийный номер исключен из репликации во избежание «состояния гонок», поэтому это значение формируется каждым сервером индивидуально. Это не является проблемой для контроллеров, т.к. они реплицируют DNS-записи через LDAP, но, если вы будете настраивать репликацию Master-Slave со сторонней DNS-инфраструктурой, вам следует учитывать, что при переключении на другой DNS-сервер нужно будет принудительно выполнить загрузку зоны во избежание потерь информации.

• Обновление SOA (Refresh) – периодичность отправки запросов к владельцу зоны для обновления DNS-записей, значение указывается в секундах.

• Повторный запрос SOA (Retry) – время в секундах, через которое будет выполнен повторный запрос информации к серверу-владельцу, если он окажется недоступен.

• Окончание действия SOA (Expire) – время (в секундах), в течение которого вторичный сервер будет пытаться завершить синхронизацию зоны с первичным DNS-сервером.

• Минимальный срок жизни SOA (Minimum TTL) – время жизни кэша для негативного ответа на запрос в зоне.

• Срок жизни по умолчанию (Default TTL) – время по умолчанию, в течение которого информация будет кэшироваться другими DNS-серверами.

• Срок жизни (TTL) – время, в течение которого информация будет кэшироваться другими DNS-серверами.

• Динамическое обновление (Allow-update) – позволяет клиентам и DHCP-серверу автоматически обновлять DNS-записи для поддержания их в актуальном состоянии. Может быть разрешено или запрещено.

• Разрешить запрос (Allow-query) – определяет, кому разрешено запрашивать записи из этой зоны. По умолчанию разрешено всем («any»).

• Разрешить перенос (Allow-transfer) – определяет, каким Slave-серверам разрешен перенос зоны, т.е. её копирование. По умолчанию не разрешено никому («none»).

• Глобальные перенаправители (Global forwarders) и Политика перенаправления (Update-policy) – тут можно указать один или более глобальных перенаправителей и определить политику перенаправления.

• Состояние зоны DNS – позволяет отключить зону, не удаляя ее. Это может потребоваться в процессе отладки.

рис. 229 Параметры зоны ald.company.lan

Как мы можем убедиться, в LDAP-каталоге информация зоны хранится в записи с DN «idnsname=ald.company.lan,cn=dns,dc=ald,dc=company,dc=lan».

рис. 230 Запись «idnsname=ald.company.lan,cn=dns,dc=ald,dc=company,dc=lan»

Записи в доменной зоне

На вкладке Записи ресурсов DNS мы увидим все DNS-записи этой зоны, см. рис. 231.

рис. 231 Записи в зоне ald.company.lan

Каждая ресурсная запись содержит следующие атрибуты:

• Имя (NAME) — адрес, к которому «принадлежит» данная ресурсная запись.

• Тип (TYPE) — задает тип ресурсной записи, который определяет ее назначение.

• Поле данных (RDATA) — данные ресурсной записи, формат которых зависит от типа.

  Если открыть одну из SRV-записей _kerberos._tcp, которые используются для обнаружения центров распространения ключей Kerberos, когда к ним нужно обратиться по протоколу TCP, см. рис. 232, то в поле данных мы видим приоритет, вес, порт и цель.

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

• Класс (CLASS) — определяет тип сетей, добавлен из предположения, что DNS может использоваться не только в TCP/IP, но и с другими типами сетей.

• TTL (Time To Live) — допустимое время хранения данной ресурсной записи в кэше неответственного DNS-сервера.

• Длина поля данных (RDLEN) — дополнительная служебная информация.

рис. 232 DNS-запись _kerberos._tcp

Приведем список наиболее важных DNS-записей:

• Запись A (address record) или запись адреса — связывает имя хоста с адресом протокола IPv4, то есть запрос A-записи для имени dc-1.ald.company.lan вернет IPv4-адрес сервера dc-1 в домене ald.company.lan.

• Запись AAAA (IPv6 address record) — работает как А-запись только с протоколом IPv6.

• Запись CNAME (canonical name record) или каноническая запись имени (псевдоним) — используется для перенаправления на другое имя.

• Запись MX (mail exchange) или почтовый обменник — указывает сервер, который принимает входящую почту для домена.

• Запись NS (name server) — делегирует обслуживание зоны другому DNS-серверу.

• Запись PTR (pointer), обратная DNS-запись или запись указателя — позволяет по IP-адресу получить каноническое FQDN имя хоста.

  В домене Kerberos PTR-записи используются как средство защиты от различных атак. Например, при вводе машины в домен недостаточно в качестве DNS-сервера указать DNS-сервер из инфраструктуры MS AD, где настроено перенаправление прямой зоны. Нужно настроить перенаправление обратной зоны тоже или создать PTR-записи для контроллеров домена ALD Pro на DNS-сервере Microsoft.

• SRV-запись (server selection) — позволяет задать список серверов, которые предоставляют определенные сервисы в сети, например, LDAP, Kerberos, NTP. Эти записи необходимы для работы механизмов автоматического обнаружения сервисов и далее мы рассмотрим их подробнее.

• TXT-запись (text) — позволяет хранить в DNS любые настройки, например, политики обработки спама (Sender Policy Framework, SPF), публичный сертификат для проверки писем получателями с использованием цифровых подписей (DomainKeys Identified Mail, DKIM). С помощью текстовых записей, например, провайдеры могут запрашивать подтверждение того, что вы владеете доменным именем.

Вернемся к SRV-записям т.к. они очень активно используются в домене. Эти записи определяют местоположение определенных служб, то есть имя хоста и номер порта. SRV-запись имеет такой формат:

_<service>._<proto>.<name> <TTL> <class> <SRV> <priority> <weight> <port> <target>

Где:

• service — символьное имя сервиса (например, _ldap).

• proto — транспортный протокол, используемый сервисом (TCP или UDP).

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

• TTL — время жизни.

• class — поле класса (это всегда IN).

• SRV — тип записи (для SRV-записей всегда SRV).

• priority — приоритет целевого хоста, более низкое значение означает, что этот сервер более предпочтителен.

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

• port — номер порта TCP или UDP, на котором работает сервис.

• target — каноническое имя машины, предоставляющей сервис.

Вы можете добавить в домене свои собственные SRV-записи, но следует понимать, что служба каталога FreeIPA для своих сервисов создает немного специфичные SRV-записи. Этим записям в каталоге назначен класс idnsTemplateObject и задано дополнительное свойство «idnsTemplateAttribute;cnamerecord», которое определяет шаблон подстановки для поддержки технологии сайтов (локаций), см. рис. 233.

рис. 233 Шаблон idnsTemplateAttribute в SRV-записях службы FreeIPA

Для привязки серверов к сайтам у записей DN «cn=servers,cn=dns,dc=ald,dc=company,dc=lan» задано значение атрибута «idnsSubstitutionVariable;ipalocation», соответствующее имени сайта, в котором этот сервер находится, см. рис. 234.

рис. 234 Атрибут idnsSubstitutionVariable для контроллера домена

Например, при запросе _ldap._tcp.ald.company.lan у DNS-службы на контроллере 10.0.1.11 (dc-1.ald.company.lan) сервис BIND9 выполнит подстановку и вернет результат для адреса _ldap._tcp.hq_locations.ald.company.lan, что соответствует сайту головного офиса hq (англ. head quarters).

nslookup -q=SRV _ldap._tcp.ald.company.lan

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

admin@dc-1:~$ nslookup -q=SRV _ldap._tcp.ald.company.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
_ldap._tcp.ald.company.lan canonical name = _ldap._tcp.hq._locations.ald.company.lan.
_ldap._tcp.hq._locations.ald.company.lan service = 50 100 389 dc-4.ald.company.lan.
_ldap._tcp.hq._locations.ald.company.lan service = 0 100 389 dc-1.ald.company.lan.
_ldap._tcp.hq._locations.ald.company.lan service = 0 100 389 dc-2.ald.company.lan.
_ldap._tcp.hq._locations.ald.company.lan service = 50 100 389 dc-3.ald.company.lan.
_ldap._tcp.hq._locations.ald.company.lan service = 50 100 389 dc-5.ald.company.lan.

Как вы можете заметить, в список будут включены все контроллеры домена, но для серверов из сайта hq приоритет будет равен 0, а у всех остальных 50, поэтому служба SSSD будет в первую очередь обращаться к контроллерам из «своего» сайта. Таким образом, привязка хостов к сайтам выполняется через DNS-сервер, который их обслуживает.

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

• Практическая работа: Модуль 3. Базовые функции и настройка ALD Pro
• Тест: Модуль 3. Базовые функции и настройка ALD Pro

Заключение

В этом модуле мы познакомились поближе с архитектурой портала управления и двумя сетевыми службами контроллера домена: NTP и DNS. В следующем модуле мы перейдем к таким компонентам, как KDC, LDAP, и узнаем, зачем нужна Samba AD на контроллерах FreeIPA.

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

• Проект эталонного времени от ФГУП «ВНИИФТРИ»

• Рекомендуем ознакомиться также с видеороликами нашего хорошего товарища на канале «ИТ-Проповедник». Учитывайте, что ролики записаны для версии 2.2.1, поэтому часть информации потеряла актуальность, но в целом они могут быть крайне полезны.

  • Установка Apache Directory Studio на Astra Linux 1.7 в домене ALD Pro

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

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