Samba4/Linking AD and unix directories

Revision as of 07:38, 4 February 2009 by Abartlet (talk | contribs) (add links)

Some thoughts on windows trusted domains

An introduction to Windows authentication

In AD, Windows authentication consists of two parts, which cannot be reliably be separated: Kerberos and NTLM

Kerberos has traditionally been one of the hardest networking technologies to implement correctly, but one that Microsoft has successfully deployed in AD.

The technology it displaced is also the reason that AD has worked so well - NTLM authentication has been the backbone of windows networking since before it even existed (the LM authentication part of this dates back to the original SMB protocol from IBM).

What makes this pair of authentication solutions so important is that they reinforce each other.

NTLM authentication is pretty simple in concept - it is a challenge/response based authentication system, where the server generates a challenge. In the domain sense this is more complicated, as the (file) server (for example) must generate the challenge, and then supply both the challenge and response to whatever server holds the password. It does this over the NETLOGON protocol in AD domains, and in return finds information about the user's groups.

Kerberos is instead a 'ticket' based authentication system, based on symetric cryptography to prove that because a user holds a ticket, the user's identity is proved.

When Kerberos works, it works pretty well - it is fast, reliable, secure and avoids the server needing to talk to a DC. However, when Kerberos fails - as it often does in the real world, it fails spectacularly without the change Microsoft introduced, and without the fallback to NTLM.

Whenever a user connects to a host that is not known in the Kerberos database (AD), or is contacted by an IP address, or where for some other reason Kerberos has failed, then the user will, without prompting or any bother, simply fall back to NTLM. This ensures the connection still goes ahead dispite the most adverse of network conditions. Without inspecting the traffic, it should be impossible to tell that a corporate network isn't using Kerberos.

The other things Microsoft did to Kerberos include support for name canonicalisation of both clients and servers, and server-side referrals.

These allow users to log in with an e-mail address that may show no resemblance to their actual principal. (This is known as logging in with a user principal name). When in a forest (at least), the KDC (for Kerberos) and NETLOGON server (for NTLM) will lookup the UPN wherever it is in the forest (presumably via the global catalog) and return either a ticket with the correct principal, or a referall (I presume) to the other KDC where the user can actually log in. (In kerberos, unlike NTLM, the servers and KDC in particular do not talk to each other on behalf of the user).

Similarly, the KDC will use it's directory knowledge (presumably the global catalogue again) to help client computers find the correct realm for a server, and to allow the server to be called many different names. These service principal names may or may not be directly tied to the DNS form of the realm, and it is the local KDC that helps the client computer find the correct destination. No local configuration is used (unlike the [domain_realm] mapping table in MIT kerberos).

Because client machines are only ever joined to one realm, and typically tickets are only obtained from that realm or it's trusts, it is clear who to ask for this initial information.

At the DC level, a general mapping between domains and realms is exchanged when trusted domains are established. See the LsarQueryForestTrustInformation call.

Finally, the PAC (an additional blob of information containing information on users, groups, logon drives, profile paths, full names etc) is attached to the kerberos ticket. This avoids the need for any lookups to the DC.

The result of this is that to Microsoft's Kerberos is substantially easier to use and deploy than traditionally the case with Unix Kerberos.

Trusted domain types

Active Directory has a growing array of different ways that it can be integrated into a series of trusted domains. These grew out of the NT4 trusts, which where one-way and not transitive - so a large company would have to set up a trust from every domain to every other domain. The tools eventually made it easier to setup two-way trusts, but the underlying technology didn't change.

In AD, the following trust types are available:

  • Parent-child trust: The simple case of a child domain. By means

of parent-child trusts, every domain in the tree can reach the whole tree (via the root if required)

  • Tree-root trusts: Joins new trees to an existing forest. Consider

the company merger for example.

  • External trusts: Akin to NT4 trusts, supporting NTLM authentication only
  • Forest trusts: Used between two different companies. Supports Kerberos

See these resources from Microsoft TechNet in particular:

A very good guide on the trusted domain types, and the ports and protocols used

Other challenges

SID filtering: When implementing domain trusts, we should validate the incoming user groups to ensure that they don't compromise security in this domain. Just because the SID is included does not mean the other domain was right to include it.

How should 'Unix' clients be made to handle canonicalisation and referrals? Should they run winbindd or similar to know about 'AD-like' forests?

Implications for trusted domains

The two authentication technologies in use here do have major implications for the design of an AD <-> IPA trusted domain solution. In particular, a solution that does not provide a target for NTLM authentication will be significatnly less robust for users who are 'pure kerberos' users, but who access AD resources. That is, at any time where the 'pure kerberos' user accesses another AD machine by IP address, or if something isn't quite right for Kerberos (time sync for example), the access will fail for the 'pure kerberos' users only.

Also, Kerberos is not universally used or available, particularly outside the corporate firewall (see for example MSCHAPv2 VPNs).

As such, it may be very much desired to implement the full NTLM stack in a trusted domain solution. Implemeting these NETLOGON calls would not be a particualr additional burden on top of the LSA and other things a trusted domain would need.