Миграция домена с windows на linux

Возможности гибридного развертывания

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

• Нужны квалифицированные администраторы, чтобы перенастроить информационные системы для работы в Linux-домене. Не всегда есть готовые решения, особенно для корпоративных приложений, поэтому требуются дополнительные исследования и длительное тестирование.

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

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

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

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

  Между доменами MS Active Directory и ALD Pro (FreeIPA) возможно установление одно- и двусторонних транзитивных доверительных отношений лес к лесу и одно- и двусторонних нетранзитивных доверительных отношений домен к домену (external trusts).

  Для полноценной поддержки двусторонних отношений на стороне ALD Pro реализована функция глобального каталога, чего нет в ванильной версии FreeIPA, — это позволяет на стороне Windows при назначении прав доступа в стандартных оснастках Windows выполнять поиск по объектам доверенного леса ALD Pro.

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

• Прямая работа Linux машин в домене MS AD. Позволяет пользователям AD входить в Linux машины и выполнять прозрачную аутентификацию при обращении к «керберизированным» сервисам в домене. Реализация сценария возможна с помощью старой клиентской части Winbind или улучшенной альтернативы SSSD. Служба SSSD поддерживает и более экзотические сценарии работы, например, когда машина находится в двух доменах сразу.

• Прямая работа Windows машин в домене ALD Pro (FreeIPA). Позволяет пользователям ALD Pro входить на рабочие станции Windows и выполнять прозрачную аутентификацию при обращении к «керберизированным» сервисам в домене. Реализация сценария возможна в силу нативной поддержки Kerberos-доменов со стороны Windows и расширенных возможностей FreeIPA, которые дает интеграция с Samba AD.

• Реализация единого входа для веб-приложений через обмен цифровыми удостоверениями по протоколам OAuth, OpenID, SAML.

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

• серверные приложения,

• рабочие места клиентов и

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

Серверные приложения по сложности миграции можно классифицировать на несколько групп:

• Непереносимые:

  • Приложения, которые работают только с AD DS, например, MS Exchange. Потребуют замены на аналоги (RuPost, CommuniGate или VK WorkMail).

  • Приложения, которые интегрированы с каталогом через NTLM, могут потребовать существенных доработок, хотя на контроллерах домена для работы в доверительных отношениях интегрирован компонент Samba AD, который предоставляет этот интерфейс.

• Переносимые:

  • Приложения, которые интегрированы с каталогом через Kerberos, например, 1С, и, соответственно, вся линейка этих учетных систем.

  • Приложения, которые интегрированы через LDAP, например, Bitrix24.

  • Web-приложения, которые интегрированы через обмен цифровыми удостоверениями по протоколам OAuth, OpenID, SAML.

Картинка с сайта: www.aldpro.ru

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

• MS Windows в домене MS AD — это исходные данные для начала миграции.

• Astra Linux в домене MS AD через SSSD или Winbind — промежуточный сценарий, который позволит начать замену клиентских приложений.

• MS Windows в домене ALD Pro — промежуточный этап, который поможет в тех случаях, когда невозможно заменить или переписать какие-то специфичные клиентские приложения. Вместе с тем не забывайте, что в некоторых случаях может помочь среда для запуска Windows-приложений Wine.

• Astra Linux в домене ALD Pro через SSSD — это то, к чему рекомендуется прийти.

Учетные записи могут быть:

• Из домена ALD Pro (FreeIPA);

• Из домена MS AD (в т.ч. Samba AD DC 4.7+);

• Локальные (не рекомендуется).

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

Типовые сценарии развертывания

Сценарий «Сервисный домен»

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

Картинка с сайта: www.aldpro.ru

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

• Централизованное управление учетными записями администраторов системы, включая их SSH-ключи.

• Автоматизация настройки ОС Astra Linux на серверах через механизм групповых политик ALD Pro (через Salt-скрипты).

• Контроль доступа к серверам через правила HBAC и SUDO.

Сценарий «Ресурсный домен»

В домен ALD Pro переносятся не только серверы, но и «керберизированные» сетевые приложения (ресурсы), такие как файловые серверы, корпоративные веб-приложения и т.д. Пользователи и рабочие места сотрудников остаются в домене AD, доступ к ресурсам осуществляется через механизм доверительных отношений.

Картинка с сайта: www.aldpro.ru

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

• Прозрачная аутентификация пользователей при обращении к ресурсам в Linux-домене через механизм доверительных отношений.

• Возможность постепенного переноса корпоративных приложений в Linux-инфраструктуру по мере их готовности.

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

Сценарий «Управление рабочими местами»

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

Картинка с сайта: www.aldpro.ru

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

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

• Контроль доступа к рабочим станциям через правила HBAC и SUDO.

• Установка ОС на рабочие станции пользователей по сети.

Служба каталога FreeIPA поддерживает транзитивные двусторонние доверительные отношения с лесом Active Directory, извлекая информацию обо всех поддоменах. Первый и второй уровни работают по умолчанию, для поддержки третьего и последующих уровней требуется внесение дополнительных настроек.

