Kerberos authentication fails – The local machine must be a Kerberos KDC (domain controller) and it is not
Posted On March 13, 2019
This issue is not particular to SharePoint, but that’s how I came across it, so I’ll present it that way. However, keep in mind that you could see this behavior for any IIS site using Kerberos.
Users are unable to authenticate via Kerberos (Negotiate). They try to access a site and get prompted for credentials three times before it fails.
Another variation of the issue is that the user gets prompted for credentials once (which they don’t expect), and are allowed access to the site after entering them. When checking a Fiddler trace or the Security Event Log on the web-front-end (WFE), we see that NTLM was used instead of Kerberos.
The Secure Channel (the channel between the SharePoint server and Domain Controller (DC)) may be pointed to a DC where the “Kerberos Key Distribution Center” service is stopped or malfunctioning.
Verify which DC your SharePoint server is connected to. You can use NLTest /SCVerify for that. The DC will be listed as the “Trusted DC Name”
Example: NLTest /SC_Verify:CONTOSO.COM
Log on to the identified DC, open services.msc, and verify that the “Kerberos Key Distribution Center” service is started.
If it’s already started, restart it. It may also help reboot the DC.
Another option is to manually switch the Secure Channel connection to a different DC.
First run NLTest /DSGetDC command to verify the AD “Site” the SharePoint server is in.
Example: NLTest /DSGETDC:CONTOSO.COM
Then run NLTest /DCList to get a list of DCs for the domain. It will also list the AD “Site” each DC is in.
Example: NLTest /DSLIST:CONTOSO.COM
Then run NLTest /SC_Reset to point the SharePoint server at a new DC. Ideally, you’d pick a DC that is in the same AD “Site”. If one does not exist, you can pick a different DC from a different “Site”.
Example: NLTest /SC_Reset:CONTOSO.COM\DC1.contoso.com
Here are some examples of errors you’ll see:
In the Security event log on the WFE:
Log Name: Security
Event ID: 4625
Task Category: Logon
Keywords: Audit Failure
An account failed to log on.
Security ID: NULL SID
Account Name: –
Account Domain: –
Logon ID: 0x0
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: User1
Account Domain: Contoso.com
Failure Reason: An Error occured during Logon.
Sub Status: 0x0
Caller Process ID: 0x0
Caller Process Name: –
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: –
Package Name (NTLM only): –
Key Length: 0
— The Key here is the status code: 0xC00002F5
And in the IIS log on the WFE:
2019-03-06 16:12:09 10.226.63.256 GET / – 80 – 10.68.256.64 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729) – 401 1 2148074297 15
— The key here is the value for sc-win32-status on the 401.1 response: 2148074297
If you look either of those values (0xC00002F5 and 2148074297) up, you’ll see the same error message:
The local machine must be a Kerberos KDC (domain controller) and it is not.