通过

Central Admin and Kerberos

  • 项目

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…

Comments

  • Anonymous
    October 17, 2006
    So is the implications of this mean that for kerberos enabled iis virtual servers (or web applications to use the new parlance) we have to make sure that each site has a unique hostname and can't rely on port numbers to distinguish between sites?
  • Anonymous
    October 27, 2006
    No that's not really the case. It's more about the accounts used and the SPN's created for those URLs.In general SharePoint managed paths are going to start at the same URL (especially load balanced URLs) and this gets registered on the App Pool Account SPN. The implication here is if the URL is going to contain multiple Web Applications running under mulitple accounts.
  • Anonymous
    June 12, 2009
    PingBack from http://menopausereliefsite.info/story.php?id=1893
  • Anonymous
    October 18, 2011
    Do you meanDeleted SPN for http/SPServer:<centraladminport> and http/SPServer.Contoso.com:<centraladminport> from the ContosoSPServiceAcct account.?