none
Network access through firewalls needed for trusts

    Question

  • Scenario:  One way trust between domain A and domain B, where domain B trusts domain A.  Domain A has single controller DCA (10.10.10.10), and domain B has single domain controller DCB (10.20.20.20), with a firewall separating them and appropriate AD ports open between the domain controllers.  The member objects in both domains do not have access through the firewall to the DCs in the other domain.  So SERVERB in domain B cannot access the domain A domain controller (DCA).  There is a service account in domain A that is used for some system processes, called SVCA.  There is a computer account in domain A called SERVERA.  There is a user account in domain B called USERB, and a computer account in domain B called SERVERB which has IIS installed on it.  

    I am trying to understand exactly how the communication path and logon will work for the following scenario.  Basically which DC each system and user account will use during authentication, and therefore what firewall ports need to be open.  

    1. USERB logs onto SERVERB in domain B.  Obviously both the user and computer logon occurs at DCB (10.20.20.20). 

    2. There is an application on SERVERB that calls IIS and runs a task, using the SVCA account from domain A.  This is where my question/misunderstanding is.  Does this authentication occur at DCB or DCA?  Does it happen at DCB and then the authentication is passed to DCA?  Or does it just directly call out to DCA?

    I found this article (https://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx) that maybe indicates that DCB should request the ticket from DCA, and then pass that onto SERVERB and SVCA. Here is the applicable quote from the article:  "To access a shared resource in another domain by using Kerberos authentication, a user’s computer first requests a ticket from a domain controller in its account domain to the server in the trusting domain that hosts the requested resource. This ticket is then issued by an intermediary trusted by both the user’s computer and the server. The user’s computer presents this trusted ticket to the server in the trusting domain for authentication."

    Can anybody shed some light on this for me?

    Monday, January 16, 2017 3:26 PM

Answers

  • > 2. There is an application on SERVERB that calls IIS and runs a task, using the SVCA account from domain A.
     
    SVCA needs access to DCA to get his TGT. And he needs access to DCB for his TGS.
     
    This is one of the best articles about Kerberos interop I ever stumbled across: http://technet.microsoft.com/library/cc772815.aspx
     
    • Marked as answer by jadedpuppy Tuesday, January 31, 2017 2:34 PM
    Monday, January 16, 2017 3:50 PM

All replies

  • > 2. There is an application on SERVERB that calls IIS and runs a task, using the SVCA account from domain A.
     
    SVCA needs access to DCA to get his TGT. And he needs access to DCB for his TGS.
     
    This is one of the best articles about Kerberos interop I ever stumbled across: http://technet.microsoft.com/library/cc772815.aspx
     
    • Marked as answer by jadedpuppy Tuesday, January 31, 2017 2:34 PM
    Monday, January 16, 2017 3:50 PM
  • > 2. There is an application on SERVERB that calls IIS and runs a task, using the SVCA account from domain A.
     
    SVCA needs access to DCA to get his TGT. And he needs access to DCB for his TGS.
     
    This is one of the best articles about Kerberos interop I ever stumbled across: http://technet.microsoft.com/library/cc772815.aspx
     

    But that access to DCA for the Ticket Granting Ticket is a direct route?  It doesn't go "through", or is not facilitated, by DCB?  In other words, it would just go directly to 10.10.10.10?

    From that article you linked, I would have thought that the following would be occurring (quote is from the article, under the "Cross-Realm Authentication Between Two Realms" subsection.  

    "When a user with an account in West wants access to a server with an account in East, the process is:

    1. The Kerberos client on the user's workstation sends a request for a service ticket to the ticket-granting service in the user account's realm, West.
    2. The ticket-granting service in West determines that the desired server is not a security principal in its realm, so it replies by sending the client a referral ticket—a TGT encrypted with the inter-realm key that the KDC in West shares with the KDC in East."
    Monday, January 16, 2017 4:19 PM
  • >     SVCA needs access to DCA to get his TGT. And he needs access to DCB for his TGS.
    >
    > But that access to DCA for the Ticket Granting Ticket is a direct route?  It doesn't go "through", or is not facilitated, by DCB?  In other words, it would just go directly to 10.10.10.10?
     
    Yes, it is a direct connection. If SVCA requests a TGS for SRVB from his DCA, DCA cannot issue this ticket (because SRVB is not a Member of Domain A). But DCA will issue a TGS Referral that directs SVCA to DCB. It will encrypt this TGS referral with the trust password, so DCB will know that SVCA is a valid account, and then DCB will issue the TGS for SVCA to access SRVB.
     
    >  2. The ticket-granting service in West determines that the desired server is not a security principal in its realm, so it replies by sending the client a referral ticket—a TGT encrypted with the inter-realm key that the KDC in West shares with the KDC in East."
     
    Exactly. DCA issues a referral, and SVCA then uses this referral to request a TGS from DCB.
     
    Monday, January 16, 2017 5:00 PM
  • >     SVCA needs access to DCA to get his TGT. And he needs access to DCB for his TGS.
    >
    > But that access to DCA for the Ticket Granting Ticket is a direct route?  It doesn't go "through", or is not facilitated, by DCB?  In other words, it would just go directly to 10.10.10.10?
     
    Yes, it is a direct connection. If SVCA requests a TGS for SRVB from his DCA, DCA cannot issue this ticket (because SRVB is not a Member of Domain A). But DCA will issue a TGS Referral that directs SVCA to DCB. It will encrypt this TGS referral with the trust password, so DCB will know that SVCA is a valid account, and then DCB will issue the TGS for SVCA to access SRVB.
     
    >  2. The ticket-granting service in West determines that the desired server is not a security principal in its realm, so it replies by sending the client a referral ticket—a TGT encrypted with the inter-realm key that the KDC in West shares with the KDC in East."
     
    Exactly. DCA issues a referral, and SVCA then uses this referral to request a TGS from DCB.
     
    I guess I'm confused as to why SVCA is requesting a TGS for SERVERB in the first place.  If the SVCA account is accessing domain A resources to do its "service work" (the work that the IIS application is kicking off), does it still need a TGS for the SERVERB?
    • Edited by jadedpuppy Monday, January 16, 2017 5:38 PM
    Monday, January 16, 2017 5:34 PM
  • Hi,

    One more article for your reference:

    How does Authentication Work Cross Domain?

    https://blogs.msdn.microsoft.com/anthonw/2006/08/02/how-does-authentication-work-cross-domain/

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, January 19, 2017 9:43 AM
    Moderator
  • Hi,

    One more article for your reference:

    How does Authentication Work Cross Domain?

    https://blogs.msdn.microsoft.com/anthonw/2006/08/02/how-does-authentication-work-cross-domain/

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thanks for the information.  That situation is pretty close to ours, but there is a small difference, as evidenced by my point 2 in my original question: 

    "2. There is an application on SERVERB that calls IIS and runs a task, using the SVCA account from domain A.  This is where my question/misunderstanding is.  Does this authentication occur at DCB or DCA?  Does it happen at DCB and then the authentication is passed to DCA?  Or does it just directly call out to DCA?"

    In our example the SVCA account is part of domain A, not domain B, like user 2 is in the article you linked.  

    The article says: "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.)."  This would seem to indicate that the TGT for the trusted domain can be accessed by the non-trusted, but Martin (whose opinion I obviously trust, lol) states: "SVCA needs access to DCA to get his TGT."  It sounds like Martin and the linked article are saying different things.


    Thursday, January 19, 2017 2:25 PM
  • Hi,

    User 2 from domain B and SVCA from domain A, Kerberos client on the user's workstation sends a request for a service ticket to the ticket-granting service in the user account's realm.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, January 23, 2017 3:52 AM
    Moderator
  • Hi,

    Just want to confirm the current situations.

    Please feel free to let us know if you need further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, January 31, 2017 7:44 AM
    Moderator
  • Hi,

    Just want to confirm the current situations.

    Please feel free to let us know if you need further assistance.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Both of you are saying the same thing, so it would certainly appear that my understanding was incorrect.  We haven't had the chance to test this fully in our environment to confirm this, but I doubt you are both wrong.  I have marked the original answer as correct.  
    Tuesday, January 31, 2017 2:34 PM