Active Directory Migration

Kerberos Authentication Fails across an External Domain Trust when NTLM is Disabled (SID-History Troubleshooting)

When migrating Active Directory users with SID-History, users may successfully authenticate but still be unable to access resources located in the trusted source domain.

In our lab environment, Kerberos authentication appeared to work correctly at first glance. Cross-realm Kerberos tickets could be obtained successfully, the external domain trust was healthy, and SID filtering had been disabled. Nevertheless, Windows was unable to obtain the required Kerberos service ticket for the target file server. As a result, Windows fell back to NTLM authentication. Because NTLM was disabled, access failed.

This article explains how to identify this situation and one possible resolution.

Symptoms

A migrated user successfully authenticates to the target domain.

The user also contains the expected SID-History attribute and receives the expected SID-History values in the access token after logon.

However, accessing a resource located in the trusted source domain fails.

Example:

dir \\dc01.source.com\shtest

When NTLM is disabled, Windows reports an error similar to:

Authentication failed because NTLM authentication has been disabled.

 

Environment

The issue was observed in a lab environment using:

  • Two separate Active Directory forests
  • One domain per forest
  • Two-way external (domain) trust
  • SID filtering (quarantine) disabled
  • SID-History migrated correctly
  • NTLM disabled
  • Kerberos authentication

Replacing the external domain trust with a forest trust immediately resolved the authentication problem without any additional configuration.

Initial Investigation

The first assumption was that SID-History was not functioning correctly.

However, the following checks all succeeded:

  • SID-History attribute populated
  • SID-History present in the user's logon token (whoami /groups)
  • Trust healthy
  • SID filtering disabled
  • Cross-realm Kerberos ticket successfully obtained

For example:

klist get krbtgt/SOURCE.COM

completed successfully.

The failure occurred only when requesting the Kerberos service ticket:

klist get cifs/dc01.source.com

which returned:

Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb

klist failed with 0xc000018b

Because no Kerberos service ticket could be obtained, Windows attempted NTLM authentication instead. Since NTLM had been disabled, access failed.

Cause

During troubleshooting it became apparent that Kerberos was unable to associate the requested service principal name (SPN)

cifs/dc01.source.com

with the appropriate Kerberos realm when using the external domain trust.

Although the trust itself was operational and cross-realm Kerberos tickets could be obtained successfully, Windows failed to obtain the final service ticket for the requested service.

Resolution

Adding an explicit Host-to-Realm mapping immediately resolved the issue.

Example:

ksetup /addhosttorealmmap dc01.source.com SOURCE.COM

After purging existing Kerberos tickets:

klist purge

requesting the service ticket succeeded:

klist get cifs/dc01.source.com

The SMB access then completed successfully using Kerberos without falling back to NTLM.

Verifying Host-to-Realm Mappings

Host-to-Realm mappings are stored locally on the computer.

They can be verified in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\HostToRealm

Example:

SOURCE.COM
    SpnMappings = dc01.source.com

Although ksetup is used to create and remove these mappings, existing mappings may not always be displayed by the ksetup command itself. Verifying the registry is therefore recommended.

Mappings can be removed again using:

ksetup /delhosttorealmmap dc01.source.com SOURCE.COM

You can add a DNS suffix mapping using the syntax below, to map multiple servers at once:

ksetup /addhosttorealmmap .source.com SOURCE.COM

Only use a suffix-wide mapping if the complete DNS namespace belongs to the specified Kerberos realm. An overly broad or incorrect mapping can route Kerberos requests to the wrong realm.

Deploying the Mapping through Group Policy

For multiple clients or servers, deploy the mapping centrally through:

Computer Configuration
  Administrative Templates
    System
      Kerberos
        Define host name-to-Kerberos realm mappings

Troubleshooting Steps

If Kerberos authentication falls back to NTLM across an external domain trust, the following checks may help identify the problem:

Verify that SID-History has been migrated correctly.

Confirm that SID filtering has been disabled for the external domain trust.

Verify that a cross-realm Kerberos ticket can be obtained:

klist get krbtgt/SOURCE.COM

Attempt to request the Kerberos service ticket:

klist get cifs/dc01.source.com

If the cross-realm ticket succeeds but the service ticket fails with:

0xC000018B

consider testing an explicit Host-to-Realm mapping using ksetup.

Forest Trust versus External Domain Trust

During testing, the same authentication scenario worked immediately after replacing the external domain trust with a forest trust.

Forest trusts provide automatic name suffix routing between forests, while external domain trusts use different Kerberos trust mechanisms.

In the investigated environment, explicitly mapping the target host to the appropriate Kerberos realm resolved the service ticket acquisition problem when using an external domain trust.

Summary

If users migrated with SID-History can authenticate successfully but resource access fails because Windows falls back to NTLM, the problem may not be related to SID-History itself.

Verify whether Kerberos is able to obtain the required service ticket.

If

klist get krbtgt/SOURCE.COM

succeeds but

klist get cifs/server.source.com

fails with

0xC000018B

an explicit Host-to-Realm mapping may resolve the problem:

ksetup /addhosttorealmmap server.source.com SOURCE.COM

This approach resolved the issue in our laboratory environment using an external Active Directory domain trust while allowing Kerberos authentication to continue without falling back to NTLM.

If you are troubleshooting Kerberos, SID-History, or trust-related access issues during a migration, Sys-Manage CopyRight2 can help with Active Directory migration with SID-History, including cross-domain and cross-forest migration scenarios where authentication behavior must be validated carefully.

For workstation and user environment moves, see also computer and user profile migration.