Kerberos Armoring, Fehler bei Domain-Trust

[mzahneissen 0]

Hallo,

 

bei der Aktivierung von Kerberos-Armoring in einer Umgebung mit mehreren Active Directory Domains und Forests stoße ich auf Fehler sobald Armoring erzwungen wird. Die Umgebung enthält einen Forest mit einer Root- und einer Tree-Domain sowie einen weiteren Forest mit nur einer einzigen Domain. Alle Domains sind mit 2-Way-Trust verbunden. Wird Armoring nur auf "Supported" gesetzt ist alles OK, bei "Required" funktionieren verschiedene Dinge nicht mehr. Es gibt Fehler bei der AD-Replikation zwischen den Domänen im gleichen Forest. Der Zugriff über die Domänengrenzen scheitert, z.B. Dateizugriff oder auch RDP-Anmeldung. Das gilt sowohl für die Domänen im gleichen Forest als auch zwischen den Forest. Als Fehlermeldung kommt immer, fehlerhafte Anmeldung oder vergleichbares.

Wir konnten das Problem auch in neu aufgebauten Testumgebungen nachstellen.

 

Kennt das jemand? oder besser noch, eine Lösung?

 

Ich freue mich über jeden Tipp.

Dank an Euch im Voraus.

Michael

[cj_berlin 1.515]

Moin,

 

ist auf die DCs auch die Kerberos Client-Policy für Armoring ausgerollt oder nur die KDC-Policy? Das ist der häufigste Fehler  

[mzahneissen 0]

vor 2 Minuten schrieb cj_berlin:

Moin,

 

ist auf die DCs auch die Kerberos Client-Policy für Armoring ausgerollt oder nur die KDC-Policy? Das ist der häufigste Fehler  

Hallo cj_berlin,

 

ja, sowohl die Kerberos-Client als auch die KDC-Policy sind konfiguriert. Wenn die KDC-Policy auf Supported steht, werden auch Tickets mit der FAST-Option ausgestellt (KLIST). Clients sind alle Win11 oder Server 2019/2022.

Ich hatte auch testweise nach der Aktivierung 2xKRBTGT-Resets durchgeführt (in der Testumgebung), ohne Auswirkung auf den Armoring-Fehler.

 

[cj_berlin 1.515]

Ich bin gespannt, ob jemand Ideen hat. Ich bin am Freitag wieder im Lande und kann mir das anschauen, ich habe mindestens ein Labor, wo das funktioniert. (Disclaimer: Funktionierte im Sommer).

Es ist in dieser unseren Zeit nicht auszuschließen, dass einer der letzten Patchdays das kaputt gemacht hat, selbst wenn's im Sommer noch funktioniert hat.

bearbeitet Gestern um 13:53 von cj_berlin

[zahni 588]

Firewalls habt Ihr nicht dazwischen? Man übersieht gern mal, dass Kerberos Port 88 UDP benötigt.

[mzahneissen 0]

vor 27 Minuten schrieb zahni:

Firewalls habt Ihr nicht dazwischen? Man übersieht gern mal, dass Kerberos Port 88 UDP benötigt.

Zwischen den einzelnen Sites und Domänen gibt es Firewalls. Hier sind jedoch alle notwendigen Ports - inkl. UDP/88 - freigeschaltet.

In der eigens aufgesetzten Testumgebung waren alle Systeme ohne Firewall verbunden, auch die lokalen FWs waren deaktiviert.

 

bearbeitet vor 3 Stunden von mzahneissen

[zahni 588]

Wenn ich das korrekt verstehe, ist die Funktion von validen Zertifikaten und Credential Guard abhängig.. Und Credential Guard braucht bestimmte Hardware- oder Hypervisor-Funktionen:

 

https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/additional-mitigations

 

 

[mzahneissen 0]

vor 24 Minuten schrieb zahni:

Wenn ich das korrekt verstehe, ist die Funktion von validen Zertifikaten und Credential Guard abhängig.. Und Credential Guard braucht bestimmte Hardware- oder Hypervisor-Funktionen:

 

https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/additional-mitigations

 

 

Danke. Den Beitrag kenne ich und verstehe es so, dass für bestimmte Funktionen Credential Guard (hier, damit die DCs erkennen, von welchem Gerät sich ein User anmeldet) Kerberos Armoring benötigt wird. Aber dass es auch umgekehrt notwendig ist - also dass für Armoring Voraussetzung Credential Guard ist - lese ich nicht in dem Artikel. Auch werden hier nur die Einstellungen "Supported" und nicht "Required" für Armoring beschrieben. "Supported" funktioniert problemlos, nur bei "Required" gibt es Probleme.

Credential Guard haben wir nicht im Einsatz, jedoch eine funktionierende und korrekte PKI für alle Entitäten im AD.