Kerberos-Authentifizierung schlägt über eine externe Domänenvertrauensstellung fehl, wenn NTLM deaktiviert ist (SID-History-Troubleshooting)

Bei der Migration von Active-Directory-Benutzern mit SID-History kann es vorkommen, dass Benutzer zwar erfolgreich authentifiziert werden, aber trotzdem nicht auf Ressourcen in der vertrauenswürdigen Quelldomäne zugreifen können.

In unserer Laborumgebung schien die Kerberos-Authentifizierung auf den ersten Blick korrekt zu funktionieren. Cross-Realm-Kerberos-Tickets konnten erfolgreich abgerufen werden, die externe Domänenvertrauensstellung war fehlerfrei, und SID-Filtering war deaktiviert. Trotzdem konnte Windows das erforderliche Kerberos-Service-Ticket für den Ziel-Dateiserver nicht abrufen. Dadurch fiel Windows auf NTLM-Authentifizierung zurück. Ist NTLM deaktiviert, schlägt der Zugriff fehl.

Dieser Artikel erklärt, wie diese Situation erkannt werden kann und welche mögliche Lösung es gibt.

Symptome

Ein migrierter Benutzer authentifiziert sich erfolgreich an der Zieldomäne.

Der Benutzer enthält außerdem das erwartete SID-History-Attribut und erhält nach der Anmeldung die erwarteten SID-History-Werte im Zugriffstoken.

Der Zugriff auf eine Ressource in der vertrauenswürdigen Quelldomäne schlägt jedoch fehl.

Beispiel:

dir \\dc01.source.com\shtest

Wenn NTLM deaktiviert wurde, meldet Windows einen Fehler ähnlich wie:

Authentication failed because NTLM authentication has been disabled.

Umgebung

Das Problem wurde in einer Laborumgebung mit folgender Konfiguration beobachtet:

• Zwei separate Active-Directory-Forests
• Eine Domäne pro Forest
• Zwei-Wege-externe Domänenvertrauensstellung
• SID-Filtering (Quarantine) deaktiviert
• SID-History korrekt migriert
• NTLM deaktiviert
• Kerberos-Authentifizierung

Das Ersetzen der externen Domänenvertrauensstellung durch eine Forest-Vertrauensstellung löste das Authentifizierungsproblem sofort ohne zusätzliche Konfiguration.

Erste Analyse

Die erste Vermutung war, dass SID-History nicht korrekt funktionierte.

Die folgenden Prüfungen waren jedoch erfolgreich:

• SID-History-Attribut war vorhanden
• SID-History war im Anmeldetoken des Benutzers vorhanden (whoami /groups)
• Vertrauensstellung war fehlerfrei
• SID-Filtering war deaktiviert
• Cross-Realm-Kerberos-Ticket konnte erfolgreich abgerufen werden

Beispiel:

klist get krbtgt/SOURCE.COM

wurde erfolgreich abgeschlossen.

Der Fehler trat nur beim Anfordern des Kerberos-Service-Tickets auf:

klist get cifs/dc01.source.com

Dies gab folgenden Fehler zurück:

Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb

klist failed with 0xc000018b

Da kein Kerberos-Service-Ticket abgerufen werden konnte, versuchte Windows stattdessen NTLM-Authentifizierung. Da NTLM deaktiviert war, schlug der Zugriff fehl.

Ursache

Während der Fehlersuche zeigte sich, dass Kerberos den angeforderten Service Principal Name (SPN) nicht dem passenden Kerberos-Realm zuordnen konnte:

cifs/dc01.source.com

Dies trat bei Verwendung der externen Domänenvertrauensstellung auf.

Obwohl die Vertrauensstellung selbst funktionierte und Cross-Realm-Kerberos-Tickets erfolgreich abgerufen werden konnten, konnte Windows das finale Service-Ticket für den angeforderten Dienst nicht beziehen.

Lösung

Das Hinzufügen eines expliziten Host-to-Realm-Mappings löste das Problem sofort.

Beispiel:

ksetup /addhosttorealmmap dc01.source.com SOURCE.COM

Nach dem Löschen vorhandener Kerberos-Tickets:

klist purge

war das Anfordern des Service-Tickets erfolgreich:

klist get cifs/dc01.source.com

Der SMB-Zugriff funktionierte anschließend erfolgreich mit Kerberos ohne Rückfall auf NTLM.

