2

I have a webservice that is configured for Windows Authentication. The client code that invokes the WS passes along the credentials to the WS as follows:

myWebService.Credentials = System.Net.CredentialCache.DefaultCredentials;

(my understanding is that this represents the username-password-domain of logged on user).

I am testing configuration issues and confused about how to ensure Kerberos is set.

DETAILS Follow:

I have 2 virtual directories on the same IIS server (one is a "client" with .aspx pages) and the other is the "server" (it hosts a webservice that the client invokes).

My client displays key info about the connecting user via this code:

private string GetUserInfo()
{
    System.Security.Principal.WindowsIdentity UserIdentityInfo;
    StringBuilder msg = new StringBuilder("User Name: ");
    UserIdentityInfo = System.Security.Principal.WindowsIdentity.GetCurrent();
    msg.Append(UserIdentityInfo.Name);
    msg.Append(Environment.NewLine);
    msg.Append(" Token: ");
    msg.Append(UserIdentityInfo.Token.ToString());
    msg.Append(Environment.NewLine);
    msg.Append(" Authenticated: ");
    msg.Append(UserIdentityInfo.AuthenticationType);
    msg.Append(Environment.NewLine);
    msg.Append(" System: ");
    msg.Append(UserIdentityInfo.IsSystem);
    msg.Append(Environment.NewLine);
    msg.Append(" Guest: ");
    msg.Append(UserIdentityInfo.IsGuest);
    msg.Append(Environment.NewLine);
    msg.Append(" Anonymous: ");
    msg.Append(UserIdentityInfo.IsAnonymous);
    msg.Append(Environment.NewLine);
    return msg.ToString();
}

Authentication type is Kerberos when BOTH webclient and the called webservice are on the same server (eg. SERVER1). Actual execution works correctly too.

Authentication type changes to NTLM when this same webclient code in invoked but it now resides on SERVER2. The called webservice still resides on the original server (SERVER1). Actual execution FAILS because the credentials are not correct.

SERVER1 and SERVER2 are on the same local area network (same DOMAIN) and the domain account I use for testing each scenario above is the same (I am in Administrators group on each machine).

How can I configure this so KERBEROS is the authentication type - that is, when this client on SERVER2 is invoked from a browser by "me"?

DaniellaMercuryFan
  • 249
  • 1
  • 7
  • 17

1 Answers1

1

What you have is a classic double hop situation. The graphic in the following post is pretty much your exact situation:

http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx

When both your 'client' and 'service' are on Server1, there is only a 'single hop' to authenticate the user. When you introduced Server2 into the mix, you now have the double hop where authentication is now delegated.

Since you are running your app pools as a domain account, you will need to setup service principal names (SPNs) in order to prevent the double hop. There are resources mentioned in the post above. There is mention of it in this article as well:

http://msdn.microsoft.com/en-us/library/ff649309.aspx

A SPN will need to be created for the specific user account, service, and host name. This needs to be done on the domain controller.

Rob
  • 931
  • 6
  • 10
  • Thank you. As I understand it, Server1 (hosting the called webservice) must be configured for delegation in the Active Directory so that when it tries to connect to the database server (Server3) it will be allowed to do so. PLEASE NOTE: I checked the Application Pool IDENTITY for the called webservice (on Server1) and discovered it set to a "predefined" Network Service account (rather than a domain account as you assumed). Is this significant? – DaniellaMercuryFan May 16 '11 at 22:21
  • Have a look at the following information for help in troubleshooting Kerberos issues: http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx. Having the app pool set as the Network Service account might make things a little easier. Depending on how you are accessing the IIS site, if you are using the actual computer name as your URL, it might just be a matter of setting the account in AD to allow delegation. – Rob May 17 '11 at 02:19