Convincing a Windows Domain that we are trustworthy
Mon, 15 Mar 2010 - 22:40In the last few weeks I have been working on trying to find out how to make a Windows 2008 R2 Domain Controller, trust a Samba domain so that it would consider us able to handle PACs and therefore send us them.
This is different from the normal MIT Kerberos level trust. When using those trusts, the Windows DC does not expect the other Realm to be able to send PACs, understand PACs, or understand routing information for transitive trusts.
In order to set-up a cross-realm trust you need to make the Windows DC believe we are actually just another Windows Domain, with all the bells and whistles of a Windows Domain. Well, actually not all of them, and discovering exactly which ones was my goal.
As usual with Windows, there is a lot of redundancy and different ways to do things. Depending on the way you try to set up cross-forest trust relationships you will cause different netlogon RPCs to be issued.
After implementing some of them, and finding that some others were hard, I tried to find a way to reduce the amount of calls we need.
It turns out, as one might expect, that creating the 2 half of the trust on each DC would be easier as only the verification process is left. What I did not expect was that that was going to be true even if the tool used to create the trust on the Samba side, was actually a Windows 7 box.Long story short, after fiddling around and hacking up some netlogon calls obscenely, in some cases hard coding server names in there, I was able to convince the Windows DC that we were indeed a trustworthy realm. Something to which it could route kerberos packets including the PAC.
At the same time the Samba domain KDC was able to parse the PAC and use the cross-realm trust account password to release tickets. And the Windows side was able to use this to seamlessly access the Samba fileserver.
For the moment it is all a big hack, and I have tested it only with a one way trust relationships (the Samba domain trusts the Windows domain but not the other way around). Yet it allowed me to finally confine the problem and understand exactly what is the minimum set of calls we have to answer and, most importantly, what we are supposed to answer.
Because of the hacks this code won't go in any tree for now, but it the base I need to plan the next steps. There is a lot of work to do before we have the mechanism needed to substitute the hacks with the proper actions the Samba server needs to take.
Ah, almost forgot, while researching this matter I also found interesting oddities and some protocol issues. Those always spice up your day, as it derails all your work and distracts you from your path until you understand and then solve or work around the problem. Usually just to fall into a new one a few days later, just as soon as you got back to the thread and remembered what were you actually doing and expecting to happen, so that you can happily forget it all over again. But this is also fun if you can take it philosophically :-)