Kennwörter von lokalen Admin-Konten im Active Directory verwalten

Nicht nur die Kennwörter von Domänenbenutzern oder Domänenadministratoren müssen die IT-Verantwortlichen in ein Security-Konzept einbinden, sondern auch die Passwörter der lokalen Anmeldekonten. Hier könnte man argumentieren, dass bei Clients im Active Directory (AD) ja keine lokalen Konten genutzt werden.

Doch zumindest ein lokales Administratorkonto ist auf den Windows-Clients immer vorhanden. Dieses muss entsprechend abgesichert werden. Hier können sich die Systembetreuer auf „LAPS“ (Local Administrator Password Solution) verlassen.

Für die Installation von LAPS müssen im Vorfeld einige Voraussetzungen geschaffen werden, etwa die Verfügbarkeit des .NET-Framework (Version 4), oder der Powershell 2.0 (oder höher). Serverseitig muss mindestens die Version Server 2003 bis hin zu Server 2012 R2 vorhanden sein. Das Active Directory benötigt dabei die AD-Schema-Erweiterung. Zudem wird eine breite Palette an Client-Systemen unterstützt, von Windows Vista, Windows 7, Windows 8, Windows 8.1 sowie Windows 10. Werden diese Anforderungen erfüllt, können die Systembetreuer mit der Installation starten. Dazu wird die LAPS-Software von der entsprechenden Microsoft-Seite heruntergeladen.

Die entsprechenden Dateien werden nun auf den Server übertragen, und die Datei „LAPS x64“ mit Administratorberechtigungen gestartet. Nun findet sich der Systembetreuer im Installationsassistenten wieder. An dieser Stelle folgen die Administratoren dem Setup-Assistenten, klicken zweimal auf „Next“, prüfen ob alle Installationspakete gewählt sind und bestätigen dies mit einem Klick auf „Install“.

Software ausrollen

Nun ist es an der Zeit, die Software auf den Client-Systemen auszurollen. Dazu eignet sich eine entsprechende Richtlinie (GPO, Group Policy Object) im Active Directory, oder auch eine skriptgesteuerte Installation auf den Clients. Für die Skript-Lösung kann beispielsweise folgender Aufruf (etwa in der Kommandozeile, CMD oder der Windows Powershell, PS) eingesetzt werden:

msiexec /i <file location>LAPS.x64.msi /quiet

Hier müssen die Systembetreuer den lokalen Pfad (beziehungsweise Netzwerkpfad) zur LAPS-Anwendung entsprechend anpassen. Alternativ können die Systembetreuer auch die Datei „AdmPwd.dll“ auf die Clients kopieren und entsprechend der Windows-Registrierungsdatei hinzufügen:

regsvr32.exe AdmPwd.dll

Alternativ navigieren die Systembetreuer in die Group Policy Management Konsole und erstellen eine neue GPO in der entsprechenden Domäne, und wählen eine passende Bezeichnung. Nun bearbeiten die Administratoren die GPO (Rechte Maustaste => „Bearbeiten“) und erweitern den Verzeichnisbaum („Software settings“ => „Software installation“) und fügen mit dem Kontextmenü über „New“ ein neues Paket hinzu. An dieser Stelle wird nun der UNC-Pfad (Uniform Naming Convention) des LAPS-Pakets angegeben. Es empfiehlt sich an dieser Stelle die 64-Bit-Version anzugeben. Soll die GPO für 32-Bit-Clients angepasst werden, muss naturgemäß die 32-Bit-Installationsdatei definiert werden.

Allerdings sollten die Option „Make this 32-bit X86 application available to Win64 machines“ unbedingt deaktiviert werden. Auf diese Weise ist sichergestellt, dass 64-Bit-Systeme auch die 64-Bit-Variante erhalten. Anderenfalls kann es zu der Situation kommen, dass 64-Bit-Clients die – für sie ungeeignete – 32-Bit-Variante aufgespielt bekommen. Sind sowohl 32-Bit und 64-Bit-Systeme im AD vorhanden, müssen die Administratoren für jede Kategorie eine eigene GPO anlegen.