Права доступа и политики в домене ALD Pro можно будет назначать как на отдельных пользователей доверенных доменов, так и на группы, используя механизм внешних групп (External Groups).

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

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

Если в компании используются толстые клиенты, разработанные под операционную систему Windows, в некоторых случаях их получится запускать из-под Linux, используя среду для запуска Windows-приложений Wine, с пробросом Kerberos-ключей через GSSAPI и связку ключей ядра Linux. Wine — это не самый стабильный продукт, но в случае бизнес-приложений, которые не используют аппаратное ускорение и другие продвинутые API, этот способ может вполне сработать.

Сценарий «Полное развертывание инфраструктуры»

В данном сценарии пользователи и сервисы работают в домене ALD Pro, интеграция с Active Directory не используется. Этот сценарий не является примером гибридного развертывания, его следует считать результатом полного импортозамещения, когда все пользователи и сервисы переведены на Linux и интеграция с инфраструктурой Windows больше не требуется.

Картинка с сайта: www.aldpro.ru

Механизм работы доверительных отношений

Доверительные отношения дают возможность пользователям одного домена выполнять прозрачную аутентификацию по протоколу Kerberos V5 при обращении к ресурсам другого домена. Например, вы можете разрешить пользователям из домена AD DS входить в операционную систему компьютеров под управлением Astra Linux из домена ALD Pro или, наоборот, дать возможность пользователям ALD Pro подключаться с компьютеров Astra Linux к общим файловым ресурсам, находящимся в домене AD DS, см. рис. 318.

Картинка с сайта: www.aldpro.ru

Система ALD Pro построена на базе службы каталога FreeIPA, в которой поддержка доверительных отношений с AD DS появилась с версии 3.0 путем интеграции с пакетом программ Samba. Доверительные отношения могут быть установлены как между лесами, где FreeIPA выступает в роли леса с одним доменом (Forest Trust), так и между конкретными доменами (External Trust), что в определенных случаях может быть предпочтительнее, например, чтобы сократить количество рекурсивных запросов на получение cross-realm билетов.

Механизм доверительных отношений реализован в протоколе аутентификации Kerberos V5, и понятие доверия является его фундаментом. Например, когда вы выполняете первый вход в операционную систему, у службы SSSD нет прямого доступа к вашим учетным данным, поэтому она не может выполнить проверку аутентичности самостоятельно и вынуждена доверять сервисному билету, выданному контроллером домена. Основанием для доверия является тот факт, что билет зашифрован паролем учетной записи компьютера, который известен только контроллерам домена и самому компьютеру. На стороне контроллера пароль хранится в LDAP-каталоге в атрибуте krbPrincipalKey учетной записи хоста, а на стороне компьютера в специальном файле на диске, см. klist -k /etc/krb5.keytab.

Доверие между доменами работает похожим образом: в момент установления отношений в каждом из доменов создается специальная учетная запись доверенного домена с общим ключом или так называемый объект доверенного домена (trusted domain object, TDO). С помощью этого ключа «доверенный домен» (англ. trusted domain) шифрует кросс-доменные билеты пользователей, а «доверяющий домен» (англ. trusting domain) эти билеты расшифровывает и проверяет. Для доверяющего домена такое отношение считается исходящим (outgoing), а для доверенного домена оно считается входящим (incoming), т.е. направление доверия и направление доступа
противоположны друг другу, см. рис. 319.

Картинка с сайта: www.aldpro.ru

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

Картинка с сайта: www.aldpro.ru

Рассмотрим, как работает аутентификация с использованием доверительных отношений, когда пользователю доверенного домена ALD.COMPANY.LAN нужно пройти аутентификацию в службе из доверяющего домена WIN.COMPANY.LAN, см. рис. 320:

1. Пользователь ALD запрашивает TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN у контроллера из своего родного домена ALD для выполнения последующей аутентификации на контроллерах ALD.

2. Контроллер ALD располагает учетными данными пользователя из своего домена, поэтому может подтвердить аутентичность запроса и выдать ему TGT-билет. Если пользователь сможет расшифровать ответ, он подтвердит тем самым свою аутентичность.

3. Пользователь ALD, используя TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN, обращается к контроллеру ALD за билетом cifs/fs-1.win.company.lan@ALD.COMPANY.LAN для последующей аутентификации в службе cifs на файловом сервере fs-1 из доверяющего домена WIN.

4. Контроллер ALD располагает мастер-ключом домена ALD, поэтому может успешно проверить аутентичность пользователя, но у него нет учетных данных службы из доверяющего домена WIN, поэтому контроллер возвращает ошибку KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

5. Пользователь ALD, используя TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN, обращается к своему контроллеру ALD за кросс-доменным TGT-билетом krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN для последующей аутентификации на контроллерах домена WIN.

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

   Кросс-доменный билет является вспомогательным, поэтому не сохраняется в связке ключей, и вы не сможете увидеть его командой klist, если только не запросите его целевым образом с помощью команды kvno krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN.

   Далее шаги 5 и 6 могут повториться рекурсивно несколько раз по количеству доменов, которые будут стоять на пути между клиентом и сервисом. Если домен A доверяет домену B, а домен B доверяет домену C, то пользователи из домена C могут получить доступ к сервисам из домена A транзитивно через домен B. По умолчанию доверительные отношения между ALD Pro и AD DS устанавливаются транзитивными.

