Enabling Kerberos Delegation on a NLB scenario

  • Article

 

Most common support incidents we come across is the kerberos delegation issues. So I would like to list down the steps that need to followed for configuring IIS for the kerberos delegation.

General steps to be followed on the IIS machine

Make sure that NTAuthenticationProviders is set to "Negotiate,NTLM"

c:\inetpub\adminscripts> cscript.exe adsutil set w3svc/ntauthenticationproviders "Negotiate, NTLM"

  • The next step is to set the IIS servers for delegation

In the active directory, Check the "Trust Computer for delegation"

  • Make sure that you have enabled only "Windows Integrated Authentication" in IIS

If it is an Network Load Balanced environment, we need to run the website under an App pool running with domain user account.  

  • The domain user account should be trusted for delegation in the AD
  • Double check this one in the Active Directory Users and Computers.
  • The domain user account should be a part of IIS node’s IIS_WPG group

What are the SPNs you need to set?

For normal scenario when AppPool running under NETWORK SERVICE, there are no SPNs need to be set. But when you run the AppPool under Domain Account for some reason, make sure that you have that domain user account in the local IIS_WPG group and set the following SPNs.

  • SETSPN -A HTTP/SERVERNAME <Domain User Account>
  • SETSPN - A HTTP/FQDN <Domain User Account>

If you have a Network Load Balanced environment (Software or Hardware), you need to set SPNs for the NLB or cluster name instead of the individual server names. We also want to run the AppPool under a domain user account.

  • SETSPN -A HTTP/<NetBIOS name of the LB> <Domain user account>
  • SETSPN -A HTTP/<FQDN of the LB> <Domain user account>

We also need to make sure that we do NOT have SPN entries set for HTTP/<FQDN>  <iis computer-name> for any of the IIS nodes.

Why we want to run AppPool under Domain User Account in an NLB environment?

We should not run AppPools under NETWORK SERVICE account in an NLB scenario. The reason is NETWORK SERVICE is a local account and that will be having a different SID on the IIS machines. Since we don't know to which server the request will be going, we need a common user account which will basically delegating the credentials. So, we go for a common domain user account which is basically trusted for delegation and also it is a member of local IIS_WPG group.

Simplified Kerberos Checklist

IE-IIS-Share {All using default accounts (NETWORK SERVICE)}

IE:

  • Add the url to "Local Intranet Zone"
  •  Enable Windows Integrated Authentication
  • Automatic logon with current username and password

IIS:

Only "Windows Integrated Authentication" is checked.

CIFS/Share:

  • The content folder must have privileges as per KB 812614

SPN:

  • If IIS is on DC, SPNs are not required
  • If IIS is not on DC:
    • HTTP/<computer-name> <iis-computer-name>
    • HTTP/<FQDN> <iis computer-name>

IE-IIS-Share {App Pool running under Domain account}

Domain account configuration:

  • Account is trusted for delegation
  • Is a member of IIS_WPG group on the local IIS computer
  • Has "Act as a part of Operating System"/"Impersonate a client after authentication" privileges.

IE:

  • Add the url to "Local Intranet Zone"
  • Enable Windows Integrated Authentication
  • Automatic logon with current username and password

IIS:

  • Only "Windows Integrated Authentication" is checked.

CIFS/Share:

  • The content folder must have privileges as per KB 812614

SPN:

  • If IIS is on DC: 
    • Add the following:
      • HTTP/<computer-name> <domain user account>
      • HTTP/<FQDN> <domain user account>
    • Remove the following:
      • HTTP/<computer-name>:<port> <iis-computer-name>
      • HTTP/<FQDN> <iis-computer-name>
  • If IIS is not on DC: 
    • Add the following:
      • HTTP/<computer-name> <domain user account>
      • HTTP/<FQDN> <domain user account>

Knowledge Base Articles

1. HOW TO: Troubleshoot Kerberos-Related Issues in IIS - https://support.microsoft.com/?id=326985

2. You receive an "HTTP Error 401.1 - Unauthorized: Access is denied due to invalid credentials" error message when you try to access a Web site that is part of an IIS 6.0 application pool - https://support.microsoft.com/?id=871179