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.

 

Problem:

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.

 
 

Cause:

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.

 
 

Resolution:

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

Source: Microsoft-Windows-Security-Auditing

Event ID: 4625

Task Category: Logon

Level: Information

Keywords: Audit Failure

User: N/A

Computer: WFE.contoso.com

Description:

An account failed to log on.

Subject:

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 Information:

Failure Reason: An Error occured during Logon.

Status: 0xC00002F5

Sub Status: 0x0

Process Information:

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:

SEC_E_MUST_BE_KDC

The local machine must be a Kerberos KDC (domain controller) and it is not.