9
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 340978
Url: https://administrator.de/contentid/340978
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
9 Kommentare
Neuester Kommentar
Hi,
E.
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.
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.
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.
1
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
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
Hallo!
Kannst Du dieses Skript posten oder mir schicken?
Danke und Grüße
Phil
Kannst Du dieses Skript posten oder mir schicken?
Danke und Grüße
Phil
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.
Meinen Vorschlag auch näher angesehen? Ist doch weitaus praktischer mit Domänenkonten als mit lokalen.
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
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
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:
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.
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 notfalladminDu kannst natürlich auch ein Powershell-Startskript dafür nehmen und den Powershell-Kennwortgenerator aus meinem Artikel, falls 8 Zeichen nicht ausreichen.
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
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
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.