7. Пользователь ALD, используя TGT-билет krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN, обращается к контроллеру WIN за полноценным TGT-билетом krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN.

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

9. Пользователь ALD, используя TGT-билет krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN, обращается к контроллеру WIN за билетом cifs/fs-1.win.company.lan@WIN.COMPANY.LAN для аутентификации в службе cifs на файловом сервере fs-1 из этого домена.

10. Контроллер WIN располагает мастер-ключом домена WIN, поэтому может успешно проверить аутентичность пользователя. Контроллер WIN располагает также учетными данными сервиса из своего домена, поэтому успешно выдает пользователю TGS-билет cifs/fs-1.win.company.lan@WIN.COMPANY.LAN.

11. Пользователь ALD, используя TGS-билет cifs/fs-1.win.company.lan@WIN.COMPANY.LAN, обращается к службе cifs на файловом сервере fs-1 из домена WIN.

12. Файловый сервер располагает паролем службы cifs, поэтому может проверить и подтвердить аутентичность пользователя.

Протокол Kerberos V5 регламентирует не только порядок аутентификации, но и позволяет передавать внутри билетов авторизационную информацию (поле AuthorizationData). Разработчики Active Directory разработали свой собственный стандарт MS-KILE, в соответствии с которым в этом поле можно передавать сертификат атрибута привилегий (Privilege Attribute Certificate, PAC), который содержит идентификаторы безопасности всех групп, участником которых является пользователь.

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

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

При формировании сертификата используются значения атрибута ipaNTSecurityIdentifier, в котором хранится SID в формате MS Windows. Это значение рассчитывается в момент создания субъекта безопасности в соответствии с настройками текущего диапазона идентификаторов, за что отвечает плагин sidgen.

Посмотреть SID любого объекта можно, например, с помощью команды sudo wbinfo -n 'ALD\\admin', где ALD — это NetBIOS имя домена ald.company.lan, admin — это имя субъекта:

admin@dc-1:~$ sudo wbinfo -n 'ALD\\admin'
S-1-5-21-1724891028-2898148248-1736958143-500 SID_USER (1)

Как мы видим, последний компонент идентификатора RID для пользователя admin из домена ALD Pro равен 500, что по соглашению MS соответствует идентификатору учетной записи Administrator. Можно добавить, что идентификатор группы admins равен 512, что соответствует группе Domain Admins. Относительные идентификаторы обычных пользователей и групп начинаются с 1000.

При желании вы можете исследовать PAC-сертификат Kerberos-билетов пользователей FreeIPA с помощью команды net ads kerberos pac и убедиться, что все необходимые идентификаторы там присутствуют. Но вы не сможете назначить права доступа пользователям FreeIPA, т.к. стандартные оснастки Windows выполняют поиск объектов доверенного леса путем обращения к глобальному каталогу на порт 3268/TCP.

Именно по этой причине довольно часто можно встретить утверждение, что FreeIPA не поддерживает двусторонние доверительные отношения, т.к. с одной стороны они есть, но пользоваться ими невозможно. Для решения этой проблемы в системе ALD Pro был реализован модуль глобального каталога, см. рис. 321:

Картинка с сайта: www.aldpro.ru

Пользователям ванильных версий FreeIPA можно только предложить пару обходных решений. Во-первых, на объекты файловой системы доступ можно назначить напрямую по идентификатору безопасности субъекта с помощью утилиты ICACLS (Integrity Control Access Control List).

c:\> ICACLS "C:\\Common" /grant:r "\*S-1-5-21-896088827-1417987318-1335504985-500 " /T

Кстати, в стандартном окне свойств файлового менеджера такие пользователи будут отображаться под своими обычными именами, т. к. процедура разрешения имен работает через RPC-вызов по протоколу SMB (445/TCP) без участия глобального каталога.

Во-вторых, можно воспользоваться более универсальным способом и назначать права через группы безопасности с областью действия «Локальный домен» (Domain Local). Добавить пользователей доверенного домена FreeIPA в локальную доменную группу можно следующим образом на powershell:

#SID Из леса ALD_Pro(Пользователь или группа)
$AldSid = 'S-1-5-21-1784717832-1844364183-3442789864-1013'

#Domain Local Group из леса Active Directory
$DomainLocalGroupDN = 'CN=Contoso-Group-DL,CN=Users,DC=contoso,DC=dom'

#Создание нового Directory Entry
$group = New-Object DirectoryServices.DirectoryEntry("LDAP://$($DomainLocalGroupDN)")

#Добавление AldSid в DomainLocal группу
[void]$group.member.Add("<SID=$AldSid>")
$group.CommitChanges()
$group.Close()

В обратном направлении работа с авторизационной информацией поставлена немного иначе. В билетах Kerberos, конечно же, есть PAC-сертификат, но Linux-приложения запрашивают эту информацию через вызовы к системным библиотекам, которые обрабатываются службой SSSD. Например, при вызове утилиты id никакие Kerberos-билеты пользователя не требуются:

