Модуль 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 и передает приложению через WSGI (англ. Web Server Gateway Interface), а клиентская часть написана на React и взаимодействует с сервером через JSON API.

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

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

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

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

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

Стоит также отметить, что запросы, на выполнение которых требуется много времени, бэкенд выполняет в асинхронном режиме. Активация роли, например, выполняется через Celery, а задача на повышение роли сервера передается в Salt-мастер через RabbitMQ.

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

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

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

Ранее вход по логину/паролю осуществлялся средствами базовой аутентификации (англ. Basic Auth), поэтому при переходе на страницу портала веб-браузер получал ответ со статусом 401 (Unauthorized) и заголовком WWW-Authenticate, в котором содержалось требование предоставить учетные данные в заголовке Authorization. Форма для ввода учетных данных в этом случае предоставлялась средствами браузера.

С версии ALD Pro 2.0.0 страница для входа реализует собственную веб-форму для входа, которая передает данные на сервер через POST-запрос, что позволяет сделать процесс входа более понятным и реализовать такие функции, как изменение истекшего пароля. Но обратите внимание, что как в случае базовой аутентификации, так и при использовании веб-формы передача пароля на сервер выполняется в открытом виде, см. рис. 176.

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

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

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

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

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.

   

   рис. 177 Аутентификация на портале через 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. В случае простых веб-приложений сервер Apache настраивают так, чтобы он мог проверять TGS-билеты самостоятельно без обращения к службе GSS-Proxy, тогда ему дают доступ к keytab-файлу напрямую.

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

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

admin@dc-1:~$ 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 <имя_пользователя>.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Служба разрешения имен — в этом разделе вы можете настроить работу встроенного DNS-сервера. В домене есть как минимум прямая и обратная зоны. Вы можете настроить перенаправление зон и глобальный перенаправитель.

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

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

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

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

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

Мониторинг

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

рис. 180 Запрет на удаление структурного подразделения

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

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

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

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

рис. 182 Сохранение нового структурного подразделения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Учетная запись — раздел позволяет задать 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) не могут быть вложены друг в друга. Эту возможность дают доменные группы, поэтому на этой вкладке есть раздел Состоит в группах непрямое наследование, в котором указаны все группы, в которые входит пользователь через наследование.

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

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

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

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

От самой системы ALD Pro вам доступны следующие роли:

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

• ALDPRO - IT Security Specialist — администратор информационной безопасности имеет доступ на управление групповыми политиками, а также подсистемами мониторинга и аудита.

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

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

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

• Enrollment Administrator — администратор, присоединяющий рабочие станции к домену. Требуется дополнительная настройка этой роли для использования.

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

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

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

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

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

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

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

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

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

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

На карточке вам доступны следующие атрибуты компьютера:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С дополнительной информацией по группам пользователей вы можете ознакомиться в справке ALD Pro https://dc-1.ald.company.lan/ad/help/ui/29.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 включительно.

рис. 193 Иерархия 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/lib/chrony/chrony-helper, который позволяет, например, создать в операционной системе службу, которая будет извлекать имена NTP-серверов из SRV-записей.

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

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

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

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

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

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

• Система ALD Pro использует параметр makestep, поэтому при синхронизации времени компьютер сразу устанавливает требуемое значение. Если у вас будет отсутствовать этот параметр, то служба будет крайне медленно «подтягивать» время к требуемому значению (по несколько секунд в минуту), и вам будет казаться, что синхронизация времени не работает. Форсировать переход к целевому значению в этом случае вы можете вызовом команды chronyc 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, и тут же получишь ответ, см. рис. 194.

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

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

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

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

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

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

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

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

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

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:

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.

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

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-записей достаточно передать утилите просто имя сайта:

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

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-сервера после доменного имени:

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

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

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. Многие считают, что название утилиты означает «копать», что недалеко от истины, но на самом деле это название является аббревиатурой от 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.keys — файл с ключами для аутентификации DHCP-сервера, если мы захотим, чтобы он мог автоматически обновлять DNS-записи хостов.

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

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

• Файл /etc/bind/ipa-options-ext.conf — содержит опции DNS-сервера от IPA.

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

  /* User customization for BIND named
  *
  * This file is included in /etc/bind/named.conf and is not modified during IPA
  * upgrades.
  * It must only contain "options" settings. Any other setting must be
  * configured in /etc/bind/ipa-ext.conf.
  *
  * Examples:
  * allow-recursion { trusted_network; };
  * allow-query-cache { trusted_network; };
  * /
  
  /* turns on IPv6 for port 53, IPv4 is on by default for all ifaces */
  listen-on-v6 { any; };
  /* dnssec-enable is obsolete and 'yes' by default */
  dnssec-validation no;
  allow-recursion { any; };
  allow-query-cache { any; };
  

• Файл /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/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, см рис. 197, то вы сможете увидеть, что в атрибутах записи с DN «cn=dns,dc=ald,dc=company,dc=lan», хранятся настройки, которые мы задаем на странице Роли и службы сайта ‣ Служба разрешения имен ‣ Глобальная конфигурация DNS, см. рис. 198.

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

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

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

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

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

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

• Полномочный сервер имен (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 – позволяет отключить зону, не удаляя ее. Это может потребоваться в процессе отладки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

рис. 203 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, где настроено перенаправление прямой зоны. Нужно настраивать перенаправление и обратной зоны тоже.

• 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», которое определяет шаблон подстановки для поддержки технологии сайтов (локаций), см. рис. 204.

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

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

рис. 205 Атрибут 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).

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.

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

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