none
A couple more questions about Kerberos cross forest trusts

    Question

  • Can someone please help me with the following question J

    I am trying to clarify my understanding of Kerberos trusts

    I have read a number of documents but sometimes they appear to contradict themselves (even within the same document), so this leaves you with a fussy view of the truth.

    Firstly, I understand Kerberos and TGT (ticket granting ticket) and ST (service tickets) my question is focused on the detail of what happens when dealing with Forest Trusts and External Trusts

    Dealing with a Forest Trust (trust between two domain roots both of which are AD 2012 R2)

    Question 1.

    If a user in the trusted forest want to gain access to a resource in the trusting forest, I believe they need to obtain a TGT from the trusting domain (resource domain)?

    I believe the above is correct, because without a TGT for the resource domain they will not be able to request <g class="gr_ gr_57 gr-alert gr_gramm gr_run_anim Grammar multiReplace" data-gr-id="57" id="57">a ST</g> for the resource in the target domain, and I believe the only KDC (key distribution center) that can issue a TGT for a resource in a given domain is a domain controller in the same domain as the resource being accessed

    Is my understanding/login above regarding the TGT for the trusting domain correct?

    Question 2:

    If the above is correct (TGT needed from the trusting domain), then what part in obtaining this TGT does the Trust itself play (if any) apart from creating a secure channel between DCs in each forest for the request to travel.

     

    From what I have read I understand a user requesting access to a resource in the trusting domain first asked it’s local DC (in the account/trusted domain) for a ‘referral’ to <g class="gr_ gr_36 gr-alert gr_gramm gr_hide gr_run_anim Grammar multiReplace replaceWithoutSep replaceWithoutSep" data-gr-id="36" id="36">an appropriate domain controllers</g> in the trusting domain. 

    If this is correct what is in this ‘referral’? i.e. it is just a redirection to tell the client how to transverse the trust path to reach the DC in the trusting domain;

    Or is there some meta or security data in this ‘referral’ that the trusting DC requires to authentication the request?

    Or can the trusting domain controller simply look at the SID of the requesting user to determine it comes from a domain which it trusts and simply proceed to grant a TGT on that basis alone?

    Thanks very much in advance

    __AAnotherUser


    AAnotherUser__

    Sunday, January 22, 2017 5:24 PM

Answers

  • I found the answer to my remaining question :)

    watching the video which is a very detailed YouTube Video (link below), it covers both Kerberos forwarding/delegation (aka second hop) and cross-realm and answered the question about the session keys.

    https://www.youtube.com/watch?v=AVH4c-mWnMY

    Thanks

    __AAnotherUser


    AAnotherUser__

    • Marked as answer by AAnotherUser Tuesday, January 24, 2017 5:29 PM
    Tuesday, January 24, 2017 5:29 PM