Die erzeugen Policies werden je nach AD-Einstellung früher oder später auf allen Systemen angewendet. Falls die Systembetreuer dies manuell etwas beschleunigen möchten, hilft folgendes Cmdlet weiter:

Gpupdate.exe

Das Microsoft Group Policy Refresh Utility kann sowohl in der Windows-Kommandozeile, als auch in der Powershell aufgerufen werden, Danach wird ein Neustart fällig, und auf den Clients können die Systembetreuer überprüfen, ob die hinzugefügte Policy sauber ausgeführt wurde. Das lässt sich etwa mit Hilfe des Controlpanels (Verwaltungskonsole => Programme und Features) prüfen. Hier sollte nun der entsprechende Eintrag erscheinen, dass LAPS installiert wurde.

AD-Schema konfigurieren

Als nächstes müssen die Administratoren sicherstellen das Active Directory entsprechend zu konfigurieren. Dazu benötigen die Systembetreuer die entsprechenden Berechtigungen – sprich mindestens sollte der Account der Gruppe „Schema Admins“ angehören. Zwei Attribute müssen die Administratoren im AD hinzufügen, um die Kennwörter abzuspeichern, und die lokalen Admin-Accounts zu verwalten. So „merkt“ sich das AD auch die entsprechenden Anmeldedaten (Zeitpunkt des letzten erfolgreichen Logins oder zu welchen Zeitpunkt das Kennwort gemäß der gesetzten Richtlinien ablaufen wird). Dazu werden folgende zwei Optionen benötigt:

• • ms-Mcs-AdmPwd
  • ms-Mcs-AdmPwdExpirationTime

Das erste Attribut speichert das jeweiligen lokale Admin-Passwort im Klartext, das zweite den Zeitpunkt, an dem das Kennwort zurückgesetzt wird. Um das AD-Schema entsprechend zu erweitern, wird ein Powershell-Modul benötigt. Dieses kann auf unterschiedliche Weisen importiert werden. Am schnellsten ist dies in der Powershell selbst möglich. Dazu öffenen die Administratoren ein PS-Fenster mit Administratorberechtigungen und nutzen folgende Cmdlets:

Import-module AdmPwd.PS
Update-AdmPwdADSchema

Aufruf der beiden Befehle sollten die Systembetreuer jeweils eine Bestätigung (Ausgabe: „Success“) erhalten. Besondere Vorsicht ist allerdings auf einem Read-Only-Domain-Controller (RODC) geboten. Microsoft hat dazu einen entsprechenden Leitfaden bereitgestellt

Im nächsten Schritt gewährt der Systembetreuer die entsprechenden Berechtigungen, um die Kennwörter zu aktualisieren – mit Hilfe des Cmdlets „Set-AdmPwdComputerSelfPermission“. Dazu ist es nötig, die Schreibberechtigung bei den Attributen „AdmPwdExpirationTime“ und „ms-Mcs-AdmPwd“ anzupassen. Das lässt sich mit folgenden Befehl in der Powershell sicherstellen:

Set-AdmPwdComputerSelfPermission -OrgUnit <Name der OU >

An dieser Stelle ist es wichtig, die korrekte Organisationseinheit (OU) zu definieren, in denen sich die jeweiligen Client-Computer-Objekte befinden. Sind diese auf mehrere OUs verteilt, muss dieser Befehl für jede weitere OU nochmals angepasst und erneut aufgerufen werden.

Aus Sicherheitsgründen müssen die erweiterten Berechtigungen wieder eingeschränkt werden, denn die Kennwörter werden wie bereits erwähnt im Attribut „ms-Mcs-AdmPwd“ im Klartext abgespeichert. Somit muss sichergestellt werden, dass keine unbefugten Benutzer oder AD-Gruppen auf diese Informationen Zugriff erlangen können. Auch an dieser Stelle müssen die folgenden Schritte wiederholt werden, wenn sich die Computer-Konten in unterschiedlichen OUs befinden:

