WCF:Relationship between NetworkCredential and Impersonation

Question

I have a WCF service hosted in IIS 7 in the default app pool in Integrated mode with anonymous access disabled and windows Authentication enabled.

I have put the following attribute on the method implementation for my interface.

[OperationBehavior(Impersonation = ImpersonationOption.Required)]

If I do not supply network credentials in the call to my service I get the expected behavior in that the following are true:

ServiceSecurityContext.Current.WindowsIdentity.Name = myDomain\myUser
ServiceSecurityContext.Current.PrimaryIdentity.Name = myDomain\myUser
Thread.CurrentPrincipal.Identity.Name = myDomain\myUser
I can connect to a database on a remote system using SSPI and myDomain\myUser authentication.
WindowsIdentity.GetCurrent().Name = myDomain\myUser
I can use Thread.CurrentPrincipal.IsInRole() to verify the user is in a role.
I can use WindowsIdentity.GetCurrent().Groups to retrieve a list of groups for the user.

But if I supply network credentials using the following:

var networkCredential = new NetworkCredential(user, pwd, dom);
base.ClientCredentials.Windows.ClientCredential = networkCredential;
base.ClientCredentials.Windows.AllowNtlm = true;      
base.ClientCredentials.Windows.AllowedImpersonationLevel 
          = System.Security.Principal.TokenImpersonationLevel.Delegation;

Then all of the above is the same EXCEPT the database connection and two of the groups listed are different. The connection to the database is being made using the NT Authority\Anonymous login user. Using the NetworkCredentials puts the user in the NT Authority\Network group rather than NT Authority\Interactive and additionally the LOCAL group is removed.

My goal is to make the connection to the database using the credentials passed by NetworkCredential, any advice would be appreciated.

Shane Holder

Answer 1

Sounds like typical double-hop issues.

I am guessing in your working scenario that Kerberos is getting used by default which will get you a Delegation token on the remote server.

In the second scenario it is not using Kerberos because of the supplied user/pass and that does not support getting a Delegation token.

The only other way to get a Delegation token on the remote server that I am aware of is to use Basic Authentication (with SSL), a complete pain.

Concerning the credentials double hop issue