Domain Join Hardening Changes mit dem CU 10/22

[phatair 39]

Hallo zusammen,

 

ich habe dazu im Board noch nichts gefunden und ich hoffe der Bereich hier ist der richtige.

 

Günther Born hatte schon vor ein paar Tagen darüber berichtet, dass mit dem CU 10/22 die Sicherheitslücke CVE-2022-38042 geschlossen wurde.

Dies hat zur Folge, dass sich beim Domain Join etwas ändert.

MS hat dazu auch einen KB Artikel veröffentlich, blöderweise ist der aber im KB Artikel von dem CU 10/22 nicht vermerkt.

https://support.microsoft.com/en-us/topic/kb5020276-netjoin-domain-join-hardening-changes-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8

 

Zitat

New behavior after you install October 11, 2022 and later updates

During domain join, the client will perform additional security checks before attempting to reuse an existing computer account.

Algorithm:

1. Account reuse attempt will be permitted if the user attempting the operation is the creator of the existing account.

2. Account reuse attempt will be permitted if the account was created by a member of domain administrators.

This change does not affect new accounts.

 

Wenn das CU 10/22 installiert ist, ändert sich folgendes.

Bisher konnte ein Client auch dann in die Domäne aufgenommen werden, wenn das Computer Objekt schon bestand. Der Account der für den Domain Join genutzt wurde musste nur die passenden Rechte haben. Diese hatte man ja meisten per Delegation auf die OU gesetzt.

Ab dem CU 10/22 geht das nicht mehr. Wenn das Computer Objekt schon besteht kann nur noch ein Domänen Admin oder der damalige Ersteller des Computer Objekts den Domain Join durchführen.

 

Bei uns werden Clients beim Imaging über einen Service Account in die Domäne aufgenommen. Nur bestimmte Accounts haben überhaupt das Recht Clients in die Domäne aufzunehmen.

Würde nun ein Client aus der Domäne genommen werden (z.B. troubleshooting) und ein Client Admin würde versuchen den Client wieder aufzunehmen, würde das fehlschlagen. Er müsste das als Domain Admin machen (ist ein NoGo bei uns) oder den Service Account aus dem Imaging nehmen. Letzte Lösung wäre dann, er löscht das Computer Objekt und lässt es neu erstellen.

 

Ich hoffe, ich habe hier nichts komplett falsch verstanden. Finde die Änderung ärgerlich, aber nicht so problematisch, da dieses Vorgehen bei uns äußert selten vorkommen wird.

Aber MS hätte es meiner Meinung nach besser kommunizieren müssen. Ich hätte diese Info nirgends gefunden.

 

Was meint ihr? hab ich da einen Denkfehler und wusstet ihr von der Änderung?

[daabm 1.348]

Wir haben das leider auch nicht mitbekommen, und es hat uns voll erwischt... Derzeit prüfen wir, ob unser Offline Domain Join durch den Fix aus dem Artikel von Günter Born repariert werden kann. Andere Prozesse haben's evtl. schwerer...

 

Hintergründe: Wir joinen Clients über den Offline-Join von netdom. Dafür verwenden wir einen Service-Account, der natürlich kein Dom-Admin ist. Das resultierende File wird zum Client transportiert, so daß der ohne Join-Credentials auskommt. "Früher" haben wir die Clients mit einem dedizierten Join-User gejoint. Wird jetzt ein Client reinstalliert, der mit dem früheren Verfahren "ursprünglich" erstellt wurde, kan das Djoin-File nicht mehr erstellt werden - "Reuse prohibited". Klar - der Account wurde unrsprünglichen dedizierten Join-User erstellt, der jetzt verwendete Account ist ein anderer

 

Für kleinere Umgebungen, in denen sich nicht sooo viel ändert bei den Clients, würde ich einfach die Dom-Admins zum Owner aller Member machen. Sollte per dsacls oder setacl nicht der riesen Aufwand sein, das zu skripten und auf den Domain Controllern per Task auszuführen. Könnte man sogar noch triggern auf "Computer Account created", dann wäre es eine "nachhaltige" Lösung

[NorbertFe 2.027]

Ich versuch grad nachzuvollziehen, wieso das ganze irgendwas "sicherer" macht. Wenns den DomainAdmins "gehört", dann kann ich es überschreiben/übernehmen. Gehört es jemand anderem als dem Joining User ist es verboten. Wo ist denn da jetzt der Schutz, oder zielt das etwa darauf ab, dass jeder User per Default 10 Konten aufnehmen kann?

[cj_berlin 1.306]

Ich denke, es geht darum, dass jemand z.B. einen SCCM (seit der Ignite; Intune) Site-Server umzieht und das alte Computer-Objekt liegen lässt. Dieses ist Admin auf der SQL-Datenbank und meistens auch auf dem SQL Server, sowie auf sämtlichen anderen SCCM-Servern. Joine ich als Attacker eine Maschine, wo ich lokaler Admin bin, unter diesem Namen, dann kann ich an die SQL-Datenbank, und dort sind Kennwörter von Accounts, die Admin sind auf allen Clients und ggfls. auch Servern, usw. usw. usw....

[NorbertFe 2.027]

Hmm klingt irgendwie auch relativ konstruiert. Am Ende hülfe vermutlich, wenn bei Domain austritt das Konto nicht deaktiviert sondern gelöscht würde. Und ja das Risiko bleibt, dass einfach abgeschaltet wird und das Konto rumliegt. 

[cj_berlin 1.306]

Naja, im CVE steht auch Complexity=High. Sowas einfaches wie log4j kriegt man nicht jeden Tag geschenkt.

[phatair 39]

vor 17 Stunden schrieb NorbertFe:

Ich versuch grad nachzuvollziehen, wieso das ganze irgendwas "sicherer" macht. Wenns den DomainAdmins "gehört", dann kann ich es überschreiben/übernehmen. Gehört es jemand anderem als dem Joining User ist es verboten. Wo ist denn da jetzt der Schutz, oder zielt das etwa darauf ab, dass jeder User per Default 10 Konten aufnehmen kann?

 

Stimmt, dass hatte ich falsch verstanden. 

Ich hatte es so verstanden, dass man Domänen Admin sein muss um das Objekt zu übernehmen. Aber es ist so, dass man es übernehmen kann, wenn der Objekt Ersteller ein Domänen Admin war.

[daabm 1.348]

vor 21 Stunden schrieb cj_berlin:

Joine ich als Attacker eine Maschine, wo ich lokaler Admin bin, unter diesem Namen, dann kann ich an die SQL-Datenbank, und dort sind Kennwörter von Accounts, die Admin sind auf allen Clients und ggfls. auch Servern, usw. usw. usw....

 

Das heißt für mich eigentlich, daß "Domain Admins zum Owner machen" nicht wirklich die Lösung ist, oder? Weil joinen können muß ich ja trotzdem noch, also die alten Bedingungen (Schreibzugriff) sind hoffentlich noch in Kraft?

[cj_berlin 1.306]

vor 2 Stunden schrieb daabm:

 

Das heißt für mich eigentlich, daß "Domain Admins zum Owner machen" nicht wirklich die Lösung ist, oder? Weil joinen können muß ich ja trotzdem noch, also die alten Bedingungen (Schreibzugriff) sind hoffentlich noch in Kraft?

Sind sie. Mein Szenario wäre, dass ich an das Join-Account komme, weil es in der Software-Verteilung im Klartext hiterlegt ist.