Практическая работа: Модуль 9. Миграция и гибридное развертывание. Интеграция с Microsoft Active Directory
См. также Требования, правила и цели выполнения практической работы
Практические задания
Задание 1. Настройка стенда для доверительных отношений
Параметры стенда
В качестве практического занятия мы с вами установим доверительные отношения на уровне леса (Forest Trust) между доменами MS AD и ALD Pro.
Инфраструктура ALD Pro у вас уже развернута. Развернем инфраструктуру Microsoft:
Разверните контроллер MS AD на Windows Server 2019:
Имя контроллера: windc-1.win.company.lan
Имя домена (Realm): win.company.lan
Статичный IP адрес: 10.0.1.101
Маска сети: 255.255.255.0
Шлюз: 10.0.1.1
Создайте winpc-1 на Windows Server 2019 и подключите его в домен win.company.lan:
Имя хоста: winpc-1.win.company.lan
Имя домена (Realm): win.company.lan
Статичный IP адрес: 10.0.1.102
Маска сети: 255.255.255.0
Шлюз: 10.0.1.1
рис. 327 Стенд доверительных отношений
Проверка доступности портов
Следующим пунктом идет проверка портов. Этот пункт в рамках данной практики мы тоже опускаем, так как оба домена мы разворачиваем в одном сегменте сети. Фаерволы операционных систем по умолчанию не блокируют стандартные порты.
Взаимное перенаправление DNS-зон
Для работы доверительных отношений с компьютеров в домене ald.company.lan должны разрешаться имена компьютеров домена win.company.lan и наоборот. Для этого нам нужно сделать взаимное перенаправление DNS-зон.
Для создания перенаправителя (ConditionalForwarder) для зоны ald.company.lan в домене win.company.lan запустите PowerShell на контроллере домена win.company.lan (Active Directory) и выполните следующую команду:
Add-DnsServerConditionalForwarderZone -Name "ald.company.lan" -ReplicationScope "Forest" -MasterServers 10.0.1.11
где
ald.company.lan - DNS-имя перенаправляемой зоны;
10.0.1.11 - это IP адрес контроллера ALD Pro.
Проверка доступности домена ald.company.lan:
ping dc-1.ald.company.lan
Resolve-DnsName _ldap._tcp.ald.company.lan -Type SRV
Resolve-DnsName _kerberos._tcp.ald.company.lan -Type SRV
Resolve-DnsName _ldap._tcp.dc._msdcs.ald.company.lan -Type SRV
Resolve-DnsName _kerberos._tcp.dc._msdcs.ald.company.lan -Type SRV
Для создания перенаправителя (ConditionalForwarder) для зоны win.company.lan в домене ald.company.lan запустите окно терминала на контроллере домена ald.company.lan (ALD Pro) и выполните следующие команды:
admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa dnsforwardzone-add win.company.lan --forwarder=10.0.1.101 --forward-policy=only
где:
win.company.lan - DNS-имя перенаправляемой зоны;
10.0.1.101 - это IP-адрес контроллера MS AD.
Проверка доступности домена win.company.lan:
admin@dc-1:~$ ping windc-1.win.company.lan
admin@dc-1:~$ dig SRV _ldap._tcp.win.company.lan
admin@dc-1:~$ dig SRV _kerberos._tcp.win.company.lan
Настройка DNS-доверительных сетей (необязательно)
Следующим пунктом идет проверка портов. Этот пункт в рамках данной практики мы тоже опускаем, так как оба домена мы разворачиваем в одном сегменте сети.
Проверка настройки времени
Основной задачей проверки является убедиться, что время на контроллерах домена ALD Pro и MS AD синхронизированы.
Проверьте сначала на стороне ALD Pro. Начните с проверки статуса службы:
root@dc-1:~# systemctl status chrony.service
Проверьте источник времени:
root@dc-1:~# chronyc sources -v
Проверьте расхождение времени:
root@dc-1:~# chronyc tracking
Конфигурация сервиса времени находится в /etc/chrony/chrony.conf.
Далее проверьте настройки времени на стороне MS AD. Так как контроллер MS AD будет поднят с нуля и настройка синхронизации времени будет выставлена по умолчанию, то ниже приведем пример настройки с внешним NTP-источником.
w32tm /config /reliable:yes /syncfromflags:manual /manualpeerlist:"ntp.msk-ix.ru" /update
net stop w32time
net start w32time
w32tm /resync
w32tm /monitor /computers:"ntp.msk-ix.ru"
w32tm /stripchart /computer:ntp.msk-ix.ru
Задание 2. Установка глобального каталога
Для установки глобального каталога в домене ALD Pro необходимо выполнить следующую команду только на первом контроллере домена dc-1, после чего глобальный каталог установится на все контроллеры домена:
admin@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 указывает репозиторий, откуда будет установлен пакет глобального каталога. Ключ является обязательным, т.е. его нужно указать даже в случае предварительной установки пакета глобального каталога на контроллер домена.
Иногда команда aldpro-update-all завершается с ошибкой. Например, глобальный каталог не смог установиться на втором контроллере домена. Повторное выполнение команды решает проблему.
После установки вы можете убедиться, что ГК был установлен, выполнив команду ipactl status:
До установки ГК:
root@dc-1:~# 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
После установки ГК:
root@dc-1:~# 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, которая отвечает за синхронизацию глобального каталога.
root@dc-1:~# systemctl status ipa-gcsyncd
● 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-записи для обнаружения этого сервиса клиентами. Найти их можно с помощью утилиты ipa, отфильтровав по слову «gc»:
root@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
Потом можно посмотреть каждую по отдельности:
root@dc-1:~# ipa dnsrecord-find ald.company.lan --name=_gc._tcp
Имя записи: _gc._tcp
SRV record: 0 100 3268 dc-1.ald.company.lan.
---------------------------------
Количество возвращённых записей 1
---------------------------------
Задание 3. Создание двустороннего траста (Forest Trust)
Во всех инструкциях создание траста начинают с выполнения команды ipa-adtrust-install, которая подготавливает домен FreeIPA к работе с доверительными отношениями, в частности добавляет атрибут для хранения windows security identifier (SID). В случае ALD Pro это не требуется. Попробуйте команду ipa trustconfig-show, чтобы убедиться в наличии атрибута SID (идентификатор безопасности):
root@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
Перед созданием доверительных отношений нужно запросить Kerberos-билет для учетной записи admin:
root@dc-1:~# kinit admin
Траст можно добавить на стороне ALD Pro из командной строки. При появлении проблем рекомендуется использовать ключи -d и -v для получения дополнительной информации об ошибках:
root@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
Состояние отношения доверия: Установлено и проверено
Если в этот момент отслеживать сетевой трафик, то можно будет увидеть, что аутентификация в Windows-домене выполняется по Kerberos, а установление траста выполняется по транспортному протоколу SMB2 путем вызова удаленных команд RPC (все верно, SMB-протокол — это не только файлы и принтеры). В тоже время билет на доступ к службе krbtgt в Windows-домене не сохраняется в кэше sssd службы, поэтому команда klist после установления траста не покажет вам дополнительных билетов.
После создания доверия можно посмотреть информацию о созданном трасте командами ipa trust-find и ipa trust-show:
root@dc-1:~# ipa trust-find
---------------------------
найдено 1 отношение доверия
---------------------------
Имя области (realm): win.mycompany.lan
Имя домена NetBIOS: WIN
Идентификатор безопасности домена: S-1-5-21-3328403581-165198287-4002972307
Тип отношения доверия: Домен Active Directory
---------------------------------
Количество возвращённых записей 1
---------------------------------
root@dc-1:~# ipa trust-show win.company.lan
Имя области (realm): win.company.lan
Имя домена NetBIOS: WIN
Идентификатор безопасности домена: S-1-5-21-3328403581-165198287-4002972307
Направление отношения доверия: Двустороннее отношение доверия
Тип отношения доверия: Домен Active Directory
Можно посмотреть и диапазон POSIX-идентификаторов доверенного домена:
root@dc-1:~# ipa idrange-find
-------------------
найдено 2 диапазона
-------------------
Имя диапазона: ALD.COMPANY.LAN_id_range
Первый идентификатор POSIX диапазона: 536400000
Количество идентификаторов в диапазоне: 200000
Первый RID соответствующего диапазона RID: 1000
Первый RID вторичного диапазона RID: 100000000
Тип диапазона: local domain range
Имя диапазона: WIN.COMPANY.LAN_id_range
Первый идентификатор POSIX диапазона: 1801200000
Количество идентификаторов в диапазоне: 200000
Первый RID соответствующего диапазона RID: 0
SID доверенного домена: S-1-5-21-3328403581-165198287-4002972307
Тип диапазона: Active Directory domain range
---------------------------------
Количество возвращённых записей 2
---------------------------------
Задание 4. Проверка работоспособности доверительных отношений
Два основных типа запросов, которые может выполнять клиент - это поиск идентификационных данных (id) и аутентификация (login). Для пользователей ALD Pro (IPA) поиск идентификационных данных представляет собой обычный поиск по протоколу LDAP на ALD Pro (IPA)-сервере, а аутентификация выполняется с помощью внутреннего инструмента, подобного kinit, также подключающегося к ALD Pro (IPA)-серверу.
Доверенные пользователи AD (Trusted AD users) работают по-другому: поиск идентификационных данных (id) с клиентских компьютеров подключается к ALD Pro (IPA)-серверу с помощью расширенной операции LDAP. Плагин extdom сервера ALD Pro (IPA) запрашивает у экземпляра SSSD, запущенного на сервере, информацию о пользователе AD, экземпляр SSSD выполняет поиск на сервере Active Directory с использованием протокола LDAP и передает данные обратно клиенту ALD Pro (IPA). Для запросов аутентификации на основе пароля (login) клиенты ALD Pro (IPA) подключаются непосредственно к серверам AD с помощью Kerberos.
Имейте в виду, что, поскольку во время проверки подлинности должен быть задан правильный набор групп, запрос на проверку подлинности также должен выполнить поиск идентификатора, обычно операцию initgroups, перед проверкой подлинности.
Первым делом выполним аутентификацию и проверим, все ли контроллеры домена ALD Pro перечислены в контроллерах отношений доверия.
Выполнить аутентификацию:
root@dc-1:~# kinit admin
Показать, какие контроллеры домена могут обрабатывать Trust c Active Directory:
root@dc-1:~# ipa trustconfig-show
Домен: ald.company.lan
Идентификатор безопасности: S-1-5-21-3134460814-120682416-4104473534
Имя 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
Показать созданный траст:
root@dc-1:~# ipa trust-find win.company.lan
Показать направление отношения доверия:
root@dc-1:~# ipa trust-show win.company.lan
Если контроллер ALD Pro не указан в списке, то требуется проверить наличие ошибок в логах на проблемном контроллере:
root@dc-1:~# grep -insRH --color=auto "ipa-ad" /var/log
/var/log/ipaserver-install.log:162:2023-05-11T14:56:28Z DEBUG The ipa-adtrust-install
command failed, exception: ScriptError: Unrecognized error during check of admin rights: 'member_user'
В данном случае нужно вручную повторно запустить команду ipa-adtrust-install на проблемном контроллере.
Далее проверим топологию репликации суффикса.
root@dc-1:~# ipa topologysuffix-verify --help
Usage: ipa [global-options] topologysuffix-verify NAME [options]
Options:
-h, --help show this help message and exit
Проверка топологии репликации для суффикса, которые выполняются:
проверка того, не отключена ли топология (иначе говоря, имеются ли пути репликации между всеми серверами).
проверка того, не превышено ли рекомендованное количество соглашений о репликации между серверами.
root@dc-1:~# ipa topologysuffix-verify domain
=================================================================
Топология репликации суффикса "domain" соответствует требованиям.
=================================================================
Проверим работоспособность траста с помощью команды id. Требуется выполнить на каждом ALD Pro контроллере домена. Очистка всего доступного кэша и перезапуск службы sssd:
root@dc-1:~# rm -f /var/lib/sss/db/* /var/lib/sss/mc/* && systemctl restart sssd
Получение информации о пользователе в домене win.company.lan:
root@dc-1:~# id 'win\administrator'
или так:
root@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)
Проверка работоспособности траста с помощью Kerberos
Выполним запрос Kerberos-билета из домена MS AD, включив логирование протокола Kerberos:
https://web.mit.edu/kerberos/krb5-1.12/doc/user/user_commands/kinit.html
root@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 10.0.1.101:88
[30804] 1698829046.855696: Sending TCP request to stream 10.0.1.101:88
[30804] 1698829046.855697: Received answer (198 bytes) from stream 10.0.1.101:88
[30804] 1698829046.855698: Terminating TCP connection to stream 10.0.1.101: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:
Далее выполним команду KLIST, чтобы посмотреть полученные билеты Kerberos в кэше:
root@dc-1:~# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_6c40ahD
Default principal: Administrator@WIN.COMPANY.LAN
Valid starting Expires Service principal
24.10.2023 13:48:50 24.10.2023 23:48:50 krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN
renew until 25.10.2023 13:48:44
Теперь попробуем получить служебный билет Kerberos для доступа к файловому серверу kvno:
root@dc-1:~# kvno -S CIFS windc-1.win.company.lan
CIFS/windc-1.win.company.lan@WIN.COMPANY.LAN: kvno = 3
root@dc-1:~# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_6c40ahD
Default principal: Administrator@WIN.COMPANY.LAN
Valid starting Expires Service principal
24.10.2023 14:17:17 24.10.2023 23:48:50 CIFS/windc-1.win.company.lan@WIN.COMPANY.LAN
24.10.2023 13:48:50 24.10.2023 23:48:50 krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN
renew until 25.10.2023 13:48:44
Дополнительные проверки:
Выполняем аутентификацию пользователя из домена AD DS, получаем TGT-билет от контроллера AD DS
root@dc-1:~# kinit administrator@win.company.lan
Получаем для пользователя Cross-realm TGT-билет у контроллера AD DS для сквозной аутентификации на контроллерах ALD Pro:
root@dc-1:~# kvno krbtgt/ALD.COMPANY.LAN@WIN.COMPANY.LAN
Используя Cross-realm TGT-билет, получаем у контроллера ALD Pro сервисный билет для аутентификации на хосте из домена ALD Pro с fqdn именем dc-1.ald.company.lan:
root@dc-1:~# kvno host/dc-1.ald.company.lan@ALD.COMPANY.LAN
Получаем для пользователя Cross-realm TGT-билет у контроллера ALD Pro для сквозной аутентификации на контроллерах Active Directory:
root@dc-1:~# kvno krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN
Используя Cross-realm TGT-билет, получаем у контроллера Active Directory сервисный билет для аутентификации на хосте из домена Active Directory:
root@dc-1:~# kvno host/windc-1.win.company.lan@WIN.COMPANY.LAN
Конечный результат
root@dc-1:~# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_B4jH9CO
Default principal: Administrator@WIN.COMPANY.LAN
Valid starting Expires Service principal
24.10.2023 14:41:04 25.10.2023 00:22:09 host/windc-1.win.company.lan@WIN.COMPANY.LAN
24.10.2023 14:39:55 25.10.2023 00:22:09 krbtgt/WIN.COMPANY.LAN@ALD.COMPANY.LAN
24.10.2023 14:28:13 25.10.2023 00:22:09 host/dc-1.ald.company.lan@ALD.COMPANY.LAN
24.10.2023 14:25:15 25.10.2023 00:22:09 krbtgt/ALD.COMPANY.LAN@WIN.COMPANY.LAN
24.10.2023 14:22:09 25.10.2023 00:22:09 krbtgt/WIN.COMPANY.LAN@WIN.COMPANY.LAN
renew until 25.10.2023 14:22:04
Задание 5. Дополнительное задание
Попробуйте выполнить вход на pc-1.ald.company.lan, под учетной записью Administrator@WIN.COMPANY.LAN.
Примечание
Если вы изменили HBAC-правило «allow_all», которое изначально разрешает всем подключаться к хостам ALD Pro (например, запретили вход всем, кроме группы admins), то необходимо добавить пользователя Administrator@WIN.COMPANY.LAN в external-группу, которую затем включить разрешающее правило. Если этого не сделать, то попытка зайти на хост ALD Pro вы будете получать ошибку «Доступ запрещен».
Попробуйте выполнить вход на winpc-1.win.company.lan под учетной записью admin@ALD.COMPANY.LAN.
Создайте общую папку на winpc-1.win.company.lan, дайте полный доступ пользователю admin из домена ALD.COMPANY.LAN. Зайдите на pc-1.ald.company.lan под учетной записью admin@ALD.COMPANY.LAN, подключите общую папку, созданную выше. Убедитесь в наличии доступа, создав файл и внеся в него изменения.
На windc-1.win.company.lan запустите оснастку Active Directory Domains and Trusts и убедитесь, что доверительное отношение с ald.company.lan создалось.