Share via

How does Authentication Work Cross Domain?

  • Article

A question that comes up frequently involving federated customers is how does an organization need to configure its firewalls to allow users in a trusted, but not fully trusted, domain to access their resources. Consider the following scenario:

[WEB RESOURCE]---|---FIREWALL---WAN---FIREWALL---|---[USER 2]
[DOMAIN CTRL A]--| |---[DOMAIN CTRL B]

User 2 wants to access a web resource in Domain A. The two domains (A and B) are part of the same forest, but share a common root domain, through which replication occurs. The domain controllers and other resources are not permitted for direct contact (because the firewalls are owned by someone else in the federation that doesn't care about making anything functional, only secure). Under these circumstances, what exactly happens when User 2 attempts to connect and authenticate to the Web Resource?

  1. User 2 from Domain B logs onto Domain B workstation.

  2. Domain B workstation contacts Domain B KDC to get user authenticated.

  3. Domain B KDC creates a Ticket Granting Ticket (TGT) for User 2 on Domain B. Included in the TGT is PAC (Privilege Attribute Certificate) data, which is the list of the SIDs of the global, domain local and universal groups that user is a member of.

    NOTE: A GC (for any domain) would need to be contacted for the universal group enumeration.

  4. User 2's workstation receives TGT, extracts PAC data and puts the listed SIDs into an access token that is locally created. It also adds the SIDs of any machine local groups of which the user or the user’s groups are members. That access token is used on that machine only (tokens don’t traverse the wire).

  5. Every time User 2 accesses a member server in Domain B for the first time, User 2’s workstation uses the TGT to get a session ticket for the member server from the Domain B KDC. The KDC generates the session ticket and embeds the PAC data from the TGT that the user presented to the KDC (which keeps the KDC from having to authenticate over and over, but also means that the user has to log off and log back on to get a refreshed PAC from a KDC). The member server receives the session ticket and uses the PAC data in the same way that the workstation did, generating the access token locally and checking its local SAM for any additional SIDs to add to the token.

  6. When User 2 wants to access the Web Server resource in Domain A, User 2’s workstation goes to Domain B’s KDC to get a TGT for Domain A (this is what the trust relationship facilitates; KDCs on each end of the trust exchange long-term keys so that they can issue TGTs for each other.).

  7. User 2’s workstation presents the Domain A TGT to a Domain A KDC and requests a session ticket for the Domain A resource server (the web server in this case). Domain A's KDC works the same way as Domain B’s KDC did when it comes to constructing the session ticket for the member server, including just dumping the PAC data into the session ticket. The only difference is that the Domain B KDC actually constructed the Domain A TGT.

  8. The Domain A member server behaves just like a Domain B member server would and the Domain B workstation did.

Now, here's where the firewalls come in: if User 2’s workstation can’t contact a Domain A KDC, then Kerberos authentication will fail and it falls back to NTLM, and then we start dealing with pass-through authentication, which is going to require direct connectivity between the DCs for the different domains. But, the web server doesn’t need to be able to access the source KDC (Domain B). Rather, User 2 needs to be able to access the Domain A KDC, which it probably can’t do if this federation is blocking this at the firewall. 

The problem can be somewhat compounded by the fact that the Domain Controller in Domain A won't necessarily be chosen on a consistent basis, so the hosting agency in the federation would need to allow access to potentially any DC in Domain A. In other words, firewalls would need to be opened (gasp!). 

Actually, Microsoft has recognized this scenario with the R2 release of Windows Server 2003 and provided what is called Active Directory Federation Services, which do allow more control over which domain controllers are used for cross agency authentication. The problem, however, is that ADFS is designed for a mulitple forest scenario, not multiple trusted domains in the same forest.

Comments

  • Anonymous
    April 04, 2007
    So what ports need to be opened up on the firewall?
  • Anonymous
    July 24, 2007
    The comment has been removed
  • Anonymous
    October 17, 2007
    Hi anthonw,Nice article whihc gave a clear picture about authentictaion in trusted domain. I have question that how ADFS use to create a trusted domain and how authentication works for it?