admin@dc-1:~$ id Administrator@WIN.COMPANY.LAN
uid=1633600500(administrator@win.company.lan) gid=1633600500(administrator@win.company.lan)
группы=1633600500(administrator@win.company.lan),1633600520(group policy creator
owners@win.company.lan),1633600519(enterprise admins@win.company.lan),1633600512(domain
admins@win.company.lan),1633600518(schema admins@win.company.lan),1633600513(domain
users@win.company.lan),959800006(fs_users)

Для получения авторизационной информации на пользователя Administrator из домена WIN.COMPANY.LAN служба SSSD делает не обычный поисковый LDAP-запрос, а отправляет расширенную операцию, которую на стороне сервера обрабатывает плагин exdom. Учитывая, что в LDAP-каталоге нужной информации нет, плагин обращается к службе SSSD на сервере, которая обрабатывает этот запрос по-разному в зависимости от того, какая роль назначена серверу:

• На контроллерах доверия служба SSSD напрямую обращается к контроллерам AD DS по протоколу LDAP для преобразования идентификаторов и извлечения информации об участии пользователей доверенного домена в группах.

• На агентах доверия служба SSSD проксирует такие запросы на один из контроллеров доверия ALD Pro, опять же, путем выполнения расширенной LDAP-операции.

Осталось только разобраться с идентификаторами. Учитывая, что в среде Linux используются не SID, а POSIX-идентификаторы, на стороне ALD Pro служба SSSD выполняет сопоставление идентификаторов одним из двух способов:

1. Если в AD DS установлен компонент Identity Management for UNIX (что маловероятно), то у объектов будут заданы атрибуты uidnumber/gidnumber, и вы сможете их использовать. Для этого в момент установления доверительных отношений следует указать параметр ipa-ad-trust-posix.

2. Если компонента Identity Management for UNIX нет (что вероятно), то параметр ipa-ad-trust-posix задавать не нужно, и по умолчанию идентификаторы будут рассчитываться математически. Для этого на стороне FreeIPA каждому доверенному домену из леса AD DS будет назначен диапазон POSIX-идентификаторов. Размер этого диапазона по умолчанию составляет 200 тысяч идентификаторов, поэтому для крупных доменов AD DS его нужно будет расширить вручную.

Вы можете назначать права доступа непосредственно на эти идентификаторы или задействовать внешние группы (External groups), которые являются аналогом Domain Local групп AD DS, т.к. позволяют добавлять субъекты из доверенного домена. Единственно, учтите, что у внешних групп нет POSIX-идентификаторов, поэтому для предоставления доступа к файловым ресурсам вам нужно будет включить их в состав обычных POSIX-групп.

Например, в следующем примере показано, как доменных администраторов AD DS можно включить в группу доменных администраторов ALD Pro:

admin@dc-1:~$ ipa group-add 'ad_admins_external' --external --desc='Группа администраторов AD DS'
admin@dc-1:~$ ipa -n group-add-member 'ad_admins_external' --external 'WIN.COMPANY.LAN\\Domain Admins'
admin@dc-1:~$ ipa group-add-member admins --groups='ad_admins_external'
admin@dc-1:~$ id Administrator@WIN.COMPANY.LAN
… 959800000(admins) …

Настройка доверительных отношений

Взаимное перенаправление DNS-зон

Для работы доверительных отношений нужно, чтобы из домена ald.company.lan разрешались доменные имена зоны win.company.lan и наоборот. Для этого нам нужно сделать взаимное перенаправление DNS-зон.

Для создания перенаправителя в домене win.company.lan выполните на контроллере домена AD DS следующую команду PowerShell:

PS> Add-DnsServerConditionalForwarderZone -Name "ald.company.lan" -ReplicationScope "Forest" -MasterServers [IP адрес ALDPro контроллера]

Проверьте возможность разрешения имен из зоны ald.company.lan:

admin@dc-1:~$ ping dc-1.ald.company.lan

Из интерфейса DNS-перенаправитель можно создать в оснастке DNS Manager, см.:numref:mod9_figure_image15:

Картинка с сайта: www.aldpro.ru

Для создания перенаправителя в домене ald.company.lan выполните на контроллере домена ALD Pro следующую команду bash:

admin@dc-1:~$ ipa dnsforwardzone-add win.company.lan --forwarder=[IP адрес контроллера MS AD] --forward-policy=only

Проверьте возможность разрешения имен из зоны win.company.lan:

admin@dc-1:~$ ping dc-1.win.company.lan

Из интерфейса DNS-перенаправитель можно создать на странице , см. рис. 323:

Картинка с сайта: www.aldpro.ru

allow-recursion { trusted_network; };
allow-query-cache { trusted_network; }

listen-on-v6 { any; };

dnssec-validation no;

acl "trusted_network" {
  localnets;
  localhost;
  192.168.88.0/24;
  172.19.3.0/24;
  172.19.4.0/24;
};

admin@dc-1:~$ systemctl status chrony.service
admin@dc-1:~$ chronyc sources -v
admin@dc-1:~$ chronyc tracking

