Bilateral Trusts with AD DS and Global Catalog Implementation in ALD Pro

Currently, many companies are thinking about migrating to Linux infrastructure and are planning to use the FreeIPA open source directory service or more functional solutions based on it, such as ALD Pro, instead of Microsoft AD DS. But no matter how ambitious the migration plans are, migrating all services and all jobs to Linux at once can be an overwhelming task even for very strong teams, so CIOs are looking very closely at the possibilities for deploying a hybrid environment, and one of the key tools for such deployment is a trust mechanism.

In this article, we will explain the most fundamental aspects of how FreeIPA – AD DS trusts work, explain why you need a global catalog module in ALD Pro, and share a few best practices that will help you if your infrastructure is still using the vanilla FreeIPA system.

Trust relationships allow users in one domain to authenticate transparently using the Kerberos protocol when accessing resources in another domain. For example, you can allow users from the AD DS domain to log into the operating system of computers running Astra Linux from the ALD Pro domain, or vice versa, allow ALD Pro users to connect from Astra Linux computers to file shares located in the AD DS domain, see below. Fig.1.

The trust mechanism is implemented in the Kerberos V5 authentication protocol, and the concept of trust is its foundation. For example, when you log on to a domain computer, it does not have direct access to your credentials, so it cannot authenticate itself and must trust the service ticket issued by the domain controller. The basis for trust is that the ticket is encrypted with a computer account password that is known only to the domain controllers and the computer itself. On the controller side, the password is stored in the LDAP directory (attribute krbPrincipalKey of the host account), and on the computer side in a regular disk file (see klist -k /etc/krb5.keytab).

Trust between domains works in a similar way: at the moment a relationship is established, special accounts are created in domains with a common key, which becomes the basis of trust. Later, cross-realm tickets are encrypted with this key, with the help of which users of the trusted domain are authenticated on the controllers of the trusting domain.

The ALD Pro directory service is built on top of the FreeIPA open source product, which introduced AD DS trust support in version 3.0. Trust relationships can be established both between forests, where FreeIPA acts as a forest with one domain (Forest Trust), and between specific domains (External Trust), which in certain cases may be preferable, for example, to reduce the number of recursive get requests cross-realm tickets.

Trust relationships with AD DS are established on the FreeIPA side using the ipa trust-add command:

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

win.company.local corresponds to the AD DS domain FQDN, administrator is the domain’s administrator account name, and the two-way key value specifies that the trust relationship should be two-way. When establishing relationships, it is recommended to specify the –password key and pass the password of the AD DS domain administrator to the script, since in this case all settings will be performed automatically. But if the specified credentials are not available to you, you can ask the AD DS domain administrator to create a trust on their side and provide you with a trust password. In this case, when establishing a relationship, you will need to use the –trust-secret key.

In order for a user from AD DS to be able to pass not only authentication, but also authorization, i.e., to obtain access rights in accordance with their membership in groups, identifiers of their groups are transmitted inside the kerberos tickets, packaged in the so-called privilege attribute certificate ( Privilege Attribute Certificate, PAC). The ipa-kdb plugin is responsible for PAC processing on the FreeIPA side, but since in the Linux environment not SIDs are used, but POSIX identifiers, identifiers must be matched in one of two available ways when processing the certificate.

If the Identity Management for UNIX (IDMU) component is installed in AD DS, then the uidnumber / gidnumber attributes will be set on the objects and you can use them, for which you must specify the ipa-ad-trust-posix parameter at the time of establishing the trust relationship. If the specified parameter is not set, then by default the identifiers will be calculated arithmetically: on the FreeIPA side, each trusted AD DS domain will be assigned a dedicated range of POSIX identifiers. This range is 200K numbers, so for large AD DS domains, it will need to be expanded manually.

You can check existing trust relationships and their ranges with the ipa trust-find and ipa idrange-find commands. Information about which groups a user of a trusted domain belongs to and what identifiers they have can be obtained using the id command:

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

For the convenience of administering access rights, you can use the so-called external groups (External groups) in FreeIPA, the list of members of which may include subjects of a trusted domain. However, these groups do not have POSIX identifiers, so you will need to include them in regular POSIX groups in order to grant access to file shares. For example, the following example shows how AD DS domain administrators can be included in the ALD Pro domain administrators group:

# 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) … 

Now consider the issue of authorization in the opposite direction. In order for ALD Pro users to be able to pass not only authentication, but also authorization in the AD DS domain, objects in the FreeIPA domain are assigned security identifiers in the MS Windows format, for which the sidgen plugin is responsible. ALD Pro has this mechanism enabled by default, so all users and POSIX groups in the LDAP directory have the value of the ipaNTSecurityIdentifier stored attribute. You can view the SID of any object, for example, using the wbinfo (winbind information) command, where ALD is the NetBIOS domain name ald.company.local, admin is the login of the desired user:

# wbinfo -n 'ALD\admin'
S-1-5-21-1724891028-2898148248-1736958143-500 SID_USER (1)

At the end of the SID, we see that the relative RID for the admin user from the ALD Pro domain is 500, which, by MS convention, corresponds to the Administrator account ID. You can add that the admins group ID is 512, which corresponds to the Domain Admins group, and for normal users and groups, relative ID values ​​start at 1000 and are mathematically calculated from their POSIX ID value.

The security IDs of the user’s groups are packaged in a PAC and passed in a cross-realm ticket, which is the responsibility of the ipa-kdb plugin. Further, this information is already processed by AD DS domain controllers and included in service tickets, as a result of which it becomes available to target systems. Optionally, you can examine the PAC certificate using the little-known net ads kerberos pac utility from the Samba treasure chest. Rest assured, on the MS side, the full list of SIDs is available to services, with the exception of those identifiers that fall under the filtering rules for security reasons.

And we come to the most interesting part of the article. So why is it so common to say that FreeIPA-AD DS trusts don’t work bidirectionally if the tickets that FreeIPA users come with contain the required list of identifiers?

The answer is that when you try to assign access using standard MS Windows snap-ins, you will find that the search for objects in the FreeIPA trusted domain does not work, that is, you cannot select a user from the list, and therefore cannot grant him authorized access. The problem arises for the simple reason that the search is performed by accessing the global catalog on port 3268, and FreeIPA simply does not have this service. But we offer you a couple of workarounds that will work even if you are a vanilla FreeIPA user.

First, you can assign permissions directly to the object’s SID. If we are talking about a file sharing service, then the ICACLS (Integrity Control Access Control List) command will help you:

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

After adding objects to the access list in the standard security window, they will not even be displayed by their SIDs, but by their usual names, since the global catalog is not used in the name resolution procedure, in this case a normal RPC call is made over the SMB transport. But this method completely depends on the resources of which target system you need to grant access to the user. Therefore, we offer you another more universal way.

You can create a security group in the AD DS domain with the scope “Domain Local” and include users and groups from the FreeIPA trusted domain in it:

# 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() 

The above solutions can be a lifesaver for many administrators, but they are still extremely inconvenient to use, so the R&D team of our ALD Pro product has made significant efforts to introduce a global catalog module in the FeeIPA directory service from Astra Linux, which allows you to use native MS Windows tools in the ways you are accustomed to, see Fig. 2

The global catalog module is already in beta testing and will be available in the product this summer! In one release with the global catalog, a synchronization module will appear, which will close another big block of hybrid deployment tasks, and we will try to cover it in one of our next articles.

We will be glad if our developments will help you in the implementation of the import substitution program at your enterprise. You can find more detailed instructions on setting up and debugging the work of trust relationships in the working documentation for the product.