mzahneissen

Am 14.11.2025 um 16:56 schrieb cj_berlin:

Update (weil die ganze Welt ja drauf wartet):

Nach diversen eigenen Tests und einer abendlichen gemeinsamen Session mit @MurdocX kristallisiert sich das folgende Bild heraus:

• es funktioniert (und ja, ich weiß, das wurde von @mzahneissen anders gemeldet) mit Server 2019 und 2022 bei SMB-Zugriff von Member zu Member und Cross-Forest-Anmeldung auf einem Member (alles Server)
• es funktioniert NICHT (genau wie von @mzahneissen und @MurdocX beschrieben) in einem Lab, das komplett aus Server 2025-Maschinen besteht (DCs und Member).
• es funktioniert auch der Zugriff von einem Server 2025 oder Windows 11 Member auf einen Server 2022 Member in einem Lab, das 2022er DCs hat
• das Problem hat augenscheinlich NICHT mit der Site-Bestimmung und DCLocator zu tun (war kurz mal eine Idee)
• das Problem hat augenscheinlich auch NICHT mit dem November-Patchday zu tun.

Soweit es also Dinge betrifft, die ich mit eigenen Augen gesehen habe, ist es mal wieder ein "Server 2025 als DC"-Problem. Bleiben also Meldungen in diesem Thread, die darauf hinweisen, dass das Phänomen ggfls. auch mit 2019 oder 2022 besteht, aber das kann ich beim besten Willen  nicht nachstellen.

 

Ich habe das an die PG gegeben, da aber Cliff Fischer gerade das Weite gesucht hat (nein, ich weiß nicht, ob er zu Semperis kommen wird  ) sind sie gerade im Schock und mit verminderter Mannstärke und Motivation unterwegs.

 

Jetzt wo ich ein Lab habe, wo es nicht funktioniert, werde ich mal ein paar Traces ziehen und weiter schauen.

Hallo @cj_berlin und @MurdocX, vielen Dank für Euer Engagement und die vielen Tests. Leider bin ich seit Tagen krank und auch diese Woche nicht in der Firma. Wenn ich irgendwas beitragen kann, Traces, Klist oder sonst etwas, kann ich Kollegen bitten das durchzuführen.

vor 6 Minuten schrieb cj_berlin:

Trust-Einstellungen sind bei mir genau so, es muss auch nichts am Trust extra fürs Armoring gesetzt werden - außer, dass die Client-Policy auch auf DCs gelten muss, aber ich schätze, das ist der Fall, denn sonst würde man sich gar nicht mehr anmelden können.

Spannend. Ist es vielleicht doch ein OS-Versionsthema? Ich meine, einer von euch erwähnte 2019er DCs? Schon zu spät, um den Thread nochmal aufmerksam zu lesen...

richtig, bei mir sind alle DCs 2019, DFL und FFL 2016.

Trust-Konfig und Klist kann ich erst Mittwoch bei mir vergleichen.

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?

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.

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.

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.

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.

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