All replies

  • As the above post came out a bit weird syntax wise I have posted it again below (hopefully it will come out OK this time)

    Can someone please help me with the following question J

    I am trying to clarify my understanding of Kerberos trusts 

    I have read a number of documents but sometimes they appear to contradict themselves (even within the same document), so this leaves you with a fussy view of the truth.

    Firstly, I understand Kerberos and TGT (ticket granting ticket) and ST (service tickets) my question if focused on the detail of what happens when dealing with Forest Trusts and External Trusts

    Dealing with a Forest Trust (trust between two domain roots both of which are AD 2012 R2) 

    Question 1.

    If a user in the trusted forest want to gain access to a resource in the trusting forest, I believe they need to obtain a TGT from the trusting domain (resource domain)?

    I believe the above is correct, because without a TGT for the resource domain they will not be able to request a ST for the resource in the target domain, and I believe the only KDC (key distribution center) that can issue a TGT for a resource in a given domain is a domain controller in the same domain as the resource being accessed 

    Is my understanding/login above regarding the TGT for the trusting domain correct?

    Question 2:

    If the above is correct (TGT needed from the trusting domain), then what part in obtaining this TGT does the Trust itself play (if any) apart from creating a secure channel between DCs in each forest for the request to travel. 
     
    From what I have read I understand a user requesting access to a resource in the trusting domain first asked it’s local DC (in the account/trusted domain) for a ‘referral’ to an appropriate domain controllers in the trusting domain.  

    If this is correct what is in this ‘referral’? i.e. it is just a redirection to tell the client how to transverse the trust path to reach the DC in the trusting domain; 

    Or is there some meta or security data in this ‘referral’ that the trusting DC requires to authentication the request?

    Or can the trusting domain controller simply look at the SID of the requesting user to determine it comes from a domain which it trusts and simply proceed to grant a TGT on that basis alone?


    AAnotherUser__

    Sunday, January 22, 2017 5:25 PM
  • Hi,
    Basically speaking of Kerberos in domain, the authentication process for a domain user to access their computer is:
    • The Kerberos client requests and then receives a TGT from the KDC.
    • The Kerberos client uses the TGT to request and then receive a service ticket for the local workstation from the KDC.
    • The service ticket for a network resource would be encrypted with the system or service key depending on whether the resource is a system or service. The workstation has a system key created when the computer joined the domain. The service ticket for the workstation is encrypted with this key.
    • The local LSA builds an access token from the credentials contained in the service ticket and then grants or denies the user access.
    While the Kerberos works over forest trust, the process is:
    1. User logs on to Workstation using credentials from trusted forest. The user then attempts to access resource in trusting forest.
    2. Workstation from trusted forest contacts the Kerberos Key Distribution Center (KDC) on a domain controller in its domain and requests a service ticket for the resource server SPN.
    3. This DC in the trusted forest does not find the SPN in its domain database and queries the global catalog to see if any domains in the trusted forest contain this SPN. Because a global catalog is limited to its own forest, the SPN is not found. The global catalog then checks its database for information about any forest trusts that are established with its forest, and, if found, it compares the name suffixes listed in the forest trust trusted domain object (TDO) to the suffix of the target SPN to find a match.
    Hope that the process as above helps you on the questions.
    Best regards,
    Wendy

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

    • Proposed as answer by Todd Heron Monday, January 23, 2017 10:00 PM
    Monday, January 23, 2017 8:04 AM
    Moderator
  • Hello Wendy
    Thank you very much for taking the time to reply, 

    I understand all of the information you wrote above (and have been continuing to read more Kerberos information since I placed the above post).

    I do have a couple of points I would like to clear up please, as I need to understand this exactly and some of the documentation varies and is not complete. I appreciate my question is quite detailed but I have to ask it as I have never seen a complete explanation written down anywhere in the Microsoft documentation I have read and it is critical for me to understand it, thanks in advance.

    If we have Forest-A and Forest-B (let's say with a two-way forest trust setup to keep things simple) we will also assume I have 'one' domain in each forest (root domain)

    I am a user and Forest-A and the Share (CIFS) I want access to is in Forest-B

    As you allured to in the last part of your reply I need to get a Service Ticket for a given SPN
    I need to get this Service Ticket from a KDC (DC) who knows the SPN as the KDC needs to encrypt the Service Ticket with the SPN related password (StringToKey function) it has stored in its database (Active Directory)

    Now in order to get a Service Ticket from a KDC I need to present a TGT,

    I already have a TGT but this is for my Domain (in forest-A) because it is encrypted with the password of the KDC for 'my domain' and therefore cannot be read by the domain controllers (KDC) in forest-B (unless they just happen to have the same one, which is very unlikely) 

    So problem how to I get a TGT for forest-B, as I cannot just as a KDC in forest-B for a Service Ticket by presenting my TGT as it will not be able to decrypt it.

    So, does the KDC in forest-B when presented with a request for a Service Ticket using a TGT from forest-A 'refer' back to the KDC in forest-A (across the secure channel that is the trust) to decrypt and therefore verify the TGT ?

    However if it worked like that, this just proves I am a valid user from forest-A it does not give me a TGT for forest-B at this point.

    In the above scenario the problem with getting a TGT from forest-B is, the KDC in forest-B does not know my UPN password (stringToKey) in order to encrypt a 'session key' (which I will need to further request a Service Ticket latter) 

    problem :)

    I did read a document (more slated towards Linux/MIT kerberos but still v5) that said when you create a Trust between Kerberos realms a 'second and shared' kebtgt account is ceated e.g. kertgt@forest-A&forest-b

    if this second and shared account is created, then is it correct to assume the following
    The KDC TGS (ticket granting service) in forest-A creates a TGT for me for forest-B but this time encrypts the TGT with the password (stringToKey) from the kertgt@forest-A&forest-b  account shared by both forests so I basically end up with two TGT one for my domain and one I can present to a KDC in the other forest?
    if so this would explain how the KDC in forest-B could decrypt the TGT I presented when I am requesting a Service Ticket for an SPN in forest-B
    However, there remains a problem I need a 'session key'  to further communicate with the TGS (ticket granting service, in forest-B) which is normally supplied to me when I get a TGT and encrypted with my UPS password.

    The problem is the KDC in forest-B dose not know my UPN password (as it does not have a copy of the Domain partition, from my domain)

    So event if I can get a TGT to present to KDC in forest-B (as it is encryped as above), How does the KDC in forest-B send me a session key (e.g. encrypted) when it does not know my UPN password to encrypt it with, in which case how can I then go on to request and obtain a Service ticket from this KDC

    Thanks very much, perhaps the directory services engineers (if you are not already one an know the answer) who write AD can answer the above as most of the documents just brush passed this and do not explain it.

    Thanks again

    __AAnotherUser



    AAnotherUser__

    Tuesday, January 24, 2017 11:11 AM
  • Hello Again

    I have done some more reading and discovered answers to about 95% of my questions

    from the documentation at the following URL 

    http://www.zeroshell.org/kerberos/

    where by it explains the following (but there is still one thing missing which I will come to at the end)

    Now let's look at an example to clarify all this. Let's suppose that the user pippo of the realm EXAMPLE.COM, whose associated principal is pippo@EXAMPLE.COM, wishes to access the pluto.test.com server belonging to the TEST.COM realm, via ssh:
    • If Pippo does not already have a TGT in the realm EXAMPLE.COM he makes an initial authentication request (kinit). Obviously, the reply comes from the AS of his realm;
    • He gives the <samp>ssh pippo@pluto.test.com</samp> command which should open the remote shell on pluto.test.com without having to re-enter the password;
    • the ssh client makes two queries to DNS: it works out the IP of pluto.test.com and on the just obtained address carries out the reverse in order to obtain the hostname (FQDN) in canonical form (in this case it coincides with pluto.test.com);
    • ssh client then realizes, thanks to the previous result, that the destination does not belong to the user's realm and thus asks the TGS of the realm EXAMPLE.COM (note that it asks the TGS of its realm for this) for the remote TGT krbtgt/TEST.COM@EXAMPLE.COM;
    • With the remote TGT it asks the TGS of the realm TEST.COM for the host/pluto.test.com@TEST.COM service ticket;
    • When the TEST.COM Ticket Granting Service receives the request, it checks for the existence of the principal krbtgt/TEST.COM@EXAMPLE.COM in its database with which it can verify the trust relationship. If this verification is positive the service ticket (encrypted with the key of host/pluto.test.com@TEST.COM) is finally issued which pippo will send to the host pluto.test.com to obtain the remote shell.

    The above explains how I can present a TGT to the other forest (so question answered on that one)

    However the document does not mention any thing (unless I missed it) about a 'session key' when I can use between me and the SPN in the other forest to exchange data (encrypted with the share session key) once I have gained access via the Service Ticket.

    Now I could use the Diffie–Hellman key exchange protocol in order that both I and the SPN (service) in the other forest end up with the same session key but it does not mention this is the document.

    Can someone please answer my question about the session key (aka shared secret, e.g. symmetric key) 

    Thanks All

    __AAnotherUser


    AAnotherUser__

    Tuesday, January 24, 2017 3:38 PM
  • Actually thinking about it the above example talks about using SSH which uses X509 certificates and therefore can exchange a symmetric key (session key) by going through the usual TLS handshake 

    However what if I was connecting the a SAMBA CIFS share?

    Thanks again

    __AAnotherUser


    AAnotherUser__

    Tuesday, January 24, 2017 3:47 PM
  • I found the answer to my remaining question :)

    watching the video which is a very detailed YouTube Video (link below), it covers both Kerberos forwarding/delegation (aka second hop) and cross-realm and answered the question about the session keys.

    https://www.youtube.com/watch?v=AVH4c-mWnMY

    Thanks

    __AAnotherUser


    AAnotherUser__

    • Marked as answer by AAnotherUser Tuesday, January 24, 2017 5:29 PM
    Tuesday, January 24, 2017 5:29 PM
  • Hi,
    Great share, and it will be greatly helpful to others who have the same question.
    Best regards,
    Wendy

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

    Wednesday, January 25, 2017 1:44 AM
    Moderator