2

I've noticed that there is an option to set "Trust this user for delegation to any service" that can be set for service users. I've read a lot about unconstrained delegation with regards to computers but haven't seen users mentioned anywhere.

Can anyone clarify what this does compared to setting this for a computer? I understand that with a computer, say a web app, the server could use any user's ticket that connects to it and delegate it to the DB server or any other server (when talking about unconstrained delegation).

But what happens in the context of a user having this same right? Can the user just request any user's ticket and delegate it? How does the user get access to the tickets in the first place and what is needed to impersonate the other users? Just an exported TGT ticket?

Thanks a lot!

Improve this question

2 Answers 2

Reset to default
1

When you do Kerberos Constrained Delegation (or anything pre-Resource-Based Delegation) on Windows, you assign delegation rights to the identity of the process accepting the kerberos tickets from the inbound hop.

So in short, if the process is running as a domain user, that user needs delegation enabled. If it's running as a System-type identity, the computer does. But you should always Constrain delegation, or use the newer Resource-Based Delegation model (where instead of identifying back-end SPNs, you identify front-end Identities allowed to delegate to the target service identity from the target service identity).

Unconstrained delegation is a bad idea - it might best be considered a stopgap solution in Windows 2000 which gained constraints quickly in Windows Server 2003. It allows impersonation of any qualifying service principal (read: User or computer) to another service, with no restrictions. Get someone's ticket, do anything they can do - so control of a service set with unconstrained delegation meant control of any connecting user.

For IIS Web Applications, that generally means the App Pool Account - the base (non-client-impersonating) identity of the w3wp.exe processes associated with that App Pool. If the app pool is running as LocalSystem (don't do that), Local Service, Network Service or ApplicationPoolIdentity, then the identity used for decoding Kerb tickets and delegation is the computer account. (Couple of other caveats there like UseAppPoolCredential=true or UseKernelMode=false might also cause a non-custom user identity to be used to try to decode a ticket, but that's out of scope.)

Any Security Principal can be assigned delegation rights. Giving any User object a Service Principal Name (SPN - use SetSPN.exe), which computers have by default (HOST/computername) will enable the Delegation tab in DSA.msc.

One exception to the above is Group Managed Service Accounts (gMSAs), which should be your first choice for any new service which uses a Domain identity to run a service, as it self-manages its complex password, preventing easy long-term-password attacks on the account itself.

Improve this answer
0

Specifically it's intended for User accounts that are used as service accounts, instead of using a computer account.

Improve this answer
1
  • I understand that, as regular users are not allowed Delegation rights (from what I can see). But how would the service account interact with any user tickets? Would the service account have to run the webapp or whatever, and then it could pass tickets forward?
    – ptr0x01
    Commented Oct 18, 2018 at 8:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .