nsspi icon indicating copy to clipboard operation
nsspi copied to clipboard

Delegation after impersonation

Open vladimir-sironja opened this issue 6 years ago • 2 comments

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 avatar Oct 30 '19 08:10 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 avatar Oct 31 '19 11:10 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.

vladimir-sironja avatar Oct 31 '19 16:10 vladimir-sironja