Logo Samba, Sprechblase "what do you think"

In this article we would like to inform all IT administrators and IT-interested people about the possibilities of a trust between two domains (UCS Samba/AD and Microsoft AD). To set up a trust is to give users of one domain access to the resources of another. This can increase the scope for actions in some situations!

In our example, we will specifically refer to the interaction between Samba in UCS and Microsoft Windows, explaining in detail how a so-called trust relationship can be configured and informing about the current state of implementation.

Trusts in Windows: Option ‘External Trust’

Already Windows NT domains can be configured to trust authentication decisions of another domain – so called ‘external trust’ – and the Samba project supported it accordingly in the 3.x series of the software.

In addition to external trusts, Active Directory domains also know of the ‘forest‘ type trusts. For forest trusts, as always with Kerberos, synchronizing the system times between both domains is essential.

Trusts in Samba 4

In Samba/AD domains, i.e. from Samba 4.0 onwards, trusts were unfortunately no longer supported, because the project focused on stabilizing the new Active Directory-related components first and later on the new protocol versions SMB2 and SMB3. With the unification of the two Winbind implementations from Samba 3.x and Samba 4.x – which was supported by Univention, amongst others – it became possible for the first time that trusts could also be established with Samba 4.3. The first tests with Samba 4.3.7 at the beginning of 2016 however showed that the stability of the trusts had not qualified for productive use then. Fortunately, with Samba 4.5.1 this problem was repaired.

Uni- and Bidirectional Trust

A trust relationship between two domains can be unidirectional or bidirectional. In order to establish a unidirectional trust, originating from a ‘resource domain’ (‘trusting domain’) and addressing 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 that is created in the ‘resource domain’ and to which a password is set, which is stored as plain text in the ‘account domain’ during setup. In Samba/AD domains, this constellation is very easy to set up at the command line using the tool samba-tool, no matter whether uni- or bidirectional.

However, the prerequisite for this is that DNS resolution works across both domains. At least the domain controllers’ FQDN of the respective other domain must be resolvable in order for the communication between the domains to work. The best way to do this is to configure a DNS forwarding in both domains.

Example of 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, for example, 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

In addition, it may be useful to create a static entry in the /etc/hosts:

root@master:~# ucr set hosts/static/10.200.8.20=master.ucsdom.example

AD side:

On the Windows AD DC, a so-called ‘conditional forwarding’ can be set up for the UCS domain via the DNS server console. After this preliminary work, the trust itself can be established directly from the command line of the UCS Samba/AD DC.

The following steps, for example, set up a bidirectional trust of the type ‘external’:

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 of the Windows Active Directory domain. The login name must either use the format UCSDOM\username or the Kerberos principal in the notation username@nullucsdom.example.

More options of the samba-tool

The samba-tool offers a few further possibilities, e.g., the validation of the trust (samba-tool domain trust validate) or the establishment of unidirectional trust in any direction.

Limitations of the Current Samba Implementation

However, the current Samba implementation does not fully meet the criteria that native Windows systems expect in some situations. For example, clients who are embedded in the UCS domain unfortunately will no longer evaluate group policies after a trust relationship between a UCS Samba/AD domain and, for example, a native Microsoft Active Directory domain has been set up. Unfortunately, first steps to analyze the network traces have not yet provided any insight into the cause of this restriction.

Additionally it should also be possible to authenticate users from the Microsoft Active Directory domain on a UCS Samba/AD DC. However here, for productive use the so-called identity mapping, that is the assignment of SIDs to Posix IDs (UID / GID), is also important, but this should not be discussed here.

Evolution of the UCS Services for Windows

This shows that the area of UCS services for Windows remains an exciting subject. The focus of the various players of the Samba team is shifting steadily across releases. In addition to the two core topics Active Directory domain services on the one hand and the SMB protocol extensions on the other hand, special, in this case cross-domain features receive less attention. Also security aspects such as SID filtering are still on the to-do list of the Samba team.

Univention will actively accompany this development as well as closely monitor the interests of our customers in issues such as these. After all, our ultimate goal is that all information technologies can be easily combined with one another.

We are looking forward to your feedback!

Arvid Requate is Open Source software engineer at Univention and mainly engaged in the area of directory services, authentication and Samba.

What's your opinion? Leave a comment!

Your email address will not be published. Required fields are marked *