Ravindra Pamidi's Blog https://docs.microsoft.com/archive/blogs/ravindrapamidi/feed.xml THOUGHTS FROM A DIRECTORY SERVICES SUPPORT ENGINEER @ MS Wed, 17 Apr 2019 03:33:35 GMT en-US hourly 1 Kerberos fallback to NTLM https://docs.microsoft.com/archive/blogs/ravindrapamidi/kerberos-fallback-to-ntlm Thu, 19 Mar 2009 06:26:00 GMT https://blogs.technet.microsoft.com/ravindrapamidi/2009/03/19/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


 

 

]]> Dcdiag NcSecDesc test failure on Windows 2008 Domain Controllers KB published https://docs.microsoft.com/archive/blogs/ravindrapamidi/dcdiag-ncsecdesc-test-failure-on-windows-2008-domain-controllers-kb-published Wed, 04 Feb 2009 10:41:00 GMT https://blogs.technet.microsoft.com/ravindrapamidi/2009/02/04/dcdiag-ncsecdesc-test-failure-on-windows-2008-domain-controllers-kb-published/ We now have a KB article 967482 published regarding the NcSecDesc error described in my earlier post.

Dcdiag fails for NCSecDesc test on Windows 2008 Domain Controllers
https://support.microsoft.com/default.aspx?scid=kb;EN-US;967482
 

 

]]> Windows Server 2008 Domain Controllers fail NcSecDesc (Naming Context Security Descriptors) test when dcdiag is run https://docs.microsoft.com/archive/blogs/ravindrapamidi/windows-server-2008-domain-controllers-fail-ncsecdesc-naming-context-security-descriptors-test-when-dcdiag-is-run Tue, 14 Oct 2008 19:45:00 GMT https://blogs.technet.microsoft.com/ravindrapamidi/2008/10/14/windows-server-2008-domain-controllers-fail-ncsecdesc-naming-context-security-descriptors-test-when-dcdiag-is-run/

We are increasingly beginning to see customers calling us regarding the following error . I thought it would be best to blog it for benefit of others.

 

Scenario:

 

You have a minimum on one Windows 2008 Domain Controller deployed in a Windows 2003 Domain. When you run dcdiag on or against a Windows Server 2008 domain controller, the Naming Context Security Descriptors  (NcSecDesc) test fails. The test passes for Windows Server 2003 domain controllers in the same domain.

 

 

Starting test: NCSecDesc

        Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have

           Replicating Directory Changes In Filtered Set

        access rights for the naming context:

        DC=DomainDnsZones,DC=CONTOSO,DC=COM

        Error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have

           Replicating Directory Changes In Filtered Set

        access rights for the naming context:

        DC=ForestDnsZones,DC=CONTOSO,DC=COM

        ......................... DC2K8001 failed test NCSecDesc

 

 

 

If you have not run adprep /rodcprep, dcdiag.exe returns an error when it runs the NCSecDesc test. This test checks that the security descriptors on the naming context heads have appropriate permissions for replication. The error indicates that the Enterprise Domain Controllers group does not have Replicating Directory Changes In Filtered Set access rights for the DNS application directory partitions.

 

If you do not plan to add an RODC to the forest, you can disregard this error. If you plan to add an RODC to the forest, you must run adprep /rodcprep.

 

More Information:

 

Known Issues for Installing and Removing AD DS

https://technet.microsoft.com/en-us/library/cc754463.aspx

 

]]>