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
[email protected]
Tel:  469-7757027 x 57027
---------------------------------------------------------------------





-----Original Message-----
From: Andrew Bartlett [mailto:[email protected]]
Sent: Thursday, July 16, 2009 10:19 PM
To: Interoperability Documentation Help
Cc: [email protected]; [email protected]
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.
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol

Reply via email to