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

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

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

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

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

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

Доверительные отношения с AD DS устанавливаются на стороне FreeIPA с помощью команды ipa trust-add:

# ipa -d -v trust-add --type=ad win.company.local --admin administrator --password --two-way=true

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

Для того, чтобы пользователь из AD DS мог пройти не только аутентификацию, но и авторизацию, т. е. получить права доступа в соответствии со своим участием в группах, внутри kerberos-билетов передаются идентификаторы его групп, упакованные в так называемом сертификате атрибута привилегий (Privilege Attribute Certificate, PAC). За обработку PAC на стороне FreeIPA отвечает плагин ipa-kdb, но так как в среде Linux используются не SID, а POSIX идентификаторы, то при обработке сертификата должно быть выполнено сопоставление идентификаторов одним из двух доступных способов.

Если в AD DS установлен компонент Identity Management for UNIX (IDMU), то у объектов будут заданы атрибуты uidnumber/gidnumber и вы сможете их использовать, для чего в момент установления доверительных отношений следует указать параметр ipa-ad-trust-posix. Если указанный параметр не будет задан, то по умолчанию идентификаторы будут рассчитываться арифметически: на стороне FreeIPA каждому доверенному домену AD DS будет назначен выделенный диапазон POSIX-идентификаторов. Размер этого диапазона составляет 200 тысяч номеров, поэтому для крупных доменов AD DS его нужно будет расширить вручную.
 
Проверить существующие доверительные отношения и их диапазоны можно командами ipa trust-find и ipa idrange-find. Информацию о том, в какие группы входит пользователь доверенного домена и какие у них идентификаторы, можно получить с помощью команды id:

# id Administrator@WIN.COMPANY.LOCAL
uid=1633600500(administrator@win.company.local) gid=1633600500(administrator@win.company.local)группы=1633600500(administrator@win.company.local),1633600520(group policy creator owners@win.company.local),1633600519(enterprise admins@win.company.local),1633600512(domain admins@win.company.local),1633600518(schema admins@win.company.local),1633600513(domain users@win.company.local)

Для удобства администрирования прав доступа вы можете использовать в FreeIPA так называемые внешние группы (External groups), в список участников которых могут входить субъекты доверенного домена. Однако такие группы не имеют POSIX-идентификаторов, поэтому для предоставления доступа к файловым ресурсам вам нужно будет включить их в состав обычных POSIX-групп. Например, в следующем примере показано, как доменных администраторов AD DS можно включить в группу доменных администраторов ALD Pro:

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

Теперь рассмотрим вопрос авторизации в обратном направлении.  Для того, чтобы пользователи ALD Pro могли проходить в домене AD DS не только аутентификацию, но и авторизацию, объектам в домене FreeIPA назначаются идентификаторы безопасности в формате MS Windows, за что отвечает плагин sidgen. В ALD Pro этот механизм включен по умолчанию, поэтому у всех пользователей и POSIX-групп в LDAP-каталоге задано значение хранимого атрибута ipaNTSecurityIdentifier. Посмотреть SID любого объекта можно, например, с помощью команды wbinfo (winbind information), где ALD — это NetBIOS имя домена ald.company.local, admin — это логин желаемого пользователя:

# 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 и рассчитываются математически, исходя из значения их POSIX-идентификатора.

Идентификаторы безопасности групп пользователя упаковываются в PAC и передаются в cross-realm билете, за что отвечает плагин ipa-kdb. Далее эта информация обрабатывается уже контроллерами домена AD DS и включается в сервисные билеты, в результате чего становится доступна целевым системам. При желании, вы можете исследовать PAC-сертификат с помощью малоизвестной утилиты net ads kerberos pac из сокровищницы Samba. Будьте уверены, на стороне MS сервисам доступен полный перечень SID, за исключением тех идентификаторов, которые попадают под правила фильтрации из соображений безопасности.

И мы подошли к самой интересной части статьи. Так почему же столь распространено утверждение, что доверительные отношения FreeIPA - AD DS не работают в двустороннем режиме, если билеты, с которыми приходят пользователи FreeIPA, содержат необходимый перечень идентификаторов?

Ответ заключается в том, что при попытке назначить доступ с помощью стандартных оснасток MS Windows вы обнаружите, что поиск объектов в доверенном домене FreeIPA не работает, то есть вы не можете выбрать пользователя из списка, и, следовательно, не можете предоставить ему авторизованный доступ. Проблема возникает по той простой причине, что поиск выполняется путем обращения к глобальному каталогу на порт 3268, а во FreeIPA этого сервиса просто нет. Но мы предлагаем вам пару обходных вариантов, которые сработают даже в случае, если вы являетесь пользователем ванильной FreeIPA.

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

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

После добавления объектов в список доступа в стандартном окне безопасности они будут отображаться даже не по своим SID, а по привычным именам, т. к. в процедуре разрешения имен глобальный каталог не используется, в этом случае выполняется обычный RPC-вызов по транспорту SMB. Но данный способ полностью зависит от того, к ресурсам какой целевой системы вам нужно предоставить пользователю доступ. Поэтому мы предлагаем вам еще один более универсальный способ.

Вы можете создать в домене AD DS группу безопасности с областью действия «Локальный домен» (Domain Local) и включить в нее пользователей и группы из доверенного домена FreeIPA:

# SID группы или пользователя из ALD Pro
$ALDProSID = 'S-1-5-21-1784717832-1844364183-3442789864-1013'

# Группа из леса Active Directory с областью «Локальный домен» (Domain Local)
$ADDSDomainLocalGroupDN = 'CN=ALD-Group,CN=Users,DC=win,DC=company,DC=local'

# Включение объекта из ALD Pro в состав участников группы AD DS
$group = New-Object $group = New-Object DirectoryServices.DirectoryEntry("LDAP://$($ADDSDomainLocalGroupDN)")
[void]$group.member.Add("<SID=$ALDProSID>")
group.CommitChanges() 

Приведенные способы решения проблемы могут стать спасением для многих администраторов, но они все же крайне неудобны в использовании, поэтому R&D-команда нашего продукта ALD Pro приложила значительные усилия, чтобы в службе каталога FeeIPA из состава Astra Linux появился модуль глобального каталога, который позволяет использовать нативные инструменты MS Windows привычными вам способами, см. Рис. 2

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

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