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,521]

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,521]

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.

Edited October 28 by 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.

 

Edited October 29 by 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,521]

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 implementiert, 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.

Edited November 1 by cj_berlin

[MurdocX 1,006]

Ich habe das gleiche Verhalten wie @mzahneissen in meiner Testumgebung.

 

@cj_berlin - sorry, ich hab deine Textbausteine einfach schnell kopiert ;)

 

# Setup

• ungehärteter uneingeschränkter bidirektionaler Forest Trust (Dom A & Dom B, Dom B1)
• Auf einer Seite: Root + Sub, auf der anderen Seite: Single-Domain
• Auf allen Members UND DCs gilt: "Kerberos client support for claims etc."
• PKI ist keine implementiert, somit auch keine Strict KDC Validation oder Ähnliches
• Aktueller Updatestand auf allen Domaincontrollern und Servern
• Credential-Guard auf allen Server ist aktiv

# KDC - Kerberos Amoring -> Supportet 

• ✅ Server (Dom A) greift auf DC (Dom A) zu 
• ✅ Server (Dom A) greift auf Share Server (Dom B) - vice versa
• ✅ DC (Dom A) greift auf Share DC (Dom B) - vice versa
• ✅ Anmelden mit Benutzern der jeweils anderen Domäne

# KDC - Kerberos Amoring -> Fail unamored authentication requests

• ✅ Server (Dom A) greift auf DC (Dom A) zu 
• ❌ Server (Dom A) greift auf Share Server (Dom B) - vice versa -> Benutzerabfrage, vermutlich NTLM.
• ✅ DC (Dom A) greift auf Share DC (Dom B) - vice versa
• ❌ Anmelden mit Benutzern der jeweils anderen Domäne 

 

Ich bekomme auf dem Server, wenn ich mit einem User der anderen Domäne anmelden möchte:

-> Security, 4625, Failure Reason: An Error occured during Logon, Status: 0xC000006D, Logontype: 2

 

0xC000006D: The attempted logon is invalid. This is either due to a bad username or authentication information.

SubType: 0x0

 

Edited Sunday at 06:50 PM by MurdocX

[cj_berlin 1,521]

Moin,

 

das ist natürlich unerfreulich  

 

NTLM sollte damit nichts zu tun haben, wenn NTLM zulässig ist. Ich kann die Shares in beliebigen Konstellationen auch über IP (also mit NTLM) erreichen, habe dann auch kein Service-Ticket im Cache.

 

Was sagt denn auf den DCs in dieser Situation

klist -li 0x3e7

klist -li 0x3e7

? Gern auch mal purgen und erneut versuchen...

[mzahneissen 0]

Am 1.11.2025 um 10:59 schrieb cj_berlin:

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 implementiert, 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.

Hallo @cj_berlin, danke für Deine Tests. Was genau meinst Du mit gehärtetem Trust?

 

@MurdocX, danke für Deinen Post, ich dachte schon, wir sind die einzigen mit dem Problem. Welche Version sind Eure DCs?

[cj_berlin 1,521]

Bei mir sind die DCs und Member alle 2022, gepatcht auf Oktober.

"gehärteter Trust" wäre einer, wo dieser Trust User Account mit einer AuthN Policy bewehrt ist, die immer fehlschlägt, so dass er sich nicht authentifizieren kann (gehärtet gegen das Durchbrechen in die falsche Richtung). Wir machen das gern inzwischen auch bei bidirektionalen Trusts, denn wer weiß, ob nicht doch eines Tages auf unidirektional umgestellt wird...