c:\> w32tm.exe /query /configuration
c:\> w32tm.exe /query /status
(Get-Date).ToUniversalTime()

Создание траста между лесами (Forest Trust)

Во всех инструкциях создание траста начинают с выполнения команды ipa-adtrust-install, которая подготавливает домен FreeIPA к работе с доверительными отношениями, в частности добавляет атрибут для хранения windows security identifier (SID). В случае ALD Pro это не требуется. Попробуйте команду ipa trustconfig-show, чтобы убедиться в наличии идентификатора безопасности SID у домена:

admin@dc-1:~$ ipa trustconfig-show
 Домен: ald.company.lan
 Идентификатор безопасности: S-1-5-21-1307086432-2724870100-1147875473
 Имя NetBIOS: ALD
 GUID домена: 7a522ccc-a0d7-4eac-a46a-46b12c93fa0e
 Резервная основная группа: Default SMB Group
 Агенты отношений доверия AD IPA: dc-1.ald.company.lan
 Контролёры отношений доверия AD IPA: dc-1.ald.company.lan

Перед созданием доверительных отношений нужно получить TGT-билет для учетной записи администратора домена admin:

admin@dc-1:~$ kinit admin

Траст можно добавить на стороне ALD Pro из командной строки.

admin@dc-1:~$ ipa -d -v trust-add --type=ad win.company.lan --admin administrator --password --two-way=true
--------------------------------------------------------------------------------
Добавлено отношение доверия Active Directory для области (realm) "win.company.lan"
--------------------------------------------------------------------------------
Имя области (realm): win.company.lan
Имя домена NetBIOS: WIN
Идентификатор безопасности домена: S-1-5-21-292663598-2229028806-4201728183
Направление отношения доверия: Двустороннее отношение доверия
Тип отношения доверия: Домен Active Directory
Состояние отношения доверия: Установлено и проверено

Где:

• win.company.lan — задает FQDN имя домена AD DS, с которым требуется установить доверительные отношения.

• Ключ -d — активируют режим отладки.

• Ключ -v — активирует расширенный режим вывода информации.

• Ключ --admin — задает имя привилегированной учетной записи из домена AD.

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

  При установлении отношений рекомендуется указывать пароль, так как в этом случае все настройки будут выполнены автоматически. Но, если указанные учетные данные вам недоступны, вы можете попросить администратора домена AD DS создать траст на своей стороне и сообщить вам пароль доверительных отношений (trust password). В этом случае при установлении отношений нужно будет использовать ключ --trust-secret.

• Ключ --two-way — указывает на то, что доверительные отношения должны быть двусторонними.

Через графический интерфейс создать доверительные отношения можно на странице , см. рис. 324:

Картинка с сайта: www.aldpro.ru

Если в этот момент отслеживать сетевой траффик, то можно будет увидеть, что аутентификация в домене AD DS выполняется по Kerberos, а установление траста выполняется по транспортному протоколу SMB2 путем вызова удаленных команд RPC (да-да, вы уже знаете, что SMB-протокол — это не только файлы и принтеры). В тоже время билет на доступ к службе krbtgt в Windows домене не сохраняется в кэше sssd, поэтому команда klist после установления траста не покажет вам дополнительных билетов.

После создания доверия можно посмотреть информацию о созданном трасте командами ipa trust-find и ipa trust-show:

admin@dc-1:~$ ipa trust-find
---------------------------
найдено 1 отношение доверия
---------------------------
  Имя области (realm): win.company.lan
  Имя домена NetBIOS: WIN
  Идентификатор безопасности домена: S-1-5-21-292663598-2229028806-4201728183
  Тип отношения доверия: Домен Active Directory
---------------------------------
Количество возвращённых записей 1
---------------------------------

admin@dc-1:~$ ipa trust-show win.company.lan
  Имя области (realm): win.company.lan
  Имя домена NetBIOS: WIN
  Идентификатор безопасности домена: S-1-5-21-292663598-2229028806-4201728183
  Направление отношения доверия: Двустороннее отношение доверия
  Тип отношения доверия: Домен Active Directory

И не забудьте, что для больших доменов AD DS нужно расширить диапазон идентификаторов, который по умолчанию составляет 200 тысяч. Для этого нужно воспользоваться командой ipa idrange-mod утилиты ipa. Точное имя диапазона можно посмотреть командой ipa idrange-find.

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

  Имя диапазона: WIN.COMPANY.LAN_id_range
  Первый идентификатор POSIX диапазона: 1633600000
  Количество идентификаторов в диапазоне: 200000
  Первый RID соответствующего диапазона RID: 0
  SID доверенного домена: S-1-5-21-3250248711-3862619044-3424259349
  Тип диапазона: Active Directory domain range

