none
S4U2SELF and 2 way trust. RRS feed

  • Question

  • I read in some of the forums that a 2 way trust is required for the S4U2SELF to work.

    For .e.g. if I have an environment where I have 2 forests.

    Forest 1 -----> Domain A

    Forest 2 -----> Domain B

    and there is a one way outgoing trust between the Domain A and Domain B.  Because of the trust Domain B users can access the resources in Domain A but not the vice versa.

    Can I use the S4U2Self in this environment where the service is part of domain A and is trying to impersonate the Users from Domain B?

    Wednesday, September 16, 2009 10:50 PM

Answers

  • When Service 1 in Domain A requests a service ticket to itself on behalf of a user from Domain B, Service 1 receives the user's authorization data in the ticket from the KDC in domain B, technically in the privilege account certificate (PAC) of the service ticket.

    By reading the MS-SFU specification (see references below), my understanding is that, for your S4U2SELF to work, you need a two-way trust between the domains.

    In a cross forest environment, the user and the service are in separate domains, and belong to different realms. In case there is not a two-way forest trust, you need to establish the required trust relationships to allow any required referrals to propagate.

    The extent you create your two-way trust depends on the functional levels of the forest and the domains involved.

    Please note that this forum handles issues related to the Windows Open Specifications. If you have clarification, correction assistance, or interoperability issues regarding the documentation, this forum is the right place, and we will be happy to assist you.

    If you have setup, configuration, or general questions on this topic, I suggest the following TechNet resource.

    Discussion on Windows Server Active Directory services

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/threads

     

    References:

    [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification

    http://msdn.microsoft.com/en-us/library/cc246071.aspx

    1.3.3   Protocol Overview

    Figure 2: S4U2self and S4U2proxy

    1.4   Relationship to Other Protocols

    [MS-PAC]: Privilege Attribute Certificate Data Structure 

    http://msdn.microsoft.com/en-us/library/cc237917.aspx

     

    Regards,

    Edgar

    Friday, September 18, 2009 5:25 PM
    Moderator
  • The following references provide in-depth details that may help understand an S4U2Self scenario where the user’s account is in a different realm than the service.

    [MS-SFU] 3.1.4.1.1   Using the User's Realm and User Name to Identify the User

    [MS-SFU] 4.2 S4U2self Multiple Realm Example

    [MS-PAC] 4.2.2   SID Filtering

    [RFC4120] 1.2 Cross-Realm Operation

     

    I hope this helps.

     

    Regards,

    Edgar

    Monday, September 21, 2009 10:06 PM
    Moderator

All replies

  • sami77,

    One of our engineers will be following up with you shortly in regards to your question.

    Dominic Salemno
    Senior Support Escalation Engineer
    Thursday, September 17, 2009 2:35 PM
  • When Service 1 in Domain A requests a service ticket to itself on behalf of a user from Domain B, Service 1 receives the user's authorization data in the ticket from the KDC in domain B, technically in the privilege account certificate (PAC) of the service ticket.

    By reading the MS-SFU specification (see references below), my understanding is that, for your S4U2SELF to work, you need a two-way trust between the domains.

    In a cross forest environment, the user and the service are in separate domains, and belong to different realms. In case there is not a two-way forest trust, you need to establish the required trust relationships to allow any required referrals to propagate.

    The extent you create your two-way trust depends on the functional levels of the forest and the domains involved.

    Please note that this forum handles issues related to the Windows Open Specifications. If you have clarification, correction assistance, or interoperability issues regarding the documentation, this forum is the right place, and we will be happy to assist you.

    If you have setup, configuration, or general questions on this topic, I suggest the following TechNet resource.

    Discussion on Windows Server Active Directory services

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/threads

     

    References:

    [MS-SFU]: Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification

    http://msdn.microsoft.com/en-us/library/cc246071.aspx

    1.3.3   Protocol Overview

    Figure 2: S4U2self and S4U2proxy

    1.4   Relationship to Other Protocols

    [MS-PAC]: Privilege Attribute Certificate Data Structure 

    http://msdn.microsoft.com/en-us/library/cc237917.aspx

     

    Regards,

    Edgar

    Friday, September 18, 2009 5:25 PM
    Moderator
  • But no where in the "Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol Specification"  its been mentioned that a two-way trust is required. If this is a requirement that the document should explicitly state this and also provide details about why it needs a two-way trust. 

    I have spent a lot of time trying to setup the environment and figure out that this configuration will work only in a two-way environment.

    Anyways thanks for the information.


    Friday, September 18, 2009 10:10 PM
  • The following references provide in-depth details that may help understand an S4U2Self scenario where the user’s account is in a different realm than the service.

    [MS-SFU] 3.1.4.1.1   Using the User's Realm and User Name to Identify the User

    [MS-SFU] 4.2 S4U2self Multiple Realm Example

    [MS-PAC] 4.2.2   SID Filtering

    [RFC4120] 1.2 Cross-Realm Operation

     

    I hope this helps.

     

    Regards,

    Edgar

    Monday, September 21, 2009 10:06 PM
    Moderator