Host-to-Realm-Mappings prüfen

Host-to-Realm-Mappings werden lokal auf dem Computer gespeichert.

Sie können in der Registry geprüft werden:

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

Beispiel:

SOURCE.COM
    SpnMappings = dc01.source.com

Obwohl ksetup zum Erstellen und Entfernen dieser Mappings verwendet wird, werden vorhandene Mappings nicht immer zuverlässig durch den ksetup-Befehl selbst angezeigt. Die Prüfung der Registry wird daher empfohlen.

Mappings können wieder entfernt werden mit:

ksetup /delhosttorealmmap dc01.source.com SOURCE.COM

Mit der folgenden Syntax kann auch ein DNS-Suffix-Mapping hinzugefügt werden, um mehrere Server gleichzeitig abzudecken:

ksetup /addhosttorealmmap .source.com SOURCE.COM

Ein suffixweites Mapping sollte nur verwendet werden, wenn der komplette DNS-Namespace zu dem angegebenen Kerberos-Realm gehört. Ein zu breites oder falsches Mapping kann Kerberos-Anfragen an den falschen Realm leiten.

Mapping per Gruppenrichtlinie bereitstellen

Für mehrere Clients oder Server kann das Mapping zentral per Gruppenrichtlinie bereitgestellt werden:

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

Troubleshooting-Schritte

Wenn Kerberos-Authentifizierung über eine externe Domänenvertrauensstellung auf NTLM zurückfällt, können die folgenden Prüfungen helfen, das Problem einzugrenzen:

Prüfen Sie, ob SID-History korrekt migriert wurde.

Bestätigen Sie, dass SID-Filtering für die externe Domänenvertrauensstellung deaktiviert wurde.

Prüfen Sie, ob ein Cross-Realm-Kerberos-Ticket abgerufen werden kann:

klist get krbtgt/SOURCE.COM

Versuchen Sie anschließend, das Kerberos-Service-Ticket anzufordern:

klist get cifs/dc01.source.com

Wenn das Cross-Realm-Ticket erfolgreich ist, aber das Service-Ticket fehlschlägt mit:

0xC000018B

sollte ein explizites Host-to-Realm-Mapping mit ksetup getestet werden.

Forest-Vertrauensstellung im Vergleich zur externen Domänenvertrauensstellung

Während der Tests funktionierte dasselbe Authentifizierungsszenario sofort, nachdem die externe Domänenvertrauensstellung durch eine Forest-Vertrauensstellung ersetzt wurde.

Forest-Vertrauensstellungen stellen automatisches Namenssuffix-Routing zwischen Forests bereit, während externe Domänenvertrauensstellungen andere Kerberos-Vertrauensmechanismen verwenden.

In der untersuchten Umgebung löste die explizite Zuordnung des Zielhosts zum passenden Kerberos-Realm das Problem beim Abrufen des Service-Tickets bei Verwendung einer externen Domänenvertrauensstellung.

Zusammenfassung

Wenn mit SID-History migrierte Benutzer sich erfolgreich authentifizieren können, der Ressourcenzugriff aber fehlschlägt, weil Windows auf NTLM zurückfällt, liegt das Problem möglicherweise nicht an SID-History selbst.

Prüfen Sie, ob Kerberos das erforderliche Service-Ticket abrufen kann.

Wenn

klist get krbtgt/SOURCE.COM

erfolgreich ist, aber

klist get cifs/server.source.com

mit

0xC000018B

fehlschlägt, kann ein explizites Host-to-Realm-Mapping das Problem lösen:

ksetup /addhosttorealmmap server.source.com SOURCE.COM

Dieser Ansatz löste das Problem in unserer Laborumgebung mit einer externen Active-Directory-Domänenvertrauensstellung und ermöglichte weiterhin Kerberos-Authentifizierung ohne Rückfall auf NTLM.

Wenn Sie Kerberos-, SID-History- oder vertrauensstellungsbezogene Zugriffsprobleme während einer Migration untersuchen, kann Sys-Manage CopyRight2 bei der Active-Directory-Migration mit SID-History unterstützen, einschließlich domänen- und forestübergreifender Migrationsszenarien, in denen das Authentifizierungsverhalten sorgfältig validiert werden muss.

Für die Migration von Arbeitsstationen und Benutzerumgebungen siehe auch Computer- und Benutzerprofilmigration.