---------------------------------
Количество возвращённых записей 2
---------------------------------
admin@dc-1:~$ ipa idrange-mod --range-size=1000000 WIN.COMPANY.LAN_id_range
ipa: WARNING: Для применения изменений конфигурации необходимо перезапустить службу sssd.service
на IPA-сервере WIN.COMPANY.LAN_id_range.
-------------------------------------------------------------
Изменён диапазон идентификаторов "WIN.COMPANY.LAN_id_range"
-------------------------------------------------------------
  Имя диапазона: WIN.COMPANY.LAN_id_range
  Первый идентификатор POSIX диапазона: 1633600000
  Количество идентификаторов в диапазоне: 1000000
  Первый RID соответствующего диапазона RID: 0
  SID доверенного домена: S-1-5-21-3250248711-3862619044-3424259349
  Тип диапазона: Active Directory domain range

Если со временем в лесу Active Directory появятся дополнительные поддомены, нужно будет выполнить вручную команду trust-fetch-domains утилиты ipa, чтобы для этих доменов были созданы диапазоны идентификаторов:

admin@dc-1:~$ ipa trust-fetch-domains "WIN.COMPANY.LAN"

admin@dc-1:~$ ipa -d -v trust-add --type=ad win.company.lan --admin administrator --password --two-way=true
--external=true
--------------------------------------------------------------------------------
Добавлено отношение доверия Active Directory для области (realm) "win.company.lan"
--------------------------------------------------------------------------------
  Имя области (realm): win.company.lan
  Имя домена NetBIOS: WIN
  Идентификатор безопасности домена: S-1-5-21-292663598-2229028806-4201728183
  Направление отношения доверия: Двустороннее отношение доверия
  Тип отношения доверия: Нетранзитивное внешнее отношение доверия с доменом в другом лесу Active
Directory
  Состояние отношения доверия: Установлено и проверено

admin@dc-1:~$ ipa trust-del win.company.lan

Проверка работоспособности доверительных отношений

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

Посмотреть настройки доверия можно командой ipa trustconfig-show:

admin@dc-1:~$ ipa trustconfig-show
Домен: ald.company.lan
Идентификатор безопасности: S-1-5-21-1307086432-2724870100-1147875473
Имя NetBIOS: ALD
GUID домена: 7a522ccc-a0d7-4eac-a46a-46b12c93fa0e
Резервная основная группа: Default SMB Group
Агенты отношений доверия AD IPA: dc-1.ald.company.lan dc-XX.ald.company.lan
Контролёры отношений доверия AD IPA: dc-1.ald.company.lan dc-XX.ald.company.lan

Посмотреть все доверительные отношения можно командой ipa trust-find:

admin@dc-1:~$ ipa trust-find
---------------------------
найдено 1 отношение доверия
---------------------------
  Имя области (realm): win.company.lan
  Имя домена NetBIOS: WIN
  Идентификатор безопасности домена: S-1-5-21-3250248711-3862619044-3424259349
  Тип отношения доверия: Домен Active Directory
---------------------------------
Количество возвращённых записей 1
---------------------------------

Детальную информацию о конкретном трасте покажет команда ipa trust-show <REALM>:

admin@dc-1:~$ ipa trust-show win.company.lan
  Имя области (realm): win.company.lan
  Имя домена NetBIOS: WIN
  Идентификатор безопасности домена: S-1-5-21-3250248711-3862619044-3424259349
  Направление отношения доверия: Двустороннее отношение доверия
  Тип отношения доверия: Домен Active Directory

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

admin@dc-1:~$ rm -rf /var/lib/sss/db/\* /var/lib/sss/mc/\* && systemctl restart sssd
admin@dc-1:~$ id 'win\\administrator'
admin@dc-1:~$ id administrator@win.company.lan

Пример результата:

admin@dc-1:~$ id administrator@win.company.lan
uid=1131400500(administrator@win.company.lan) gid=1131400500(administrator@win.company.lan)
группы=1131400500(administrator@win.company.lan),1131400520(group policy creator
owners@win.company.lan),1131400513(domain users@win.company.lan),1131400519(enterprise
admins@win.company.lan),1131400518(schema admins@win.company.lan),1131400512(domain admi
ns@win.company.lan)

Проверять работу аутентификации в доверительных отношениях, выполняя kinit на машине ALD Pro пользователем из доверенного домена AD DS, на самом деле совершенно бесполезно. Доверительные отношения в этом случае не используются. Для корректной работы этого механизма вполне достаточно, чтобы было настроено перенаправление DNS-зон. Вы можете включить расширенную трассировку, чтобы увидеть, что запрос уходит сразу на IP-адрес контроллера домена WIN.

admin@dc-1:~$ KRB5_TRACE=/dev/stderr kinit administrator@win.company.lan
[30804] 1698829046.855690: Resolving unique ccache of type KEYRING
[30804] 1698829046.855691: Getting initial credentials for administrator@win.company.lan
[30804] 1698829046.855693: Sending unauthenticated request
[30804] 1698829046.855694: Sending request (195 bytes) to win.company.lan
[30804] 1698829046.855695: Initiating TCP connection to stream 192.168.88.85:88
[30804] 1698829046.855696: Sending TCP request to stream 192.168.88.85:88
[30804] 1698829046.855697: Received answer (198 bytes) from stream 192.168.88.85:88
[30804] 1698829046.855698: Terminating TCP connection to stream 192.168.88.85:88
[30804] 1698829046.855699: Response was from master KDC
[30804] 1698829046.855700: Received error from KDC: -1765328359/Additional pre-authentication
required
[30804] 1698829046.855703: Preauthenticating using KDC method data
[30804] 1698829046.855704: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15),
PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
[30804] 1698829046.855705: Selected etype info: etype aes256-cts, salt "WIN-
F8I3I8FPJ70Administrator", params ""
[30804] 1698829046.855706: PKINIT client has no configured identity; giving up
[30804] 1698829046.855707: PKINIT client has no configured identity; giving up
[30804] 1698829046.855708: Preauth module pkinit (16) (real) returned: 22/Недопустимый аргумент
Password for administrator@win.company.lan:

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

