Florian’s Blog

I’ve been involved in a number of discussions with customers that all focussed on resource access across domain or even forest boundaries. The notion of implicit and explicit Trusts in Active Directory is a well-known construct, so I won’t explain the details here. I’ll just try to explain what happens under the covers.

 

Resource access within a forest, for example, a user in a child domain accesses a resource in the root domain, works “transparent”. Upon child domain creation, a trust relationship is established automatically - that’s what’s called an “implicit” trust. Resource access of security principals across the intra-forest trust just “works”, given that the security principal has access permissions on the resource.

This transparency is handled through Kerberos tickets. Within a trust, the KDCs trust one another and allow for transparent ticket issuance. Under the covers, looking from a client’s perspective, resource access works as follows:

 

(1) The security principal in child.contoso.com, a user in our case, tries to access a file share in the root domain. The user’s machine will ask DNS where the resource is to be reached. Upon retrieval of the IP address, the file server is accessed, asking for its preferred method of authentication. Being fans of Kerberos, both agree to use Kerberos.

 

(2) The user needs a Kerberos ticket to get hold of the resources on the file server. It will ask its domain-local KDC for a TGS ticket that it can present to the file server. The “domain-local KDC” is any Domain Controller in the child.contoso.com domain.

 

(3) Looking at the TGS request of the user and the service and the name of the resource, the Domain Controller for child.contoso.com immediately detects that the file server is not part of the child domain. It cannot hand out a ticket for the service, as only a KDC of the file server’s domain is able to. Instead, the child domain’s DC replies with a ticket for the KDC in the root domain, so that the user can get its access ticket from there.

 

(4) Transparently, the ticket reply from the child.contoso.com DC is taken and processed. The user’s machine uses DNS to get a list of the Domain Controllers for the contoso.com domain. Upon DNS resolution, the user’s machine uses another TGS request for the file service on the file server to ask the DC of the root domain for the ticket.

 

(5) That root DC replies with the actual ticket (since yes, the file server is member of the root domain) the user needs to access the resources on the file server.

 

Here’s a dump of what happened, network-wise (The client’s called “win7-client” in the nttest.intern.frickelsoft.net child domain and the resource is dropbox-2 in intern.frickelsoft.net, the root domain):

 

 

Now, resource access across forests works similarly. If a user in child.contoso.com tries to access a resource at external-files.fabrikam.com, the steps for the intra-forest resource access from (1)-(4) are identical.

 

(5) However, when the client computer asks the root Domain Controller for a TGS ticket for the resource in, say, fabrikam.com, the root Domain Controller cannot hand that ticket out. Again, as described earlier, only the resource’s KDC can hand out these ticket. So what the root Domain Controller does is hand out a TGS ticket for the Domain Controllers in the trusted forest’s root domain, fabrikam.com. The root Domain Controller in contoso.com knows that the resource is across the trust, as the DNS name suffix and the trust information are available.

 

(6) The client machine now gets the ticket to access fabrikam.com’s Domain Controllers. Via DNS, it figures out their IP addresses and poses a TGS request to one of the fabrikam.com DCs, asking for a service ticket for the external-files.fabrikam.com file server to access its file services capabilities.

 

(7) Finally, there’s someone who actually _can_ hand out the TGS for the resource: one of the root DCs at fabrikam.com can hand out the TGS ticket for external-files.fabrikam.com and help the client from the contoso.com child domain out.

 

Again, here’s a short network dump of this:

 

 

I have omitted some information like Global Catalog searches that happen under the covers and are transparent to the user. The whole procedure, described differently, can be found on Technet, at http://technet.microsoft.com/en-us/library/cc773178(v=ws.10), “Kerberos Authentication Process Over Domain Trusts” ff.

 

Now - what are the observations we need to take from how this works?

 

• The client machine does the work, chasing its way from KDC to KDC until it gets the ticket it requires
• Domain Controllers do background work and hand out tickets to next KDCs/Domain Controllers in the “Trust chain”
• In scenarios with resource forests or resources in a DMZ, this means:
  • Clients require access to all Domain Controllers in the trust chain - and the resource
  • Firewalls have to be adjusted accordingly
  • A “DC-DC” point to point connection is not enough to allow resource access
• A Domain Controller in the resource’s domain is the only DC that can hand out a ticket to that resource.
• Even if the root domain is supposed to be “empty”, if it hosts a number of services or another, trusted forest hosts services for child domain users, the root DCs will notice a certain amound of Kerberos traffic