-1

We have a client/server setup in two different domains that implement kerberos authentication. In order for the authentication to work we need to set up a trust between the two domain controllers. In our test lab the two domain controllers are able to reach each other, and the trust is easily created via the trust management interface.

However, in our future production environment only our clients and servers have connection, while their respective domain controllers are not able to reach each other.

Every tutorial and guide I've come across seem to suppose that the two domain controllers are on the same network, or at least open for internet traffic. Ours are not. Is there a way to set up a trust that does not require connection?

petrobrush
  • 13
  • 1
  • 2
  • 4
    You want two servers that can't see each other to communicate with each other? O_o – Bart Silverstrim Oct 27 '11 at 13:00
  • I think you are thinking of the 'trust' concept at too high a level and forgetting what that actually means underneath. – JamesRyan Oct 27 '11 at 13:21
  • Not possible. If you took two minutes to read the docs, you'd know that the two forests must be able to communicate with each other in some fashion. – MDMarra Oct 27 '11 at 13:34
  • I may be. I understood a trust to be the ability for one domain server when presented with authentication from another one, to accept it based on a valid trust to that other domain. I'm sending kerberos tickets via SSPI, which means that my server tells ad2 that my client is authenticated in ad1, and asks for the client to be authenticated in ad2 as well. Do the servers need to communicate at that point? – petrobrush Oct 27 '11 at 13:36
  • 3
    Have you read the docs yet? They clearly show that you need to be able to query the DNS servers in one forest from the other. They also give **many** other bits of info that show that connectivity is required. Do everyone a favor and read the documentation. Here's some to get you started. Technet is your friend. http://technet.microsoft.com/en-us/library/cc772808(v=WS.10).aspx – MDMarra Oct 27 '11 at 13:49
  • This would be a HUGE security issue to let a *client* tell a second server, "Yeah, I'm trusted by that guy over there" and the second server can't validate the claim. – Bart Silverstrim Oct 27 '11 at 14:00
  • Er.. that isn't quite what's happening. The client sends a ticket which has been encrypted by ad1, ad2 tries to decrypt this ticket via the shared secret by ad1 and ad2 established through the trust. If it can, then it knows the client has been authenticated. Ad2 does not ask ad1 for the clients full credentials, nor does the client send them. – petrobrush Oct 27 '11 at 14:36

2 Answers2

5

If the servers have no connection to each other (internet, intranet, whatever), this is not possible.

A possible solution for you is to make a VPN tunnel between the two locations or servers. Only then will you be able to make a trust between the two.

Bart De Vos
  • 17,761
  • 6
  • 62
  • 81
  • This might be acceptable, but will that vpn connection have to be open after a trust has been established? Is there a continous information flow going through a trust? – petrobrush Oct 27 '11 at 13:44
  • AD is constantly sending updates and information among servers. So yes, you'd want a constant pipe open. Really you need to open the networks properly to allow the servers to see each other. You're NOT going to proxy it. – Bart Silverstrim Oct 27 '11 at 14:01
  • Yes, Server A will poll server B to check for credentials. – Bart De Vos Oct 27 '11 at 14:01
  • 1
    Thanks for pointing out not only an answer, but also the best remedy. – petrobrush Oct 28 '11 at 09:24
3

How on Earth do you expect these 2 servers to share information if they can not talk to each other?

Serious question.

The answer is to set your network so that they can communicate properly...

Serious answer!

Dan
  • 15,280
  • 1
  • 35
  • 67
  • I imaginged I could do some things manually since I'll have admin control of both domains. (Insert table values, enter same passwords etc.) The authentication packages will travel through the network from ad1->client->server->ad2 and back, with no problem. – petrobrush Oct 27 '11 at 13:05
  • 3
    AD trusts last I knew involved AD servers talking to each other, not shifting trust by proxying through client systems. – Bart Silverstrim Oct 27 '11 at 13:07
  • Of course the trust won't happen through the client system, only the kerberos authentication packages after a trust has been established. Afaik this basically involves ad2 decrypting a ticket sent via clients from ad1 with a password shared by ad1 and ad2. Why couldn't I type the same password in both controllers along with a domain name, and have them trust that from me as the admin? What information is passed between two domain servers when establishing a trust that couldn't be manually imported/exported through a file or created with a common password? – petrobrush Oct 27 '11 at 13:41
  • 1
    I'm going to be honest and say I have no idea what you've just written, but I think you've misunderstood the whole idea of a two way transitive trust. What are you actually trying to achieve in the end? – Dan Oct 27 '11 at 13:48
  • [This picture](http://media.techtarget.com/digitalguide/images/Misc/kerberos_2.gif) explains programmatic kerberos authentication. i wondered if there was a way to do this in a situation where there was no company.com root domain. I'm using the Microsoft [SSPI](http://en.wikipedia.org/wiki/SSPI) interface to authenticate a user via the Kerberos security package. The larger picture is more of a stackoverflow question, but this detail of establishing a trust belongs here I think. – petrobrush Oct 27 '11 at 13:55
  • @petrobrush That picture clearly shows connectivity between east and west through the company.com forest root. Without that, it falls apart. – MDMarra Oct 27 '11 at 14:12
  • **I imaginged I could do some things manually since I'll have admin control of both domains** -- you imagined wrongly. **The authentication packages will travel through the network from ad1->client->server->ad2 and back, with no problem.** -- No, they won't. – Rob Moir Oct 27 '11 at 14:35
  • @RobertMoir Well, I'm the one sending these packages through the server and client I wrote, and I assure you they arrive at their target. [This](http://www.opengroup.org/comsource/techref2/FIGU_043.GIF) is how it's done when using NTLM. Now, if there's AD2AD communication during the InitializeSecurityContext() or AcceptSecurityContext() calls, I'm at a loss, and will have to keep a VPN tunnel open. – petrobrush Oct 27 '11 at 15:04