[English]Heute noch ein kurzer Informationssplitter, auf den mich ein Blog-Leser bereits im November 2024 hingewiesen hat. Wird ein Active Directory Domain-Hardening gemäß Update KB5020276 durchgeführt, kann es Probleme unter Windows 11 23H2 geben, so dass Active Directory Domain Computer ReJoin fehl schlägt.
Anzeige
Netjoin: Domain Join Hardening Changes
Microsoft beschreibt im Supportbeitrag KB5020276—Netjoin: Domain join hardening changes (Artikel wurde zum 13. August 2024 überarbeitet) Änderungen, die wegen der Schwachstelle CVE-2022-38042 in den kumulativen Update-Paketen vom 11. Oktober 2022 für alle unterstützten Betriebssysteme eingeführt wurden.
Ich hatte 2022 im Blog-Beitrag Windows Oktober 2022-Patchday: Fix für Domain Join Hardening (CVE-2022-38042) verhindert ggf. Domain-Join über Probleme in diesem Zusammenhang berichtet. In den Windows-Updates, die am oder nach dem 13. August 2024 veröffentlicht wurden, will Microsoft alle bekannten Kompatibilitätsprobleme mit der Allowlist-Richtlinie behoben haben. Außerdem wurde die Unterstützung für den NetJoinLegacyAccountReuse -Schlüssel entfernt. Das Härtungsverhalten wird unabhängig von der Schlüsseleinstellung beibehalten.
Windows 11 23H2 macht Probleme
Ein Blog-Leser hat mich im November 2024 per Mail kontaktiert und berichtet, dass es mit Windows 11 Probleme gebe, weil dort die GPOs nicht greifen. Der Leser verlinkte auf den Beitrag Active Directory: Computer Account Re-Use Domain Join Policy vom Juni 2024.
Dort beschreibt jemand ein Problem mit Domain ReJoin, der mit einem Fehler, dass "Ein Konto mit demselben Namen existiert in Active Directory. Die Wiederverwendung des Kontos wurde durch die Sicherheitsrichtlinie blockiert." abgelehnt wurde. Um dieses Problem zu beheben, empfiehlt Microsoft jetzt die Verwendung einer neuen GPO-Einstellung.
Anzeige
Der Blog-Leser schreibt in seiner Mail: "Hat man Windows 11, greift das AD GPO Setting nicht, soeben probiert … Ein Computer Rejoin sollte uns Admins nicht Kopfschmerzen machen, auch wenn hardening notwendiges Übel ist :(".
Im Umfeld des Lesers verwendet dieser die "Server GPO" ein – die zwar greift. Aber mit dem August 2024-Update wurde der "Legacy"-Registry-Eintrag deaktiviert, so dass dieser nicht mehr greift. Seit dieser Zeit funktioniert beim Blog-Leser absolut kein ReJoin mehr unter Windows 11 23H2. Nur noch Computerkonto löschen, und frisch hinzufügen.
Bisher hat der Leser noch nicht gewagt, Windows 11 24H2 im Firmenumfeld in der Active Directory einzusetzen. In einer Nachtrags-Mail schrieb der Leser, dass in seinem geschilderten Falleine Kerberos Problematik / MTU-Einstellung der Grund zu sein scheint, die ganz seltsame Verhalten hervorruft.
Das gelte auch beim ReJoin und verursache diverse andere in den Log-Dateien nicht auffindbare Sachen, so dass die Ursache schwierig zu lokalisieren. Bei einem tadellos laufenden AD Netzwerk konnte der Leser mit Windows 11 23H2 mit der GPO hingegen sauber rejoinen.
Das Problem ist beim Leser also nicht reproduzierbar. Frage an die Blog-Leserschaft: Hat noch jemand ein solches Verhalten beobachtet? Gibt es ggf. Hinweise, was ggf. falsch gemacht wurde. Der Leser schrieb: "Vielleicht bin ich auch einfach zu blöd um zu verstehen, was mit 'es muss der Owner des Computeraccounts eingegeben werden in der GPO, aber auf keinen Fall in die GPO lokale Gruppen oder User hinzufügen' gemeint ist?"
Anzeige
mein Re-Deployment einer Maschine (24H2) per SCCM funktioniert einwandfrei.
das verwendete Konto für den connect zum AD hat Vollzugriff auf untergeordnete Computer Objekte in einer OU und darf Computer löschen/erstellen
ich bin gerade nicht sicher, ob SCCM das Konto nach löschen neu erzeugt, oder nur resettet.
Das Problem liegt im Attribut des Computerobjekts mS-DS-CreatorSID. Steht hier eine SID eines Users, so kann nur mehr dieser User einen Rejoin durchführen. Es ist uns nicht gelungen dieses Attribut zu verändern. Letzter und einziger Ausweg ist das Konto zu löschen und neu anzulegen. Deshalb ist das Problem auch nicht nachstellbar bei diesem Konto. Hier ein Powershell Befehl um festzustellen welche Konten betroffen sind:
Get-AdComputer -filter { mS-DS-CreatorSID -like '*' -and Enabled -eq $True } | Out-GridView
Bei mir gibt es eine selbst erstellte AD-Gruppe "Trusted-Computer-Owners".
In der Default Domain Controller Policy wurde eingestellt:
Domain controller: Allow computer account re-use during domainjoin = Administratoren + Trusted-Computer-Owners.
In diese Gruppe kam dann ein (nicht Domain Administrators) Dienstkonto eines Benutzers, der ohne überhöhte Privilegien Domainjoins durchführt und dessen Computerobjekte bei Auffrischung durch Schreibberechtigte keine solchen Probleme mehr machten.
Ich hoffe das funktioniert auch mit 24H2 noch so, aus der freien Wildbahn wurde noch nichts berichtet.
Vielleicht hilft das irgendwie weiter?
ah. ok. Danke!
dann ist es ein Creator/Owner Ding, wo nur er Selbst/Self das Recht hat.
habt ihr Mal die ACLs auf dem Objekt geändert?
Das ist ein Security Feature. Wer die "Fehler-" Meldung genau liest, kann entnehmen, dass der Rejoin mit dem gleichen, priviligierten Account erfolgen muss. Ansonsten bleibt nur das Löschen des Accounts oder die Aufweichung der Security.
Falsch. Es muss nur in der "Default Domain Controllers Policy" unter "Lokale Richtlinien/Zuweisen von Benutzerrechten" die Richtlinie "Hinzufügen von Arbeitsstationen zur Domäne" konfiguriert und mit einer entsprechenden AD-Gruppe gefüllt werden.
Dann dürfen auch wieder andere Benutzer (Mitglieder der Gruppe) Re-Joins durchführen.
Naja, das war früher mal ausreichend.
Reguläre DomainUser können jetzt nur Re-Joins von Rechnern durchführen bei deren Rechnerobjekten sie selbst im mS-DS-CreatorSID Attribut eingetragen sind oder bei denen das Attribut leer geblieben ist.
Meiner (hoffentlich zutreffenden) Beobachtung nach wird beim Erzeugen+Domainjoin das Attribut leer gelassen, wenn der Erzeuger aus Sicht der DCs in der Policy "Domain controller: Allow computer account re-use during domainjoin" genannt ist – das trifft per Default bei Domain Admins zu.
Ich weiss nicht ob sich das zuletzt geändert hat, aber als MS das verschärfte, hing übrigens der Erfolg diese Blockade davon ab, ob der Client auf aktuellem Patchlevel war, ungepatchte Clients missachteten das einfach – keine Ahnung ob das immernoch so schlimm ist.