Confusion about Kerberos, delegation and SPNs.

Question

I'm trying to write a proof-of-concept application that performs Kerberos delegation. I've written all the code, and it seems to working (I'm authenticating fine), but the resulting security context doesn't have the ISC_REQ_DELEGATE flag set.

So I'm thinking that maybe one of the endpoints (client or server) is forbidden to delegate. However I'm not authenticating against an SPN. Just one domain user against another domain user. As the SPN for InitializeSecurityContext() I'm passing "[email protected]" (which is the user account under which the server application is running). As I understand, domain users have delegation enabled by default. Anyway, I asked the admin to check, and the "account is sensitive and cannot be delegated" checkbox is off.

I know that if my server was running as a NETWORK SERVICE and I used an SPN to connect to it, then I'd need the computer account in AD to have the "Trust computer for delegation" checkbox checked (off by default), but... this is not the case, right? Or is it?

Also - when the checkbox in the computer account is set, do the changes take place immediately, or must I reboot the server PC or wait for a while?

Answer 1

According to this ISC_REQ_DELEGATE is only ignored if you use constrained delegation. I'm pretty sure for constrained delegation to happen, you have to explicitly state which services the account is allowed to delegate to in Active Directory (delegation tab for a user or computer in the AD snap in).

I'm not sure of the rules using UPNs vs SPNs. Have you tried turning on Kerberos event logging and looking in the event log? The messages are often cryptic but usually possible to decipher.

Your description of the NETWORK SERVICE scenario is accurate. Trust for delegation is off by default, but NETWORK SERVICE might have permission to self register an SPN (I think this can be determined by group policy).

When you tick the box the change takes place immediately, but may have to propogate throughout all the domain controllers in the domain (I typically test in a test domain with a single DC). So, restarting your service app is enough, you don't need to reboot.

The Kerb tickets reside on the client machine. These have an expiry time, and can be flushed manually using klist or kerbtray.