Delegation after impersonation

[vladimir-sironja]

Hello,

I have been using the NSSPI lib succesfully to exchange keys invoking server's AcceptToken() until SspiCommon.Status.Ok state reached.

Upon that, I invoke ImpersonateClient() and try to delgate this security context further via WCF (httpTransport.AuthenticationScheme = AuthenticationSchemes.Negotiate;)
DC/Kerberos are all set up, all users have been granted domain Admin priviledges, all users have SPNs so that delegation can be enabled, all computers have delegations enabled.

However, when I invoke WindowsIdentity.GetCurrent().ImpersonationLevel from within Impersonation block I get "Identification" only.

Both server and client context required:
ContextAttrib.MutualAuth |
ContextAttrib.AcceptIdentify |
ContextAttrib.Confidentiality |
ContextAttrib.ReplayDetect |
ContextAttrib.SequenceDetect |
ContextAttrib.Delegate,

Any ideas? Can this work at all? Do I have to dive into SPN management to get this running?

Thanks
Vladimir

[vladimir-sironja]

I am now comparing final context-attribs against required in ServerContext.AcceptToken() upon SecurityStatus.OK and they differ.
I am short on MutualAuth, Confidiality and Delegate.
I am also unable to wireshark any Kerberos activity during ServerContext.AcceptToken() and ClientContext.Init() ping-pong.
Ideas?

[vladimir-sironja]

Ok, ClientContext has to be initialized with a valid SPN from DC, now at least TGS-REQ/TGS-REPs fly around, even though still no delegation wish noted in flags section of a TGS-REQ.