[cifs-protocol] How does constrained delegation work?

Hongwei Sun hongweis at microsoft.com
Wed Jul 22 15:57:05 MDT 2009


Andrew,

   After reviewing the related sections in MS-SFU and MS-PAC, I found that the section 3.1.4.2 (S4U2proxy Message Processing) of MS-SFU provides a description of how S4U_DELEGATION_INFO is generated or populated in PAC.  I will try to answer your questions using the information in the document. If your questions are not interpreted correctly, please clarify and we will continue to work on them.

>1.  How does this get filled out ?

  If service 1 is requesting a service ticket from TGS for service 2 on behalf of the client user,  TGS will populate the S4U_DELEGATION_INFO of PAC in the service ticket for service 2 issued as the response to S4U2Proxy extension TGS request.  The processing logic is:

         -  User's service ticket to service 1 is saved in "additional-tickets" field of S4U2Proxy extension TGS request.
         -  TGS examines PAC of the service ticket saved in "additional-tickets" field for a S4U_DELETION_INFO, if it exists, it will be copied to the                  new PAC, otherwise, a S4U_DELEGATION_INFO structure will be created and added to new PAC.
         -  S4U2ProxyTaget will be the name of service 2, which is the service to be requested.  The name of Service 1 will be added to
            S4UTransitedService list and TransitedListSize will be incremented by 1.
         -  TGS returns the new service ticket for service 2, which now contains the updated S4U_DELEGATION_INFO in PAC,  to service 1.

   Please see 3.1.4.2 and 4.3  of MS-SFU for more details.

>2.  What attribute in the backend data store is used?

  As shown in the previous section, S4U_DELEGATION_INFO is not directly mapped to any AD attributes.  It is created and updated dynamically when TGS request with S4U2Proxy extension is processed.  The name of the service to be requested and the name of the service that delegates the request on behalf of the client are used for updating the structure.

  The AD attribute on the service account related to the processing of S4U2Proxy extension is Allowed-to-Delegate-To(A2D2) (2.182 MS-ADA2 http://msdn.microsoft.com/en-us/library/cc220234(PROT.13).aspx ), which contains the list of services to which the service account can act as a proxy.  TGS uses it to determine if the service 1 can obtain a service ticket for service 2 on behalf of the client user.


>3. how does it get from there to the user's PAC?

  The updated structure S4U_DELEGATION_INFO after TGS has processed S4U2Proxy extension request is stored as a PAC_INFO_BUFFER inside PAC of service ticket for service 2, returned to service 1 on behalf of the user.

   I would like to make sure we have a common understanding of what you meant by "user's PAC". Do you mean the PAC in the user's ticket for service 1, originally sent by the user and subsequently forwarded in "additional-tickets field" of TGS request by service 1? Please clarify, in case the information provided above, along with the documentation, does not sufficiently answer your questions.

  For general information regarding constrained delegation, the following TechNet article is pretty helpful.(http://technet.microsoft.com/en-us/library/cc738207(WS.10).aspx).


Thanks!

--------------------------------------------------------------------
Hongwei  Sun - Sr. Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com
Tel:  469-7757027 x 57027
---------------------------------------------------------------------





-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Thursday, July 16, 2009 10:19 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org; pfif at tridgell.net
Subject: How does constrained delegation work?

I've seen the documentation in MS-SFU and MS-PAC 2.9 (Constrained Delegation Information), but I'm rather unclear:

How does this get filled out?  What attribute in the backend data store is used, and how does it get from there to the user's PAC?

Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.


More information about the cifs-protocol mailing list