KB50200276 netjoin

[raymccoy 1]

https://support.microsoft.com/de-de/topic/kb5020276-netjoin-änderungen-bei-der-härtung-des-domänenbeitritts-2b65a0f3-1f4c-42ef-ac0f-1caaf421baf8

 

Kann jemand das einfach erklären wie man nun als normaler AD-User ohne Adminrechte einen anderen Laptop/PC mit Hilfe eines Domänenaccount ohne Adminrechte ins AD bringen kann?

[NilsK 2.939]

Moin,

 

was ist der Hintergrund deiner Frage? Geht es darum, dass du das ermöglichen möchtest? Oder geht es darum, das zu verhindern?

 

Die Updates, die der Artikel beschreibt, betreffen nur ein bestimmtes Szenario, nämlich das (Wieder-)Verwenden eines bestehenden Computerkontos im AD. Sie betreffen nicht den üblichen Vorgang, einen Computer erstmalig ins AD zu bringen. Das funktioniert, soweit ich das sehe, immer noch so wie vorher.

 

Gruß, Nils

 

[raymccoy 1]

es darum das man vorher ein Computerobjekt angelegt hat und dann einer anderen Person das Recht erteilt hat den PC /Laptop ins AD zu bekommen.

Das geht jetzt so nicht mehr.

 

[NilsK 2.939]

Moin,

 

und du möchtest jetzt einen Weg beschrieben bekommen, wie es geht? (Ernst gemeinte Frage, damit wir in die richtige Richtung diskutieren.)

 

Falls ja, fangen wir mal einfach an: Auf das Pre-staging (Computerkonto vorher anlegen) zu verzichten, ist in dem Szenario keine Option?

 

Gruß, Nils

 

[raymccoy 1]

Auf das Pre-Staging zu verzichten ist auch eine Option

[NilsK 2.939]

Moin,

 

okay, das ist ja schon mal ein wichtiger Punkt. Ihr könntet also (so verstehe ich das) im AD gezielt auf einer OU (oder so) einer Mitarbeitergruppe das Recht geben, Computerkonten hinzuzufügen. Diese OU könnte das Standardziel für neue Computerkonten sein. Dann betreffen euch die Hinweise in dem KB-Artikel nicht.

 

Ansonsten weist der KB-Artikel ja auch Wege auf, wie es mit dem Pre-Staging gehen kann. Da ich selbst kein AD betreibe und momentan auch keine passende Testumgebung habe, fehlen mir dort die konkreten Umsetzungserfahrungen. Aber für mich klingt es, als sollten sich die nötigen Gruppen und Policies recht einfach nutzen lassen.

 

Gruß, Nils

 

bearbeitet 25. Juli 2023 von NilsK

[daabm 1.356]

Alles lösbar, wenn die Anforderung klar formuliert wird. Wir haben uns erst mal für den Würgaround entschieden, weil zu viel Automation dran hängt...

[cj_berlin 1.323]

Genau. Der User, der den Laptop ins AD aufnehmen kann, muss am Laptop ja schon mal lokaler Administrator sein. Dann kann er auch den Registry-Wert für den Workaround setzen.

[LK28 11]

Am 25.7.2023 um 11:13 schrieb NilsK:

Moin,

 

okay, das ist ja schon mal ein wichtiger Punkt. Ihr könntet also (so verstehe ich das) im AD gezielt auf einer OU (oder so) einer Mitarbeitergruppe das Recht geben, Computerkonten hinzuzufügen. Diese OU könnte das Standardziel für neue Computerkonten sein. Dann betreffen euch die Hinweise in dem KB-Artikel nicht.

 

Ansonsten weist der KB-Artikel ja auch Wege auf, wie es mit dem Pre-Staging gehen kann. Da ich selbst kein AD betreibe und momentan auch keine passende Testumgebung habe, fehlen mir dort die konkreten Umsetzungserfahrungen. Aber für mich klingt es, als sollten sich die nötigen Gruppen und Policies recht einfach nutzen lassen.

 

Gruß, Nils

 

Moin,

 

wie ich aus vergangenen Threads herausgelesen habe, würdest du nicht uneingeschränkt LAPS empfehlen. Quasi nur dann, wenn man auch das Organisatorische durchzieht und nicht aus Bequemlichkeit die "LAPS Passwörter" an die User vergibt und dann ändert.

 

Trotzdem mal ein Gedankenspiel mit deinem Tipp der Delegation an eine Mitarbeitergruppe in Zusammenhang mit LAPS, wenn ich darf:

 

Wenn ich einer Mitarbeitergruppe (normale AD Konten) das Recht vergebe, die Computerkonten hinzuzufügen, sind sie Creater-Owner und sollten nach wie vor das Recht besitzen, das lokale Admin Passwort aus LAPS lesen zu können. Auch wenn ich diesen Konten in der LAPS Konfiguration nicht explizit das Recht dazu gegeben habe,

 

Also sollte man verhindern, dass die Konten (die Mitarbeitergruppe) sich an Clients (und Servern) anmelden dürfen?

 

 

[NorbertFe 2.045]

vor 4 Minuten schrieb LK28:

Wenn ich einer Mitarbeitergruppe (normale AD Konten) das Recht vergebe, die Computerkonten hinzuzufügen, sind sie Creater-Owner und sollten nach wie vor das Recht besitzen, das lokale Admin Passwort aus LAPS lesen zu können.

Das kann man ja verhindern, dass das so ist.

[testperson 1.680]

Hi,

  

vor 38 Minuten schrieb LK28:

Wenn ich einer Mitarbeitergruppe (normale AD Konten) das Recht vergebe, die Computerkonten hinzuzufügen, sind sie Creater-Owner und sollten nach wie vor das Recht besitzen, das lokale Admin Passwort aus LAPS lesen zu können. Auch wenn ich diesen Konten in der LAPS Konfiguration nicht explizit das Recht dazu gegeben habe,

beim native LAPS - also dem "neuen" - sollten sie dann aber "nur" das verschlüsselte LAPS Kennwort bekommen (sofern du im FFL/DFL 2016 bist), mit dem sie erstmal (AFAIK) nichts anfangen können. Wenn du beim neuen LAPS auf die Verschlüsselung verzichtest, dann können sie das Klartext PW auslesen.

 

Gruß

Jan

 

[NilsK 2.939]

Moin,

 

Da ich eure Anforderungen nicht kenne, kann ich dazu nichts weiter sagen. Irgendwelche Analogien und Logikspiele führen hier nicht zu viel, denke ich.

 

Gruß, Nils