Central Admin and Kerberos

  • Article

I recently came across a problem with trying to use Kerberos for Central Administration Virtual Server/Web Application/IIS Web Site. In short here is the problem:

Symptoms: Unable to get to Central Admin with 401.2

Troubleshooting: Machine name = SpServer, App Pool Identity= SPServiceAcct, Domain= Contoso

  • Used ADSUTIL to check the NTAuthenticationProviders metabase key for the Central Admin WebApp. It was set to "Negotiate, NTLM"
  • Ran SetSPN –L on the Application Pool Identity SpServiceAcct (NT account). This revealed that we had http/SPServer:<centraladminport> and http/SPServer.Contoso.com:<centraladminport>.
  • Ran SetSPN –L on the SPServer account. This revealed that we had the expected HOST/SPServer and HOST/SPServer.Contoso.com records.
  • Checked the Event Viewer for errors. Kerberos was reporting a duplicate registration.
    • Deleted SPN for http/SPServer:<centraladminport> and http/SPServer.Contoso.com:<centraladminport> from the Contoso\SPServer account.

Root Cause: Registration of SPN for Central Admin caused a duplicate. Integrated authentication failed to fall back to NTLM since our target service had a valid registered Kerberos entry point.

 

Why did this happen? To paraphrase a KB on ASP.NET…

If multiple Web sites are reached by the same URL but on different ports, Kerberos will not work. To make this work, you must use different hostnames and different SPNs. When Internet Explorer requests either https://www.Contoso.com or https://www.Contoso.com:81, Internet Explorer requests a ticket for SPN HTTP/www.contoso.com. Internet Explorer doesn't add the port or the virtual server/Web Application to the SPN request. This behavior is the same for https://www.contoso.com/app1 or https://www.contoso.com/app2. In this scenario, Internet Explorer will request a ticket for SPN https://www.Contoso.com from the Key Distribution Center (KDC). Each SPN can be declared only for one identity. Therefore, you would also receive a KRB_DUPLICATE_SPN error message if you try to declare this SPN for each identity.

 

There are built-in SPNs that are registered for computer accounts. These SPNs are recognized for computer accounts if the computer has a HOST SPN. The Troubleshooting Kerberos Delegation white paper, Table 1   Built-in SPNs Recognized for Computer Accounts explains this very well. By adding the registration on the App Pool Identity account it created a duplicate because by default we would map HOST/SPServer to HTTP/SPServer regardless of port.

Ok, back to WSSv3/MOSS upgrade…