Delegation with S4U or How to use S4U to impersonate a user on a remote server?

[Borislav Marinov]

How to use S4U to impersonate a user on a remote server (delegation)
In an Active Directory domain (2003), I have the following setup:
A Client computer, an application computer, one or more backend servers
and a domain controller.
The user connects (remotely) to the application running on the
application computer.
The Application uses Services 4 user (S4U) to obtain an delegation
token for the user {LsaConnectUntrusted +
LsaLookupAuthenticationPackage(Kerberos) +
InitializeLSAString(KerbS4ULogon)}. I am using the same code as the one
by Keith Brown (MSDN Magazine > April 2003 or
http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs/default.aspx?fig=true#fig1).
I am able to obtain an impersonation token when running as a local
system but I was unable to obtain a delegation token this way. With
this token I can impersonate the user on the application machine but
not on the backend servers.
I NEED TO BE ABLE TO IMPERSONATE THE USER ON THE BACK-END SERVERS.
I did setup the AD to trust the application server and since I am able
to impersonate the user locally (on the application machine) obviously
the user allows delegation as well.
Am I missing some AD parameterization or this is not the way to obtain
a delegation token?
Thanks a lot,
Bobby Marinov

 

[Joe Kaplan \(MVP - ADSI\)]

You need to configure the application server to be authorized for
constrained delegation to the backend servers in question. Note that
because you use S4U on the middle tier, you need to make sure the "use any
protocol" radio button is selected in AD U&C. This enables tokens created
by S4U to be delegated.

Joe K.

 

[Borislav Marinov]

I am still getting an "Impersonation" token instead of
"Delegation" token.
Here is my process token before and the impersonation token produced by
this process (note that the impersonation level on the second one IS
NOT DELEGATION):
============= Original Process Token ===========
Token: 0x00000090, PID: 0x00000550, TID: 0x00000d1c
User: 'svctest@KERBEROS', ATTR:0x00000000
Token type: TokenPrimary
Session ID - token:0x00000000, Process:0x00000000
Privilegues :
SeTcbPrivilege :
SeCreateTokenPrivilege :
SeAssignPrimaryTokenPrivilege :
SeIncreaseQuotaPrivilege :
SeImpersonatePrivilege : Enabled DfltEnabled
SeEnableDelegationPrivilege :
SeChangeNotifyPrivilege : Enabled DfltEnabled
SeSecurityPrivilege :
SeBackupPrivilege :
SeRestorePrivilege :
SeSystemtimePrivilege :
SeShutdownPrivilege :
SeRemoteShutdownPrivilege :
SeTakeOwnershipPrivilege :
SeDebugPrivilege :
SeSystemEnvironmentPrivilege :
SeSystemProfilePrivilege :
SeProfileSingleProcessPrivilege :
SeIncreaseBasePriorityPrivilege :
SeLoadDriverPrivilege :
SeCreatePagefilePrivilege :
SeUndockPrivilege :
SeManageVolumePrivilege :
SeCreateGlobalPrivilege : Enabled DfltEnabled
SeMachineAccountPrivilege :

============= Impersonation Token ===========
Token: 0x000000a4, PID: 0x00000550, TID: 0x00000d1c
User: 'testsvc@KERBEROS', ATTR:0x00000000
Token type: TokenImpersonation
Session ID - token:0x00000000, Process:0x00000000
ImpersonationLvl: SecurityImpersonation
Privilegues :
SeTcbPrivilege : Enabled DfltEnabled
SeCreateTokenPrivilege : Enabled DfltEnabled
SeAssignPrimaryTokenPrivilege : Enabled DfltEnabled
SeImpersonatePrivilege : Enabled DfltEnabled
SeEnableDelegationPrivilege : Enabled DfltEnabled
SeChangeNotifyPrivilege : Enabled DfltEnabled
SeMachineAccountPrivilege : Enabled DfltEnabled

 

[Borislav Marinov]

Sorry,
The original process token above actually have
"SeEnableDelegationPrivilege" and "SeTcbPrivilege" enabled. I
did cut and paste an earlier version of the process token.
(I am manually enabling those privileges right before obtaining the
impersonation token)

 

[Joe Kaplan \(MVP - ADSI\)]

I'm not actually sure that is telling you that you can't delegate. If the
kerb ticket is forwardable and the service process has rights to delegate to
the target service using any protocol in AD, then it should work.

The ticket should have forwardable set unless the account in question is set
as "sensitive and cannot be delegated".

Joe K.

 

[Dominick Baier [DevelopMentor]]

Hello Joe,

from keith:

If you're using KERBTRAY.EXE to view the client's tickets, note that under
constrained delegation, the Web server's ticket won't be marked ok-as-delegate.
This is because constrained delegation works very differently from normal
Kerberos TGT forwarding, which is what happens when you use the Windows 2000-compatible
delegation option. Under constrained delegation, the client does not forward
its TGT to the server, because that would allow the server to use those credentials
anywhere on the network. Instead, the client just performs a normal Kerberos
handshake with the Web server, and the Web server uses a special extension
to Kerberos called S4U2Proxy to obtain a ticket to the back end on the client's
behalf.

 

[Joe Kaplan \(MVP - ADSI\)]

Ok, so does that mean then that the token he generates with S4U should have
a token impersonation level of "impersonate" or "delegation"? I think it is
the former in this case, but it is still not quite clear to me.

Thanks,

Joe K.

 

[Dominick Baier [DevelopMentor]]

Hello Joe,

the former. AFAIK

 

[Borislav Marinov]

So how can I generate a delegation token using "S4U2Proxy" without been
a WEB service?
How does MS IIS do it?

 

[Dominick Baier [DevelopMentor]]

Hello Borislav,

just use the overload of the WindowsIdentity ctor that thake a upn (string).