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 Dienstag 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 Mittwoch um 11:22 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.

 

[zahni 588]

Lies mal diese Seite und den Hinweis zu Windows 2025.

 

https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts

[mzahneissen 0]

vor 5 Stunden schrieb zahni:

Lies mal diese Seite und den Hinweis zu Windows 2025.

 

https://learn.microsoft.com/de-de/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/credential-guard-protected-machine-accounts

Danke, den Artikel kannte ich noch nicht. Jedoch sehe ich auch hier keine Abhängigkeit für Armoring von Credential Guard. All unsere Server sind 2019/2022, die DCs 2019.

 

[cj_berlin 1.515]

OK, wie versprochen:

• ungehärteter uneingeschränkter bidirektionaler Forest Trust
• Auf einer Seite: Root + Sub, auf der anderen Seite: Single-Domain
• Auf allen Members UND DCs gilt: "Kerberos client support for claims etc." = ENABLED, sonst keine Kerberos Client-Einstellungen abweichend von Defaults
• Auf allen DCs in allen drei Domains gilt: "KDC support for claims etc." = "Fail unarmored authentication requests"

Beobachtetes Verhalten:

• User aus einer beliebigen Domain kann sich interaktiv an einem Member aus einer beliebigen Domain anmelden ("Domain Users" aller drei Domains sind in "Users" und "Remote Desktop Users" auf allen Members)
• User aus einer beliebigen Domain kann, interaktiv s.o. angemeldet, auf eine File Share aus der jeweils anderen Domain zugreifen.

PKI ist keine implementioert, somit auch keine Strict KDC Validation oder Ähnliches

 

Nun musst Du @mzahneissen schauen, was bei Dir anders ist:

• Kerberos-Client-Policy doch nicht auf alle DCs angewendet?
• Trust nur in eine Richtung?
• Trust gehärtet?
• Selektive Authentifizierung am Trust?

Ich schätze, wenn klist Dir bei "Supported" immer FAST-Tickets zeigt, solltest Du mal auf den DCs mit klist -li 0x3e7 schauen, ob es für die DCs genauso gilt...

P.S. Clientseitig ist in meinem Lab "Fail request if armoring not available"  nirgends gesetzt.