Kerberos fallback to NTLM
Scenario: Case where NTLM is chosen instead of Kerberos as the authentication protocol and how SPNego Logging was used to trace the source of the problem.
Environment: Windows Server 2008 / IIS 7.0 / SharePoint 2007 all running on the same server.
All the App pools on IIS are running under the identity of a single service account which is part of apac.contoso.com domain where the IIS webserver is located.
FQDN of Web server: Websrv1.apac.contoso.com
The default website on IIS server is configured to use Negotiate and NTLM as the authentication providers.
We observed that NTLM is chosen as the authentication protocol on the network trace taken while accessing IIS website using NetBIOS name https://websrv1/ from a Windows Vista SP1 Client that is located in na.fabrikam.com domain.
From the trace we see the following:
1) The client does an HTTP GET request to the IIS website
2) Server responds with a HTTP 401 unauthorized message along with www-authenticate header specifying Negotiate and NTLM
3) Client chooses NTLM instead of Kerberos and the authentication succeeds over NTLM.
NTLM was later removed from the authentication providers of the IIS website, but this did not change the behavior on the client end.
In order to check why the client is choosing NTLM, we have enabled SPNEGO logging on the Windows Vista SP1 client and then reproduced the problem after flushing Kerberos ticket cache.
I am pasting the relevant portion of the Log file where it fails on Kerberos and fall backs to NTLM:
=========================
688.340> SPM-Neg: WLsaInitContext( HTTP/websrv1.na.fabrikam.com, Kerberos ) returned c000018b
688.340> SPM-Neg: Failed c000018b getting token from preferred package 'Kerberos'
688.340> SPM-Neg: Status code c000018b causing us to continue
688.340> SPM-Neg: Getting initial token from preferred package 'Kerberos'
688.340> SPM-Neg: WLsaInitContext( HTTP/websrv1.na.fabrikam.com, Kerberos ) returned c000018b
688.340> SPM-Neg: Failed c000018b getting token from preferred package 'Kerberos'
688.340> SPM-Neg: Status code c000018b causing us to continue
688.340> SPM-Neg: Dropping back to pure NTLM
688.340> SPM-Neg: Getting initial token from preferred package 'NTLM'
688.340> SPM-WAPI: [f30] WLsaInitContext(0027D9D8 : 00000002, 00000000 : 00000000, HTTP/websrv1.na.fabrikam.com)
688.340> SPM-Verbose: Context Req = 0x00010003
688.768> SPM-WAPI: LpcServer: Received msg from f30.159c
688.340> SPM-Verbose: Package = NTLM
688.6136> SPM-WAPI: [f30.159c] Dispatching API (Message 525c)
688.6136> SPM-Trace: [f30] LpcDispatch: dispatching GetUserName (1a)
688.340> SPM-WAPI: InitResult = 90312
688.340> SPM-Verbose: Flags = 00010002
688.340> SPM-WAPI: Init New Context = 01539B50 : 00000002 to session 0190D978
688.340> SPM-Neg: WLsaInitContext( HTTP/websrv1.na.fabrikam.com, NTLM ) returned 90312
=====================================================
The status code c000018b translates to STATUS_NO_TRUST_SAM_ACCOUNT
D:\Tools\Err>err c000018b
# for hex 0xc000018b / decimal -1073741429 :
STATUS_NO_TRUST_SAM_ACCOUNT ntstatus.h
# The SAM database on the Windows Server does not have a
# computer account for this workstation trust relationship.
# 1 matches found for "c000018b"
In the above the log the Client tries to establish a security context between itself and the remote server by calling the InitializeSecurityContext function. This function should return a token that the client passes to the remote peer.
It fails with error STATUS_NO_TRUST_SAM_ACCOUNT, this is because the SPN HTTP/websrv1.na.fabrikam.com does not exist in Active Directory. In this case the SPN constructed is wrong, the correct SPN should be HTTP/websrv1.apac.contoso.com and thus the client falls back to NTLM.
Fixing the name resolution problem by appending the correct DNS name suffix when a NetBIOS name is used resolves the issue.
More Information:
InitializeSecurityContext (General) Function
https://msdn.microsoft.com/en-us/library/aa375506(VS.85).aspx
Steps to enable SPNego Logging:
Save the below text with .reg file extension and then execute the file to import its contents into registry. This would create lsass.log file under %windir%\system32 directory.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"SPMInfoLevel"=dword:0000101F
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LogToFile"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos]
"LogToFile"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"LogToFile"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"LogLevel"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos]
"LogLevel"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\]
"NegEventMask"=dword:0000000F
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"LogLevel"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos]
"LogLevel"=dword:00000001
Comments
Anonymous
January 01, 2003
Hi Michael Glad that helped. The SPNego logging listed in the article works on Vista/ Windows 7 / Windows 20008 / Windows 2008 R2. If i remember it correct you would need a checked build of lsasrv.dll for xp. Cheers RavindraAnonymous
October 27, 2009
Thanks for the information - this was just what I needed. I am tracing a similar problem, but on windows XP clients - do you know if these registry key settings are supported on Win XP, as I can't seem to get the logging working on that version. Works on Vista though?Anonymous
January 07, 2010
Thanks Ravinder for the settings to enable SPNego logging, can you please let us know how to disable it again. I forgot to take registry backup before merging it. Also is there any way to enable this on Windows XP. Thanks, Neeraj