admin@dc-1:~$ kinit admin
Password for admin@ALD.COMPANY.LAN:

admin@dc-1:~$ kvno cifs/dc-1.win.company.lan@WIN.COMPANY.LAN
cifs/dc-1.win.company.lan@WIN.COMPANY.LAN: kvno = 5
admin@dc-1:~$ klist
Ticket cache: KEYRING:persistent:959800000:krb_ccache_bkldI6V
Default principal: admin@ALD.COMPANY.LAN

Valid starting       Expires              Service principal
24.04.2024 13:58:37  25.04.2024 23:58:37  cifs/dc-1.win.company.lan@WIN.COMPANY.LAN
24.04.2024 13:58:37  25.04.2024 23:58:37  krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN
24.04.2024 13:58:37  25.04.2024 13:58:32  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

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

admin@dc-1:~$ kvno krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN
krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN: kvno = 1

Глобальный каталог AD

В лесу Active Directory может быть много поддоменов, и, чтобы ускорить поиск нужной информации, разработчики Microsoft придумали такую роль, как глобальный каталог (англ. Global Catalog).

Контроллер домена, которому назначена роль глобального каталога, с помощью штатной процедуры репликации извлекает из всех поддоменов краткую информацию об объектах (Partial Attribute Set, PAT) и предоставляет ее приложениям по запросу. При желании вы можете расширить набор реплицируемых атрибутов. Для этого в редакторе схемы для нужного атрибута достаточно установить флажок «Копировать этот атрибут в глобальный каталог» (Replicate this attribute to the Global Catalog).

Глобальный каталог предоставляет данные по протоколу LDAP на портах 3268/tcp (LDAP) и 3269/tcp (LDAPS). В Active Directory первый контроллер автоматически получает роль глобального каталога, но она может быть назначена не всем контроллерам в домене. Автоматическое обнаружение серверов, которым назначена роль глобального каталога, выполняется по SRV-записям вида _ gc._tcp.<DNSDomainName>.

Глобальный каталог ALD Pro

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

Картинка с сайта: www.aldpro.ru

Модуль глобального каталога устанавливается на всех контроллерах в домене, и за его работу отвечают службы dirsrv@GLOBAL-CATALOG и ipa-gcsyncd, см. рис. 325. Первая служба обеспечивает работу дополнительного LDAP-бэкенда на порту 3268/TCP, а вторая синхронизирует информацию глобального каталога с основным каталогом, выполняя необходимую трансформацию данных.

Синхронизация работает на основе механизма репликации syncrepl. Служба ipa-gcsyncd извлекает из основного LDAP-каталога информацию о пользователях и группах, модифицирует ее с учетом схемы AD DS, которую ожидают увидеть клиенты Windows, и сохраняет в базу глобального каталога. Модификация данных выполняется по следующим шаблонам.

Шаблон модификации учетных записей пользователей

{% macro first_val(attr) -%}
   {{ entry[attr][0] }}
{%- endmacro %}
dn: cn={{ first_val('uid') }},cn=users,{{ suffix }}
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: ad-top
objectClass: ad-organizationalPerson
objectClass: user
objectClass: securityPrincipal
objectClass: posixAccount
objectClass: inetUser
objectClass: gcobject
cn: {{ first_val('uid') }}
sn: {{ first_val('sn') }}
{%- if entry['givenname'] %}
givenName: {{ first_val('givenname') }}
{%- endif %}
instanceType: 4
{%- if entry['displayname'] %}
displayName: {{ entry.single_value['displayname'] }}
{%- endif %}
name: {{ first_val('cn') }}
objectGUID:: {{ guid }}
userAccountControl: 66048
primaryGroupID: 513
objectSid:: {{ sid }}
sAMAccountName: {{ pkey }}
sAMAccountType: 805306368
{%- if entry['krbcanonicalname'] %}
userPrincipalName: {{ entry.single_value['krbcanonicalname'] }}
{%- else %}
userPrincipalName: {{ first_val('krbprincipalname') }}
{%- endif %}
objectCategory: CN=Person,CN=Schema,CN=Configuration,{{ suffix }}
{%- if entry['mail'] %}
mail: {{ first_val('mail') }}
{%- endif %}
uidnumber: {{ first_val('uidnumber') }}
gidnumber: {{ first_val('gidnumber') }}
{%- for uid in entry['uid'] %}
uid: {{ uid }}
{%- endfor %}
homeDirectory: {{ first_val('homedirectory') }}
{%- for group in entry['memberof'] %}
memberof: {{ group }}
{%- endfor %}
nTSecurityDescriptor:
D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(OA;;WP;736e4812-af31-11d2-b7df-00805f48caeb;bf967ab8-0de6-11d0-a285-00aa003049e2;CO)(A;;SD;;;CO)
gcuuid: {{ entryuuid }}

