Ravindra Pamidi's Blog

THOUGHTS FROM A DIRECTORY SERVICES SUPPORT ENGINEER @ MS

Kerberos fallback to NTLM

Kerberos fallback to NTLM

  • Comments 3
  • Likes

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
  • 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?

  • 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

  • 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

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment