Jump to content

Zusammenspiel AD und LAPS


Recommended Posts

Hallo zusammen,

 

wir wollen in unserer Firma eine Password Policy umsetzen und wollen als Hilfe Local Administrator Password Solution (LAPS) installieren.
Allerdings wissen wir nicht, was LAPS per Default alles im AD installiert/konfiguriert.
Weiss da jemand Bescheid? Wir wollen unser AD nicht zerschießen.

 

Viele Grüße
Sebastian

Link to post

Moin,

per Default installiert LAPS "im AD" gar nix. Installieren tust Du nur eine DLL (GPO client side extension) auf jedem Rechner, deren lokaler Administrator mit LAPS gemanagt werden soll. Vielleicht noch die Mini-GUI auf den Management-PCs für den Service Desk zum Nachschauen des Kennwort.

 

Im AD musst Du:

  • das Schema erweitern, damit die LAPS-Attribute überhaupt erscheinen (LAPS PowerShell-Modul)
  • Die Computer in den betroffenen OUs berechtigen, diese Attribute für das eigene Computer-Objekt zu beschreiben (LAPS PowerShell-Modul)
  • Die geeigneten Benutzer-Gruppen auf OU-Basis berechtigen, diese Attribute aus den Computer-Objekten zu lesen (LAPS PowerShell-Modul)
  • die ADMX-Vorlage in den Central Policy Store kopieren
  • Gruppenrichtlinien definieren, welche das Verhalten von LAPS auf den Zielcomputern steuern.
Edited by cj_berlin
Link to post

Die dokus die bei laps mitgeliefert werden sind für ms Verhältnisse super. Hast du die denn mal gelesen?

 

abgesehen davon hilft laps nur für bei lokalen adminkonten (deswegen auch der Name), mit einer passwortrichtlinie hat das wenig zu tun; im ad dann eigentlich nix.

Link to post
vor 5 Stunden schrieb testperson:

wenn es verschlüsselt sein soll: AdmPwd.E (ADMPWD - GreyCorbel)

Spannend. Hat es schon jemand im Einsatz? Meine Industrie- und Finanzkunden schwanken meistens zwischen "Wir führen LAPS in 2022 ein" und "Bei uns gibt es keine (dauerhaft aktiven) lokalen Adminkonten."

 

Da dieser Password Decryption Service sowieso bei jeder Operation kontaktiert werden muss und somit den Single Point of Bottleneck darstellt, frage ich mich, wozu man den Ciphertext überhaupt noch im AD speichern muss, denn ohne den PDS und dessen Keystore kann man mit dem Ciphertext ja nix anfangen. Dann könnte man ja einen anderen Vault nehmen und es als Feature verkaufen, dass man das AD-Schema nicht erweitern muss ;-) In jedem Fall funktioniert das Ganze (im Gegensatz zu LAPS) nicht in einer Site, die zum Zeitpunkt der Passwortänderung von der Zentrale (wo der PDS läuft) getrennt ist.

 

Aber die Möglichkeit, das Admin-Passwort sicher (?) durch den User anfordern zu lassen ist schon nicht ganz uncool... EDIT: Sie ließe sich aber auch in ein paar Stunden für LAPS programmieren. Gibt's bestimmt sogar schon.

Edited by cj_berlin
Link to post

Moin,

 

ich ergreife die Gelegenheit, meine grundsätzlichen Bedenken gegen LAPS noch einmal anzubringen. Die Lösung ist sicher pfiffig, aber nur innerhalb enger Grenzen. Leider wird sie in der Praxis oft jenseits dieser Grenzen eingesetzt.

 

Der Sicherheitsgewinn von LAPS hängt nahezu ausschließlich an den Berechtigungen für das Kennwort-Attribut im AD. Damit das funktioniert, braucht man strenge administrative Prozesse, die sinnvoll regeln, wer auf diese Kennwörter nun zugreifen darf. An der Stelle sehe ich in der Praxis Nachlässigkeiten - und schon hat man nicht mehr, sondern weniger Sicherheit, indem man Anwendern, die es eigentlich nicht können sollten, die Kennwörter auf dem Silbertablett darreicht. Und damit natürlich auch Angreifern.

Und dann kommen schnell Jenseits-der-Grenze-Ideen dazu wie der Klassiker "Adminrechte temporär vergeben, indem man dem User das lokale Kennwort gibt und es gleich danach per LAPS ändert".

 

Man kann LAPS sinnvoll einsetzen, aber das erfordert dann eine Sorgfalt, die in vielen Umgebungen nicht vorhanden ist.

 

Gruß, Nils

 

Link to post
vor 4 Stunden schrieb NilsK:

An der Stelle sehe ich in der Praxis Nachlässigkeiten - und schon hat man nicht mehr, sondern weniger Sicherheit, indem man Anwendern, die es eigentlich nicht können sollten, die Kennwörter auf dem Silbertablett darreicht. Und damit natürlich auch Angreifern.

Hmm also üblicherweise sollte das ja über Gruppen steuerbar sein und den „bug“ mit den Berechtigungen beim Domain join kann man auch beheben. Bleibt also nur der böse Angreifer, aber wenn der das lesen kann ist es auch schon egal.

Link to post

Moin,

 

ja, "sollte" ... aber wie das dann eben in der typischen AD-Umgebung mit solchen Gruppenmitgliedschaften ist. Und ruck-zuck ist LAPS der Hebel, der dem Angreifer den Weg vom Eindringling zum Admin ermöglicht.

Kann gutgehen, aber ich hab da eben so meine Zweifel, was den Umgang mit Berechtigungen im AD angeht. 

 

Gruß, Nils

 

Link to post
vor 3 Stunden schrieb NilsK:

ja, "sollte" ... aber wie das dann eben in der typischen AD-Umgebung mit solchen Gruppenmitgliedschaften ist. Und ruck-zuck ist LAPS der Hebel, der dem Angreifer den Weg vom Eindringling zum Admin ermöglicht.

Kann gutgehen, aber ich hab da eben so meine Zweifel, was den Umgang mit Berechtigungen im AD angeht. 

Mag alles sein. Aber was ist, wenn wir ehrlich sind, gerade in den Umgebungen, von denen Du sprichst, die Alternative? Richtig, das gleiche Admin-Kennwort auf allen Workstations (und mit etwas Pech, auch auf Servern). Und dieses hat man auch schnell in Erfahrung gebracht - fertig ist das ungehinderte lateral movement.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...