Chris Blankenship's Ramblings

Short version

When you chose to implement a cross forest trust with another organization you must realize that Kerberos Delegation is a real security risk.  A malicious admin could enable Kerberos Delegation on a server that would allow impersonation across the trust.

Long version

In the past couple of weeks I have been gathering information about security implications of Windows Active Directory cross-forest trusts.  To get up to speed on Windows Trusts you can head over to Microsoft’s TechNet article How Domain and Forest Trusts Work.

During a conversation with my customer a question came up about using Kerberos Constrained Delegation across the forest trust.  A little digging confirmed my suspicions that KCD does not work across domains, much less forest trusts:

With constrained delegation, a computer can be set to allow forwarding of credentials only to a specific list of services. Those services must reside in the same domain as the computer forwarding the credentials.

As usual I have to see this working (or not working in this case) so I built out a test lab that provided me the first hand experience with this limitation.  During this testing I also played around with Kerberos (unconstrained) Delegation.   More information about Kerberos Delegation can be found in this excellent article Advanced Kerberos topics: Delegation of authentication.

So while testing the KCD option I decided to try Kerberos Delegation.  After a couple tests to confirm my results I was surprised to discover that Kerberos Delegation works across a forest trust.  What’s the big deal right?  Everyone knows not to enable this option since it’s extremely insecure.

But wait a second.  Unconstrained Kerberos Delegation within a single forest is one thing, but in a cross forest trust scenario the stakes get much higher.  It would be nothing for a malicious admin to enable Kerberos Delegation on a web server and then use the credentials of web clients to access the trusted forest.

Follow me here with this.  Assume Forest1\Joe connects to Forest2\Webserver.  A malicious admin enables Kerberos Delegation on Forest2\Webserver and adds some back end code to reach across to Forest1 to create a user account or what ever else Forest1\Joe is allowed to perform.  As an admin in Forest1 there is no way to know if Forest2\Webserver is configured this way.

Now some of you may be aware of the Active Directory user option “Sensitive account, do not delegate” and think that would solve the problem.  As long as you don’t ever need to allow delegation for user accounts then this would in fact prevent this behavior.  But chances are you would want to leverage KCD for something like Outlook Web Access.

Unfortunately the risk of an admin enabling Kerberos Delegation is a real threat, one that is amplified when you introduce a cross-forest trust with an organization that you don’t completely manage.