This past week I spent a considerable amount of time troubleshooting issues with a Forest Trust that had been configured with Selective Authentication. My colleague has already detailed some of the potential pitfalls of a selective authentication forest trust here. But the issues I found are not covered by that post. There's a lot going on in the scenes behind a forest trust, and to properly understand it let's delve a little deeper into the subject.
A forest trust most heavily relies on DNS resolution to get information about the other trusted/trusting forest. This can be accomplished via conditional forwarders, stub zones, or secondary zones. My favorite has long been stub zones, in part because that was never the correct answer for any DNS question on MCSE exams, and in part because before Server 2008 they were better than conditional forwarders. Prior to Server 2008, conditional forwarders were set on a per-server basis, so it would be easy to forget the setting on a new domain controller. Server 2008 added Active Directory synchronized conditional forwarders. You still had to specify a particular set of servers to forward requests to, which you did not have to do in a stub zone. Secondary zones are okay, but pulling the entire DNS zone file of another forest is costly, and they may not want all their private DNS data at your fingertips. Long story short (too late!) my preference is for stub zones, but I'll live with conditional forwarders.
The next thing to understand is what Selective Authentication really means. When a forest trust is created, you can select either forest wide or selective authentication. In forest wide authentication, the trusted users have the SID for Authenticated Users added to their authorization data. This means that any trusted user has access to any resource in the trusting domain that local Authenticated Users would have. For some trusts, this is far too much access. In order to restrict access in a more granular way, selective authentication does not add the Authenticated Users SID to the authorization data for trusted users. Trusted users who will be accessing resources must be granted the Allowed to Authenticate permission to the Computer object hosting the resource.
What Microsoft does not mention, is that in order to add users from the trusted domain to a domain local group in the trusting domain, an admin needs to be able to query Active Directory in the trusted domain. Since selective authentication is turned on, they will not be able to access the directory on any Domain Controllers in the trusted domain. The workaround is to establish the trust with forest wide authentication first. Then create a domain local group for the admins in the trusted domain, and add those admins to the domain local group. Then edit the security settings for the Domain Controllers OU in ADUC. Add the Allowed to Authenticate permission on Descendant Computer Object for the domain local group of admins. This allows administrators from the trusting domain the ability to browse Active Directory and add users from the other forest. Finally, change the forest trust to selective authentication.
You might think you'd be all set. And if this were a single site, single domain forest, then you would be correct. The last piece to understand is how a client finds a domain controller to talk to in the partner forest. When trying to find a domain controller, a client will query DNS for all SRV records matching _ldap._tcp.dc._msdcs.yourdomain.name. It will get back a list of servers and try each one with a UDP ping until one responds. Then the client tries to find out what Active Directory site it is in. This is intended to keep communication local to the site. Most of the time, the Active Directory subnets in the partner trust will not have a site that lines up with the client subnet, so the client will just continue with the first server that responded. If there is a client subnet that matches, then the client will send a follow-up DNS query for SRV records matching _ldap._tcp.SiteName.sites.dc._msdcs.yourdomain.name. This might not be ideal if the site matches only has one flaky domain controller, or is on a high-latency WAN link, or is not even a routed subnet for the trust. The point is, that it is not immediately clear which domain controller a client is going to end up talking to, so every domain controller that it might talk to will need that Allowed to Authenticate permission.
Things get even more complicated when child domains and Global Catalog servers are brought into the mix. A GC has an abridged copy of every object in the forest, hence Global Catalog. When a query for directory information about the forest is made, any Global Catalog in the forest may answer the call. Server 2003 seems to restrict its calls to Global Catalogs in the root domain, but Server 2008 will take whatever Global Catalog server is available in any domain, including all those child domains. That means that all domain controllers in the child domains also require the Allowed to Authenticate permission as well.
Microsoft gives a decent overview of Selective Authentication, but they completely ignore this part of the configuration. That probably means that Selective Authentication is not terribly popular, and neither are forest trusts in general. The best articles are still mostly written against the Server 2003 platform. After working with Microsoft on this particular issue for a couple days, it became immediately evident that even their internal support is unaware of the black magic behind trust relationships. With the advent of ADFS and other forms of Federation and Identity Management, I expect that the venerable Active Directory trust will slowly fade into the obscurity of myth and legend. But if you actually need to get it working, then that's not a whole lot of help.
For a fantastic explanation of how domain controllers are located in trusted domains, look no further than this blog post.Labels: Active Directory, Active Directory Trusts, Forest Trusts, Microsoft, Selective Authentication, Windows Server 2003, Windows Server 2008