Модуль 9. Миграция и гибридное развертывание. Интеграция с Microsoft Active Directory
Введение
Из этого модуля вы узнаете о том, как подступиться к проектам импортозамещения и чем вам помогут доверительные отношения Kerberos. Мы рассмотрим, зачем в ALD Pro нужен модуль глобального каталога и как он работает. В конечном итоге, чем больше инструментов гибридного развертывания вы задействуете, тем проще вам будет выполнить миграцию инфраструктуры.
Стратегии миграции
Возможности гибридного развертывания
В настоящее время многие компании задумываются над миграцией в инфраструктуру 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.
рис. 313 Основные способы подключения к информационным системам
В качестве рабочих мест следует рассмотреть следующие варианты:
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.
рис. 314 Архитектура сервисного домена
Такой сценарий развертывания упрощает администрирование серверной группировки, предоставляя следующие возможности:
Централизованное управление учетными записями администраторов системы, включая их SSH-ключи.
Автоматизация настройки ОС Astra Linux на серверах через механизм групповых политик ALD Pro (через Salt-скрипты).
Контроль доступа к серверам через правила HBAC и SUDO.
Сценарий «Ресурсный домен»
В домен ALD Pro переносятся не только серверы, но и «керберизированные» сетевые приложения (ресурсы), такие как файловые серверы, корпоративные веб-приложения и т.д. Пользователи и рабочие места сотрудников остаются в домене AD, доступ к ресурсам осуществляется через механизм доверительных отношений.
рис. 315 Архитектура ресурсного домена
Такой сценарий развертывания потребует участия разработчиков и квалифицированных администраторов, но станет значительным шагом в направлении импортозамещения и предоставит следующие возможности:
Прозрачная аутентификация пользователей при обращении к ресурсам в Linux-домене через механизм доверительных отношений.
Возможность постепенного переноса корпоративных приложений в Linux-инфраструктуру по мере их готовности.
Возможность переноса учетных записей пользователей в Linux-домен, как только все нужные приложения окажутся в новой инфраструктуре.
Сценарий «Управление рабочими местами»
Сценарий предполагает, что в домен ALD Pro вводятся только рабочие места, и это позволяет обеспечить централизованное управление инфраструктурой Linux-компьютеров, а пользователи и ресурсы остаются в домене MS AD. Вход пользователей в компьютер осуществляется через механизм доверительных отношений.
рис. 316 Архитектура для управления рабочими местами
Этот сценарий позволит быстро заместить клиентскую инфраструктуру и отлично подходит организациям, у которых большинство корпоративных приложений не имеют толстых клиентов и работают как веб-приложения из браузера. Такой сценарий развертывания предоставит следующие возможности по управлению рабочими местами:
Автоматизация настройки рабочих станций через механизм групповых политик.
Контроль доступа к рабочим станциям через правила 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 больше не требуется.
рис. 317 Автономное развертывание
Доверительные отношения
Механизм работы доверительных отношений
Доверительные отношения дают возможность пользователям одного домена выполнять прозрачную аутентификацию по протоколу Kerberos V5 при обращении к ресурсам другого домена. Например, вы можете разрешить пользователям из домена AD DS входить в операционную систему компьютеров под управлением Astra Linux из домена ALD Pro или, наоборот, дать возможность пользователям ALD Pro подключаться с компьютеров Astra Linux к общим файловым ресурсам, находящимся в домене AD DS, см. рис. 318.
рис. 318 Схема доверительных отношений ALD Pro — AD DS
Система 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.
рис. 319 Направление доверия и доступа
Если между двумя доменами установлено только одно доверительное отношение, то такое отношение называется односторонним. Если же между доменами установлено два доверительных отношения и домены доверяют друг другу, то такие отношения называются двусторонними.
рис. 320 Поток данных при выполнении Kerberos-аутентификации в доверительных отношениях
Рассмотрим, как работает аутентификация с использованием доверительных отношений, когда пользователю доверенного домена ALD.COMPANY.LAN нужно пройти аутентификацию в службе из доверяющего домена WIN.COMPANY.LAN, см. рис. 320:
Пользователь ALD запрашивает TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN у контроллера из своего родного домена ALD для выполнения последующей аутентификации на контроллерах ALD.
Контроллер ALD располагает учетными данными пользователя из своего домена, поэтому может подтвердить аутентичность запроса и выдать ему TGT-билет. Если пользователь сможет расшифровать ответ, он подтвердит тем самым свою аутентичность.
Пользователь ALD, используя TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN, обращается к контроллеру ALD за билетом cifs/fs-1.win.company.lan@ALD.COMPANY.LAN для последующей аутентификации в службе cifs на файловом сервере fs-1 из доверяющего домена WIN.
Контроллер ALD располагает мастер-ключом домена ALD, поэтому может успешно проверить аутентичность пользователя, но у него нет учетных данных службы из доверяющего домена WIN, поэтому контроллер возвращает ошибку KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.
Пользователь ALD, используя TGT-билет krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN, обращается к своему контроллеру ALD за кросс-доменным TGT-билетом krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN для последующей аутентификации на контроллерах домена WIN.
Контроллер 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 устанавливаются транзитивными.
Пользователь ALD, используя TGT-билет krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN, обращается к контроллеру WIN за полноценным TGT-билетом krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN.
Контроллер WIN располагает паролем доверительных отношений, поэтому успешно проверяет запрос, пересчитывает PAC-сертификат с учетом правил фильтрации и выдает пользователю полноценный TGT-билет из своего домена.
Пользователь ALD, используя TGT-билет krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN, обращается к контроллеру WIN за билетом cifs/fs-1.win.company.lan@WIN.COMPANY.LAN для аутентификации в службе cifs на файловом сервере fs-1 из этого домена.
Контроллер WIN располагает мастер-ключом домена WIN, поэтому может успешно проверить аутентичность пользователя. Контроллер WIN располагает также учетными данными сервиса из своего домена, поэтому успешно выдает пользователю TGS-билет cifs/fs-1.win.company.lan@WIN.COMPANY.LAN.
Пользователь ALD, используя TGS-билет cifs/fs-1.win.company.lan@WIN.COMPANY.LAN, обращается к службе cifs на файловом сервере fs-1 из домена WIN.
Файловый сервер располагает паролем службы cifs, поэтому может проверить и подтвердить аутентичность пользователя.
Примечание
В настройках службы SSSD можно задать опцию AD Site, с помощью которой можно настроить географическую балансировку между лесами доменов ALD Pro и AD DS. Опцию следует задать как на клиенте, так и на сервере ALD Pro. В этом случае при выполнении автоматического обнаружения сервисов клиент будет в первую очередь обращаться к SRV-записям указанного сайта.
Протокол 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:
рис. 321 Иллюстрация работы модуля глобального каталога в ALD Pro
Пользователям ванильных версий 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-операции.
Примечание
В домене ALD Pro всем контроллерам назначается роль контроллеров доверия, поэтому на них устанавливается пакет программ Samba, и вы с любого из них можете установить доверительные отношения с доменом AD DS.
Если при повышении роли сервера пользователь, выполняющий эту операцию, не входил в состав участников группы «ald trust admin», то продвижение завершится с ошибкой и контроллер будет обладать только ролью агента доверия. Для того чтобы завершить установку и назначить серверу роль контроллера доверия, нужно включить пользователя в указанную группу и запустить повторно скрипт ipa-aldtrust-install
Осталось только разобраться с идентификаторами. Учитывая, что в среде Linux используются не SID, а POSIX-идентификаторы, на стороне ALD Pro служба SSSD выполняет сопоставление идентификаторов одним из двух способов:
Если в AD DS установлен компонент Identity Management for UNIX (что маловероятно), то у объектов будут заданы атрибуты uidnumber/gidnumber, и вы сможете их использовать. Для этого в момент установления доверительных отношений следует указать параметр ipa-ad-trust-posix.
Если компонента 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:
рис. 322 Создание перенаправителя в DNS Manager Windows
Для создания перенаправителя в домене 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:
рис. 323 Создание перенаправителя в портале управления ALD Pro
Настройка DNS-доверительных сетей (необязательно)
Если вы не хотите разрешать полный доступ к DNS на стороне ALD Pro, вам нужно будет настроить доверенные сети на каждом контроллере ALD Pro (FreeIPA). В файле /etc/bind/ipa-options-ext.conf нужно внести trusted_network в список разрешенных сетей:
allow-recursion { trusted_network; };
allow-query-cache { trusted_network; }
listen-on-v6 { any; };
dnssec-validation no;
В файле /etc/bind/ipa-ext.conf перечислите доверенные сети:
acl "trusted_network" {
localnets;
localhost;
192.168.88.0/24;
172.19.3.0/24;
172.19.4.0/24;
};
Проверка настройки времени
Для работы протокола Kerberos требуется, чтобы время на контроллерах домена ALD Pro и MS AD отличалось не более, чем на 5 минут. Виртуальные машины по умолчанию берут время с хостовой машины, поэтому при запуске стенда на одной физической машине проблем обычно не возникает, а в реальной инфраструктуре синхронизация времени является прямой задачей администратора.
Примечание
Протокол Kerberos использует время в формате UTC, т.е. без временных зон, поэтому, если в Windows временные зоны работают некорректно из-за отсутствия актуального обновления системы, то вы должны использовать неправильною зону, но ни в коем случае не сбивать фактическое значение времени по UTC на эмуляторе PDC.
На стороне ALD Pro используйте команды:
admin@dc-1:~$ systemctl status chrony.service
admin@dc-1:~$ chronyc sources -v
admin@dc-1:~$ chronyc tracking
На стороне MS AD используйте в терминале PowerShell команды:
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:
рис. 324 Создание доверительных отношений из графического интерфейса ALD Pro
Если в этот момент отслеживать сетевой траффик, то можно будет увидеть, что аутентификация в домене 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"
Создание внешнего траста между доменами (External Trust)
Доверительные отношения можно создать не только «лес к лесу», но и «домен к домену». Такие отношения называются внешними (External) и являются нетранзитивными. Создать такие отношения можно из командной строки, используя дополнительный ключ --external.
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
Состояние отношения доверия: Установлено и проверено
Удаление траста
Удалить траст можно из командной строки и через веб-интерфейс ALD Pro:
admin@dc-1:~$ ipa trust-del win.company.lan
Обратите внимание, что на стороне Windows доверительные отношения нужно будет удалить вручную через оснастку Active Directory Domains and Trusts. Также не будут автоматически удалены диапазоны идентификаторов, что позволит вам повторно создать доверительные отношения с этим лесом/доменом в будущем, сохранив настройки сопоставления идентификаторов.
Проверка работоспособности доверительных отношений
Рассмотрим несколько диагностических действий, которые вы можете использовать для отладки работы доверительных отношений.
Посмотреть настройки доверия можно командой 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 эта функция была реализована в виде дополнительного модуля.
рис. 325 Архитектура глобального каталога ALD Pro
Модуль глобального каталога устанавливается на всех контроллерах в домене, и за его работу отвечают службы 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 указывает репозиторий, откуда будет взят пакет глобального каталога. Ключ является обязательным, т.е. его нужно указать даже в случае предварительной установки пакета глобального каталога на контроллер домена.
После установки вы можете убедиться, что ГК был установлен, выполнив команду:
sudo ipactl status
До установки ГК:
admin@dc-1:~$ sudo ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful
После установки ГК:
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
---------------------------------
Присоединение Windows-машины к домену ALD Pro
Конечная цель проектов импортозамещения в ИТ — полный отказ от операционной системы Windows. Но, как говорится, гладко было на бумаге, да забыли про овраги. Может так оказаться, что быстро заменить какие-то клиентские корпоративные приложения, написанные под эту операционную систему, не получится. В этом случае вам может пригодиться возможность присоединения Windows-компьютеров к домену ALD Pro.
Присоединение Windows-клиентов к домену FreeIPA не находится в фокусе внимания команды разработчиков этой службы каталога, так как проект ставит своей целью не заменить Active Directory для Windows-компьютеров, а создать аналогичное решение для компьютеров под управлением операционной системы Linux. Однако компания Microsoft еще с версии Windows 2000 поддерживает возможность интеграции своих ОС с областями Kerberos, которые совместимы с RFC 2136, а центр распределения ключей FreeIPA работает как раз на базе эталонной реализации MIT KDC. То есть, ничто не препятствует тому, чтобы вводить Windows-компьютеры напрямую в домен FreeIPA.
Более того, разработчики FreeIPA реализовали возможность интеграции своего домена с Active Directory на уровне доверительных отношений за счет компонента Samba AD, поэтому контроллеры домена, помимо Kerberos, поддерживают такие протоколы, как NetBIOS, SMB, Netlogon (MS-NRPC) и NTLM. В базе данных DNS есть SRV-записи по стандартам Microsoft, а Kerberos-билеты содержат не только аутентификационные данные, но и сертификат PAC, включающий SID’ы пользователя и всех его групп.
Все эти особенности открывают дополнительные возможности по работе Windows-компьютеров в составе домена FreeIPA. Далее мы расскажем, как правильно задействовать эти отличительные черты, чтобы получить доступ к следующим функциям:
вход в ОС Windows с помощью учетных записей из домена ALD Pro;
прозрачная аутентификация при обращении пользователя к керберизированным ресурсам, например, файловым серверам;
получение уведомлений об истечении срока действия пароля и возможность сменить пароль штатными функциями ОС Windows;
предоставление доменным пользователям прав доступа к локальным ресурсам Windows-компьютера с учетом их участия в доменных группах;
синхронизация времени рабочей станции с временем на контроллерах домена;
динамическое изменение DNS-записей в домене при изменении IP-адреса на сетевом интерфейсе Windows-компьютера.
Полная инструкция занимает два десятка страниц и подробно рассказывает о том, как настроить Kerberos-аутентификацию, синхронизацию времени, динамическое обновление DNS-записей, домен для входа по умолчанию и многие другие аспекты. Вы можете ознакомиться с этой информацией в нашей статье на Хабре, поэтому укажем только, что команда ALD Pro разработала для вас специальную графическую утилиту aldpro-join.exe, которая позволяет выполнить все настройки в пару кликов, см. рис. 326:
рис. 326 Присоединение компьютера к домену с помощью утилиты aldpro-join.exe
Приложение написано на языке Python и доступно в публичном репозитории продуктовой команды на GitFlic как в виде исходных кодов, так и в виде скомпилированного с помощью Pyinstaller исполняемого exe-файла.
Практика и тестирование
Заключение
В этом модуле мы рассмотрели один из наиболее действенных механизмов гибридного развертывания, без которого не обойдется ни один проект импортозамещения! Далее займемся резервным копированием.