• ADSIEdit (ADSI-Bearbeitung) starten

• Rechtsklick auf die entsprechende OU und den Reiter „Eigenschaften“ öffnen,
• den Menüpunkt „Sicherheit“ auswählen,
• Linksklick auf „Erweitert“,

die entsprechende Gruppe (oder einzelne User) auswählen (die keine Leseberechtigung erhalten sollen) und über die Schaltfläche „Bearbeiten“ die Berechtigungen deaktivieren.

Ob die Berechtigungen nach Wunsch angepasst wurden, können die Systembetreuer die jeweilige Zuweisung auch in der Powershell prüfen, dazu lässt sich folgendes Cmdlet nutzen:

Find-AdmPwdExtendedrights -identity “OU NAME”

Bei der Ausgabe werfen die Administratoren einen Blick auf die unter „ExtendetRightHolders“ aufgeführten Gruppen und User. Diese verfügen über die Berechtigungen, um die im Klartext gespeicherten Admin-Kennwörter auszulesen.Nun ist es nötig, den „normalen“ Benutzern die passenden rechte zuzuweisen, und die lokalen Computer-Kennwörter wiederherzustellen. Dazu wird das PS-Cmdlet „Set-AdmPwdReadPasswordPermission“ eingesetzt:

Set-AdmPwdReadPasswordPermission -OrgUnit <Name der OU> -AllowedPrincipals <Benutzernamen oder Gruppen>

Unter „Status“ sollte nun der Wert „Delegated“ ausgegeben werden, um die korrekte Durchführung des Befehls anzuzeigen.

Gruppenrichtlinien für LAPS konfigurieren

Im nächsten Schritt öffnen die Systembetreuer die Management-Konsole für die Gruppenrichtlinien, und fügen die Kennwortrichtlinien hinzu. Dies lässt sich beispielsweise über eine neue Policy erzeugen, etwa über einen Rechtsklick auf die entsprechende OU („Create a GPO in this domain…“). Die passenden Voreinstellungen finden die Systembetreuer im Ordner „administrative Vorlagen“ im Untermenü „LAPS“. An dieser Stelle muss der Eintrag „Enable local admin password management“ aktiviert werden.

Im nächsten Schritt werden die Kennwort-Einstellungen selbst vorgenommen – damit ist vor allem die nötige Komplexität (mindestens 14 Zeichen in der Standard-Einstellung), sowie die regelmäßige Passwort-Änderung (alle 30 Tage) gemeint. Je nach Unternehmensrichtlinie können diese Parameter angepasst werden. Nun könnten die Systembetreuer einwenden, diese lokalen Admin-Passwörter werden selten genutzt, und sollten daher „einigermaßen“ sicher sein, folglich ist eine regelmäßige Aktualisierung nicht zwingend erforderlich. Auf der anderen Seite lassen sich derartige Kennwort-Änderungen auch automatisiert durchführen – und somit (hoffentlich) die Kennwortsicherheit erhöhen.

Auch hier können die Systembetreuer mit Hilfe der Powershell die getätigten Einstellungen schnell und effektiv überprüfen. Dazu kommt beispielsweise folgendes Cmdlet zum Einsatz:

Import-Module AdmPwd.PS
Get-AdmPwdPassword -Computername “Hostname“

Aber auch in der grafischen Oberfläche lassen sich die Passworteinstellungen entsprechend auslesen. Dazu starten die Systembetreuer die Datei „AdmPwd.UI“ mit administrativen Berechtigungen. Diese Datei ist unter „C.\Program files“ im „LAPS-Ordner“ zu finden. Hier ist noch der entsprechende Hostname einzugeben, und das entsprechende Kennwort wird angezeigt (entsprechende Berechtigungen vorausgesetzt).

Florian Huttenloher