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