Cross forest authentication

 

Anyone installed a forest trust before.. probably else you would not be reading this post.. how does authentication work in a forest trust?

Well there are two authentication mechanisms in Windows NTLM and Kerberos, both can be used in a forest trust, and both work differently. Setting it up brought me the following authentication schema..

 

 

1…11, getting the kerberos ticket for the file resource server..

 

A-I is the actual NTLM authentication path..

So what does the picture say.. lets say we hit the fileserver on the right side with the client on the left. The file server requests a kerberos service ticket and the client must go to a domain controller of each domain to get a service ticket from the domain controller in Intranet.biscuits.net. It does this by using the routing hints it receives from each domain controller. (so his own DC will say, i do not know that domain, but I do know we have a trust.. can you ask the Cookies domain controller, that domain controller will say, I have a trust with biscuits.netask him.. and the biscuits.net will say, perhaps you can try intranet.biscuits.net)

If the server asks the client for NTLM authentication it creates a challenge. This challenge must be encrypted by the client and together with domainname and username the encrypted challenge (the response) is sent to the file server. This file server must verify the answer, therefore it gives the complete package including the original challenge to his domain controller. This domain controller has three options. it can perform a passthrough authentication (discarding the domain name and see if the same user/password combination exists in his domain), deny the request or forward the request to the next hop. This hop is computed from the trust path, in this case it will forward it to the rootdomain controller actually following the trust path. That domain controller will forward the entire package (so again: domainusername, the challenge and the response) to the other rootdomain controller who is the one that can identify the right domain controller to be used. That domain controller will look in the AD for the username and search for the hash of the user. It will encrypt the orgininal challenge also and compare the outcome to the response it received (the one that the client made). If they match, the domain controller will give the go signal.