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  http://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


http://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 (3)

  1. ravindrapamidi says:

    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

    Ravindra

  2. ML49448 says:

    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?

  3. Neeraj says:

    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