der-phil
Goto Top

Lokale User Passworte im AD - Best Practice

Hallo!

Seit Jahren wird bei mir über eine GPO das lokale Admin-Passwort an jedem Rechner beim Eintritt in das AD geändert. Da dieses Passwort ja scheinbar im AD auslesbar war, hat Microsoft diese Möglichkeit mit Hinweis auf "CPassword" ja entfernt in MS14-025.


Zur eigentlichen Frage:
Was ist die Alternative?
Wie löst ihr das?

Was ich bisher gefunden, aber nicht getestet habe:

- Powershell Skripte - Hier kann wohl ein Passwort erst verschlüsselt und dann gesetzt werden.
- LAPS - setzt für jeden Client ein eigenes Passwort und hinterlegt dieses im Klartext im AD. Für mich klingt das gefährlich, wenn irgendwann einmal das Recht "All extended rights" aus Versehen auf eine OU gesetzt bzw nicht entfernt wird, kann das Passwort gelesen werden. Beim Entfernen aus dem AD muss man unbedingt daran denken, das Passwort zuvor auszulesen, sonst sitzt man in der Sackgasse...


Danke und Grüße
Phil

Content-Key: 340978

Url: https://administrator.de/contentid/340978

Ausgedruckt am: 29.03.2024 um 02:03 Uhr

Mitglied: emeriks
emeriks 19.06.2017 um 09:31:59 Uhr
Goto Top
Hi,
Seit Jahren wird bei mir über eine GPO das lokale Admin-Passwort an jedem Rechner beim Eintritt in das AD geändert. Da dieses Passwort ja scheinbar im AD auslesbar war, hat Microsoft diese Möglichkeit mit Hinweis auf "CPassword" ja entfernt in MS14-025.
Du sprichst von Passwort via GPO/GPP setzen. Ja, das ist out. Allerdings stand das Passwort hier nicht im AD sondern im SYSVOL.

- LAPS - setzt für jeden Client ein eigenes Passwort und hinterlegt dieses im Klartext im AD. Für mich klingt das gefährlich, wenn irgendwann einmal das Recht "All extended rights" aus Versehen auf eine OU gesetzt bzw nicht entfernt wird, kann das Passwort gelesen werden.
LAPS ist eine gute Wahl. Lies einfach die Doku dazu. Wenn man sich daran hält, dann ist da nichts gefährliches.
Beim Entfernen aus dem AD muss man unbedingt daran denken, das Passwort zuvor auszulesen, sonst sitzt man in der Sackgasse...
Das Computer-Objekt wird beim Domänen-Austritt nur deaktiviert, nicht gelöscht.

E.
Mitglied: DerWoWusste
DerWoWusste 19.06.2017 aktualisiert um 09:43:21 Uhr
Goto Top
Hi.

Schau Dir meinen Artikel an: Sicherer Umgang mit Supportkonten - das ist meiner Meinung nach viel vernünftiger als LAPS.
Noch ein Hinweis zu "Da dieses Passwort ja scheinbar im AD auslesbar war, hat Microsoft diese Möglichkeit mit Hinweis auf "CPassword" ja entfernt in MS14-025." - MS hat die Möglichkeit entfernt, neue GPOs mit eingebautem Kennwort zu erstellen - die Möglichkeit, aus den alten GPOs Kennwörter auszulesen, besteht jedoch weiter, man muss diese GPOs also unbedingt löschen.
Mitglied: Hitman4021
Hitman4021 19.06.2017 um 14:28:23 Uhr
Goto Top
Hallo,

wir haben das mit einem Powershell Script gelöst.
Dieses generiert für jede Workstation ein eigenes Passwort und legt es in einer CSV ab, somit ist auch gleich auf jedem Rechner ein individuelles Kennwort gesetzt.

lg
Mitglied: Der-Phil
Der-Phil 20.06.2017 um 21:34:14 Uhr
Goto Top
Hallo!

Kannst Du dieses Skript posten oder mir schicken?

Danke und Grüße
Phil
Mitglied: DerWoWusste
DerWoWusste 20.06.2017 um 23:01:52 Uhr
Goto Top
Frag lieber, wie das sicher umgesetzt wird. Wie startet es, wer kann es lesen, Kennwörter im Plaintext sichtbar...
Meinen Vorschlag auch näher angesehen? Ist doch weitaus praktischer mit Domänenkonten als mit lokalen.
Mitglied: Der-Phil
Der-Phil 26.06.2017 um 10:03:32 Uhr
Goto Top
Hallo!

Tut mir Leid, dass ich so spät antworte...

Deine Anleitung kenne ich natürlich und ich finde den Ansatz auch sehr gut - weiß aber nicht, ob ich ihn für mich passend finde. Ich hätte schon gerne noch ein absolutes "Notfallpasswort", das lokal funktioniert, auch wenn keine Verbindung zum AD möglich ist.

Dein Ansatz ist perfekt, um das Problem der "allmächtigen" Domänen-Admins zu lösen, aber es gab in der Vergangenheit schon Situationen, wo ein lokaler Adminzugang nötig war.

Ich möchte Deine Lösung einsetzen, aber eben zusätzlich einen lokalen Notzugang...

Grüße
Phil
Mitglied: DerWoWusste
DerWoWusste 26.06.2017 aktualisiert um 10:15:48 Uhr
Goto Top
Ich würde auf den lokalen Zugang verzichten. Wenn benötigt, kann man immer noch die üblichen Tricks zum Zurücksetzen nutzen.
Aber gut:

Ein Startskript kann auch random-Kennwörter setzen.
In Batch:
net user /add Notfalladmin /random>\\server\share\%computername%.txt & net localgroup Administratoren /add notfalladmin
Dies legt ein Konto Notfalladmin an, schreibt das 8-Stellige Zufallskennwort in eine Datei auf dem Server und packt es in die Admingruppe. Die Freigabe auf dem Server sollte für Computerkonten write-only sein und lesbar nur für Admins.

Du kannst natürlich auch ein Powershell-Startskript dafür nehmen und den Powershell-Kennwortgenerator aus meinem Artikel, falls 8 Zeichen nicht ausreichen.
Mitglied: Der-Phil
Der-Phil 27.06.2017 um 08:38:24 Uhr
Goto Top
Hallo!

Diese Lösung finde ich interessant, würde sie aber etwas abwandeln. Das Problem ist doch:

Client hat Netzwerkprobleme, Treiberproblem oder ähnlich
--> AD-"Notadmins" funktionieren nicht mehr
--> Client hat das Passwort geändert, aber kann es nicht "wegschreiben".

Ich glaube, aber mit einer kleinen Anpassung werde ich glücklich:
Das Startskript prüft erst, ob eine Verbindung zum entsprechenden Fileserver möglich ist und NUR dann wird das Passwort geändert. Dann sollte ja auf dem Fileserver das lokale Adminpasswort zu finden sein.


Danke und Grüße
Phil
Mitglied: DerWoWusste
DerWoWusste 27.06.2017 um 08:46:36 Uhr
Goto Top
Kannst Du so machen - ich hätte gedacht, das Startskript läuft eh nur dann, wenn die Domäne verfügbar ist und Zielserver ist auch ein DC.