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@ucsdom.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!


Artikelempfehlungen


Use UCS Core Edition for Free!

Download now
Arvid Requate

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!

Comments

  1. Hello,

    Did you have any success in configuring trust relationship using the last version (4.8) of samba4?

    Reply
    • Hello Elias,

      thanks for asking, I actually tested this yesterday with Samba 4.8.2 to collect new network traces and unfortunately this issue is still present. I’ll see what we can do about it and comment here once we see progress.

      Reply
  2. Thanks for the feedback Arvid!!! 😀

    I am also testing and so far I haven’t had good results.

    Thank you!!!

    Reply
  3. Yesterday at the SambaXP conference there was a presentation titled “Trusts Status Update”, given by Stefan Metzmacher, the principal developer in the AD part of Samba. He has been working on the foundational plumbing for trust related interoperability for at least about two years now. A lot of this work is already included in Samba 4.8, and there are chances that Samba 4.9 will include another heap of work in the area. Metze had the GPO issue on his presentation slides, so he is well aware of it and I’m confident that he will look into it as soon as the final basic security related work has been finished. My impression is, that his implementation plan is guided by the principal idea that it doesn’t make sense to “make it work somehow” for users as long as you end up having set up a massive security hole by establishing a trust relation between to Samba/AD domains in the first place. I can totally understand his priorities here. We are very glad he has this thorough expertise and oversight to implement all of this and thankful that he is working in the open source community. I will offer my help where I can.

    Reply
  4. Good news so !!!! 🙂

    I also agree that there is no point in releasing something just so that trust is established, but at the same time a greater gap is opened that can break the security that the samba already has. Last night I managed to put two samba4 AD on trust. Now I need to leave testing for longer and try to analyze the behavior.

    Reply
  5. Hello Arvid,

    How can I audit the trust between domains?

    Reply
    • There is “samba-tool domain trust validate”, check “–help” to see available options. I’m not 100% sure which combination of options “validate” requires (e.g. “–validate-location”, “–username”, “–password”, “–local-dc-username” and “–local-dc-password”), IIRC the “–username” is the remote one and may require a syntax like “ADDOM\\Administrator” (like it’s specified in the “create” step above). I have also not tested recently how fit the “validate” tool is the latest Samba, I vaguely remember that it behaved a bit peculiar in earlier Samba versions.

      Reply
      • Thanks for the help Arvid!!! Now I’m working with trusts on production servers. I will monitor and verify that the trust is stable. I report here for new updates. Thank you!!

        Reply
  6. Hello Arvid,

    Did you notice if in your tests the trust relationship occurred to fail the GPO application on one side of the relationship?

    Here with me at first seems to have been affected by the trust. I put two domains into trusts and it was about 2 weeks ago that I set up trusts in production, but then today I started to investigate why the GPOs in our main domain were not being applied. By removing the trust, everything went back to normal.

    Reply
    • Yes exactly, that’s the primary blocker why we cannot recommend it currently, as explained in the section about limitations above. We just want to know how much interest there is in this functionality. That would give us an idea how much energy to put into this.

      Reply
  7. Hello Arvid,
    Samba 4.9 has been released. It seems to me that there was great evolution in this version.
    Do you intend to implement it with UCS?

    Best regards,
    Michael

    Reply
    • We will definitely consider updating but there are at least two things to keep in mind about this. First, an update to a recent Samba version (later than 4.8) will change the primary key of the backend sam.ldb database and we will have to see how stable the automatic conversion is. Probably the Samba team has done a good job there, but it is definitely a certain amount of risk. The second point is the question if that already makes people happy that want to use trust setups, because – I guess – there is another thing to consider and that is the question of “identity mapping” (idmap): since Samba works on Linux systems, when an external, trusted AD-user logs in and creates a file on the Samba server, then Samba needs to assign a Linux (Posix) uid number to that user (to be able to write that into the owner field of the Linux file metadata). Now, on a single server Samba will simply assign the next free uid from a certain pool (above 3000000 by default). That’s ok, but if you have a couple of servers things get messy and insecure, because both servers have their own different mapping tables. There are concepts how to address this but it needs to be tested. And, reading the Samba change logs, we may want or even need to add some functionality to our S4-Connector too.

      But all those concerns aside, yes, sure, we will definitely consider the integration of the update, but I cannot say anything definite right now. All I can say is that we have done Samba updates during release cycles before (e.g. for security reasons), so we are not tied to wait for a major release.

      Reply
  8. Todays UCS 4.4-0 release supports unidirectional incoming trusts, i.e. the direction Windows trusts UCS. In this configuration users of a UCS Samba/AD Domain can log on to a Microsoft Active Directory domain to use its ressources. In some respect this is an alternative to using UCS as a member of an AD domain. Additional information about the configuration can be found in the corrsponding section of the UCS manual for users and administrators.

    Reply

Leave a Reply to Elias Cancel reply

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