Establishing a trust relationship means giving users of a domain access to the resources of another domain. In some situations this can extend the options for identity management. In the following example, I will refer to the interaction between Samba in UCS and Microsoft Windows. I will explain in detail how a so-called trust relationship can be configured and what the current state of implementation is.
Since UCS 4.4-0, unidirectional trust relationships originating from Windows are supported, i.e. the direction „Windows trusts UCS“. In this configuration, users from a UCS Samba/AD domain can authenticate themselves to a Microsoft Active Directory domain e.g. and access resources from there. In a way, this represents an alternative to operating UCS as a member of an AD domain. Further information on configuration is provided in the corresponding section of the UCS Administrator’s Manual. Furthermore, we have gathered basic information on the topic “Central Domain management with Samba and Active Directory” for you on our blog.
Trust relationships in Windows: Option „External Trust“
In addition to “external” trust relationships between domains, Active Directory also provides “forest” type trusts. In the context of this blog article, we are talking about trust relationships between two domains, not between or within forests. More details on this topic are explained in the Microsoft documentation (e.g. https://docs.microsoft.com/en-us/azure/active-directory-domain-services/concepts-forest-trust).
Uni- and bidirectional trust relationship
A trust relationship between two domains can be configured to be unidirectional or bidirectional. To establish an unidirectional trust relationship, which is based on a “resource domain” (also “trusting domain”) and an “account domain” (also “trusted domain”), a so-called “Trust Domain Object” (TDO) must be created in the Resource Domain. This is a special authentication account which is created in the resource domain. This account is secured with a password, which is stored as plain text during the setup in the account domain. In Samba/AD domains, this constellation can be set up very easily at the command line using the samba-tool tool, whether unidirectional or bidirectional.
However, this requires that DNS resolution works across both domains. At least the FQDNs of the domain controllers of the other domain must be resolvable in order for the communication between the domains to work. The most simple way to do this is to set up DNS forwarding in both domains.
Example for a bidirectional trust
For the following example we assume that the UCS DC master “master.ucsdom.example” has the IP address 10.200.8.10 and that e.g. the native Microsoft Active Directory DC “dc1.addom.example” has the IP 10.200.8.20.
UCS side:
root@master:~# cat >> /etc/bind/local.conf.samba4 <<%EOR zone "addom.example" { type forward; forwarders { 10.200.8.20; }; }; %EOR root@master:~# service bind9 restart ## Checks: root@master:~# host dc1.addom.example dc1.addom.example has address 10.200.8.20 Additionally, it can be useful to create a static entry in /etc/hosts: root@master:~# ucr set hosts/static/10.200.8.20=dc1.addom.example
AD side:
On the Windows AD DC, a so-called “conditional forwarding” can be set up for the UCS domain through the DNS server console. After this preparatory work, the relationship of trust itself can be set up directly from the command line of the UCS Samba/AD DC.
For example, the following steps set up a bidirectional trust relationship of the “external” type:
root@master:~# samba-tool domain trust create addom.example \ -k no -UADDOM\\Administrator%ADAdminPassword \ --type=external ## Checks: root@master10:~# samba-tool domain trust list Type[External] Transitive[No] Direction[BOTH] Name[addom.example] root@master10:~# wbinfo --ping-dc –domain=addom.example checking the NETLOGON for domain[ADDOM] dc connection to "dc1.addom.example" succeeded root@master10:~# wbinfo --check-secret –domain=addom.example checking the trust secret for domain ADDOM via RPC calls succeeded
After the setup, a UCS user should be able to log on to systems in the Windows Active Directory domain. The login name must either conform to the format UCSDOM\username or the Kerberos principal in the notation username@ucsdom.example.
Further options of the Samba tool
The samba tool offers a few more possibilities, e.g. the validation of the trust relationship (samba-tool domain trust validate) or the establishment of a unidirectional trust in any direction.
Limitations of the current Samba implementation
The current Samba implementation unfortunately does not yet fully meet the criteria offered by native Windows systems, e.g. SID filtering, which requires that the trusted domains be in the same administrative trust context (for more details see the Microsoft documentation on SID Filtering and Claims Transformation , the Microsoft Security Bulletin MS02-001 or the presentation “Trusted Domain Support as Active Directory Domain Controller” by Stefan Metzmacher (Samba).
With the current state of implementation in UCS, it is possible for users of a UCS domain to use resources in a familiar Microsoft Active Directory domain, e.g. to log on to a desktop that is part of the native MS AD domain.
In addition, the authentication of users from the Microsoft Active Directory domain to a UCS Samba/AD DC should be possible in general. For productive use in practice, however, the so-called identity mapping, i.e. the assignment of SIDs to Posix IDs (UID/GID), is also necessary. However, this will not be discussed further in this article. Just this much: Without further configuration each UCS server carries out its own individual ID mapping. That means, if an external user logs in, the local Winbind service assigns a POSIX-uid (& POSIX-gid) to this user. This can lead to unwanted effects if such a user can store files in a file system and this is mounted on another server at a later time.
Relevant notes
A characteristic of trusts is that users in the respective foreign domain receive the name of the domain as prefix. This is necessary to avoid name collisions. On Windows this should happen transparently; on Linux the user names of the guests then follow the scheme “OTHERDOMAIN+username”. On Microsoft Windows clients, you can log in either with “OTHERDOMAIN\username” or with the Kerberos user principal name username@OTHERREALM.