Understanding Kerberos Double Hop

Kerberos Double Hop » D' Technology Weblog: Technology, Blogging, Tips, Tricks, Computer, Hardware, Software, Tutorials, Internet, Web, Gadgets, Fashion, LifeStyle, Entertainment, News and more by Deepak Gupta.

Mon, 16 Jun 2008 11:00:21 GMT

PingBack from http://www.ditii.com/2008/06/16/kerberos-double-hop/

re: Understanding Kerberos Double Hop

barkills — Mon, 16 Jun 2008 19:51:01 GMT

"The service accounts and the computer accounts hosting the applications need to be in the same domain."

Can you explain why this statement is the case for the three scenarios where Kerberos is permitted across domain boundaries? Those three scenarios are intraforest, interforest with a forest trust, and cross-realm with a Kerberos cross-realm trust.

Thanks,

Brian Arkills

re: Understanding Kerberos Double Hop

Stevta — Mon, 16 Jun 2008 21:14:43 GMT

If your middle tier is using open delegation you can cross realms. Wheneven possible you should use constained delegation and that limits the service principal name you can choose to the middle tier's kerberos realm.

Another issue you can run into is with PAC verification can only follow direct trust and not through inherited trusts via a cross forest trust.

From a security standpoint you theoretically want to limit delegation so you do not find yourself passing credentials to other domains or forests.

So even though you maybe able cross security realms with authentication in a scenario where you are delegating authentication you should limit your exposure as best practice.

Steve

Interesting Links - 6/18/2008

Matt Johnson's Technical Adventures — Wed, 18 Jun 2008 15:32:57 GMT

To DEP or not to DEP – A good post on DEP from the Performance Team Windows XP era draws to a close –

SSRS and SSAS Integration for Microsoft Dynamics AX 2009

Pin Wang's AX Blog — Tue, 16 Jun 2009 23:59:04 GMT

For the latest version of this document, please refer to the website: https://mbs.microsoft.com/customersource

re: Understanding Kerberos Double Hop

sinman — Tue, 21 Jul 2009 03:36:46 GMT

"Source and target servers must be in the same forest or there must be a forest level trust between forests and the first level service account must be in the trusted forest root."

Does this mean the trust has to be a mutual trust between forests?

For example, (using your diagrams), if we have "server1.dc1.mydomain.com" and "server2.dc2.mydomain.com", and the dc2 forest trusts the dc1 forest, but the dc1 forest does not trust the dc2 forest, can we still set up KCD?

re: Understanding Kerberos Double Hop

Rob Greene — Thu, 23 Jul 2009 18:59:35 GMT

Hey Sinman,

it is really not easy to answer the question on will a one-way forest trust work vs do I have to have a two way trust.

First since you are saying KCD - (Kerberos constrained delegation) all accounts used in the delegation MUST reside in the same domain.

This means any account impersonating the user account all must exist in the same domain.

If you have a web application talking to a SQL Server.

As long as the Web Application Pool, and the SQL Server Service account exist in the same domain it would work.

However, if you had some kind of DCOM application it might not work if the server accounts were in separate domains. This is because typically at some point you are going to present the users kerberos ticket to the machine account (Which needs to be trusted for delegation) to make the RPC / DCOM call over to the remote system and thats when a solution like this would fail when the accounts do not exist in the same domain.

This is why all MS Technet documentation states computer and service accounts must exist in the same domain. Because there are too many caveates to really give anyone a good answer. This is the same reason why almost all documentation states a two way forest trust is required.

The best guidance I can really give you is to try your configuration with a one way trust and see how it works for you... Nothing trumps testing a solution. But I will tell you that if you do want to attempt a one-way trust setup, make sure that the delegation accounts all exist in the users forest!