Шаблон модификации групп

{% macro first_val(attr) -%}
   {{ entry[attr][0] }}
{%- endmacro %}
dn: cn={{ pkey }},cn=users,{{ suffix }}
objectClass: top
objectClass: ad-top
objectClass: group
objectClass: securityprincipal
objectClass: nsmemberof
objectClass: gcobject
objectClass: posixGroup
cn: {{ pkey }}
instanceType: 4
name: {{ pkey }}
objectGUID:: {{ guid }}
objectSid:: {{ sid }}
sAMAccountName:  {{ pkey }}
sAMAccountType: 268435456
objectCategory: CN=Group,CN=Schema,CN=Configuration,{{ suffix }}
ntsecuritydescriptor: D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPLCLORC;;;AU)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;AO)(A;;RPLCLORC;;;PS)(OA;;CR;ab721a55-1e2f-11d0-9819-0aa0040529b;;AU)
{%- for member in entry['member'] %}
member: {{ member }}
{%- endfor %}
{%- for group in entry['memberof'] %}
memberof: {{ group }}
{%- endfor %}
gidnumber: {{ gidnumber }}
groupType: {{ groupType }}
gcuuid: {{ entryuuid }}

Установка глобального каталога ALD Pro

Вы можете поставить модуль глобального каталога при установке первого контроллера домена. Для этого вам необходимо дополнительно установить пакет aldpro-gc и выполнять продвижение с ключом --setup_gc:

sudo DEBIAN_FRONTEND=noninteractive apt-get install -q -y aldpro-mp aldpro-gc
sudo aldpro-server-install -d ald.company.lan -n dc-1 -p 'AstraLinux_174' --ip 10.0.1.11 --no-reboot --setup_gc

В дальнейшем вы можете доустановить модуль, используя подсистему обновления. Достаточно вызвать следующую команду на dc-1, после чего глобальный каталог установится на все контроллеры в домене:

sudo aldpro-update-all --repo 'deb https://dl.astralinux.ru/aldpro/frozen/01/2.2.0 1.7_x86-64 main base'--username admin --password 'AstraLinux_174' --all --setup_gc

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

После установки вы можете убедиться, что ГК был установлен, выполнив команду:

До установки ГК:

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

После установки ГК:

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

Далее вы обнаружите systemd службу ipa-gcsyncd.service, которая отвечает за синхронизацию глобального каталога.

admin@dc-1:~$ systemctl status ipa-gcsyncd.service
● ipa-gcsyncd.service - Служба синхронизации Глобального каталога
   Loaded: loaded (/lib/systemd/system/ipa-gcsyncd.service; disabled; vendor preset: enabled)
   Active: active (running) since Fri 2024-03-29 17:09:05 MSK; 35min ago
 Main PID: 2253 (gcsyncd.py)
    Tasks: 1 (limit: 4915)
   Memory: 87.5M
      CPU: 2.978s
   CGroup: /system.slice/ipa-gcsyncd.service
           └─2253 /usr/bin/python3 /opt/gc/exec/gcsyncd.py

мар 29 17:09:05 dc-1.aldpro.mycompany.lan systemd[1]: Started Служба синхронизации Глобального
каталога.
мар 29 17:09:12 dc-1.aldpro.mycompany.lan gcsyncd.py[2253]: ipa: INFO: LDAP bind...
мар 29 17:09:12 dc-1.aldpro.mycompany.lan gcsyncd.py[2253]: ipa: INFO: Commencing sync process
мар 29 17:09:12 dc-1.aldpro.mycompany.lan gcsyncd.py[2253]: ipa: INFO: Initial LDAP dump is done,
now synchronizing

Вы также обнаружите после установки ГК, что в DNS создались дополнительные SRV-записи для автоматического обнаружения сервиса со стороны Windows-клиентов.

_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs
_ldap._tcp.gc._msdcs
_gc._tcp.Default-First-Site-Name._sites
_gc._tcp

Найти их можно с помощью утилиты ipa, отфильтровав по слову «gc» с помощью утилиты grep:

admin@dc-1:~$ ipa dnsrecord-find ald.company.lan | grep gc
  Имя записи: \_ldap._tcp.Default-First-Site-Name._sites.gc._msdcs
  Имя записи: \_ldap._tcp.gc._msdcs
  Имя записи: \_gc._tcp.Default-First-Site-Name._sites
  Имя записи: \_gc._tcp

Потом можно посмотреть каждую по отдельности:

admin@dc-1:~$ sudo ipa dnsrecord-find ald.company.lan --name=_gc._tcp
...
  Имя записи: \_gc._tcp
  SRV record: 0 100 3268 dc-1.ald.company.lan.
---------------------------------
Количество возвращённых записей 1
---------------------------------