In diesem Teil der Serie geht es um lokale Administratorenkennwörter auf Servern. In vielen Unternehmen wird auf allen Windows Servern dasselbe Kennwort für das lokale Administratorkonto verwendet. Dieses Kennwort ist häufig relativ vielen Mitarbeitern und nicht selten auch ehemaligen Angestellten des Unternehmens oder deren Dienstleistern bekannt. Wird das Kennwort doch regelmäßig geändert, wird die Kennwortänderung häufig mit eigenentwickelten Lösungen auf Basis von Scripten oder Group Policies durchgeführt. Das Kennwort wird dort im Klartext oder verschleiert lokal gespeichert und das Administratorkennwort bleibt für eine hohe Anzahl von Systemen dasselbe.

Microsoft bietet dafür die Lösung Local Administrator Password Solution (LAPS) als kostenlosen Download an. Diese ermöglicht die Vergabe individueller Kennwörter und deren automatisierte Änderung für das lokale Administratorenkonto auf Windows-Systemen.

Die Funktionsweise von LAPS

Die Lösung besteht aus verschiedenen Bestandteilen. Die Kennwörter werden in einem Attribut im Active Directory gespeichert, das über eine ACL geschützt ist, so dass nur berechtigte Konten das Kennwort auslesen können. Dazu ist eine Erweiterung des Active Directory Schemas notwendig, die die Attribute ms-Mcs-AdmPwd und ms-Mcs-AdmPwdExpirationTime zur Klasse Computer hinzufügt.

Auf den Windows-Systemen wird eine Group Policy Client Side Extension (CSE) installiert. Über CSEs lässt sich die Funktionalität von Group Policies beinahe beliebig erweitern. CSEs werden als DLL implementiert und in der Windows Registry unter HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions registriert. Die CSE wird dann von der Group Policy Engine geladen und liest zunächst das Attribut ms-Mcs-AdmPwdExpirationTime, in dem das Ablaufdatum des Kennworts gespeichert wird, aus. Wenn das Ablaufdatum älter als das aktuelle Datum ist, wird ein neues Kennwort nach über Gruppenrichtlinieneinstellungen konfigurierbare Komplexitätskriterien erzeugt. Zudem validiert die CSE das Kennwort gegenüber den Komplexitätsrichtlinien der Domäne. Die CSE schreibt das neue Kennwort im Klartext in das Attribut ms-Mcs-AdmPwd und das neue Ablaufdatum in das Attribut ms-Mcs-AdmPwdExpirationTime. Nach dem Aktualisieren der beiden Attribute wird das neue Kennwort für das lokale Konto geändert.

Installation und Konfiguration von LAPS

Für die Installation von LAPS sind grundsätzlich die folgenden Schritte notwendig:

1.Installieren der LAPS Management Tools auf einem Management Computer. Idealerweise werden zur Administration Privileged Admin Workstations (PAW) genutzt und die LAPS Management Tools dort installiert. Solltet Ihr noch keine PAWs nutzen, müsst Ihr Euch für weitere Informationen leider bis Teil 7 dieser Serie gedulden 😊. Die LAPS-Installation beinhaltet eine Fat Client UI, ein PowerShell-Modul und das Group Policy Template admx. Wenn ein Central Store für Administrative Group Policy Templates verwendet wird, muss die Datei AdmPwd.admx auch dorthin kopiert werden.

2. LAPS erfordert eine Erweiterung des Active Directory Schemas. Dazu muss das ausführende Konto Mitglied der Gruppe Schema Admins Dazu wird das Cmdlet Update-AdmPwdADSchema verwendet. Das PowerShell-Modul kann aus dem Installationsverzeichnis $PSHOME\Modules\AdmPwd.PS auf die PAW kopiert werden. Sollten keine PAWs im Einsatz sein, kann das Modul auch einfach auf den Domain Controller kopiert werden.

3. Das Kennwort wird im Klartext im Attribut ms-Mcs-AdmPwd im Active Directory gespeichert. Daher ist es wichtig, die Berechtigungen so anzupassen, dass nur Berechtige Zugriff auf dieses Attribut haben. Die Anpassung der Berechtigungen wird dabei für jede OU, die Computer-Objekte für Windows-Server beinhaltet durchgeführt. Eine ausführliche Beschreibung der notwendigen Schritte findet sich in Kapitel 6.2 im Dokument Local Administrator Password Management – Detailed Technical Specification, das im LAPS-Download enthalten ist.

4. LAPS beinhaltet auch eine administrative Vorlage (AdmPwd.admx), damit lassen sich die LAPS Client Einstellungen wie gewohnt mit den Group Policy-Werkzeugen verwalten. Der Name des lokalen Administratorkontos kann über die Einstellung Enable local admin password management konfiguriert werden. Ist diese Einstellung nicht aktiviert, wird per Default das Konto mit der Well-Known Security ID 500 verwendet. Dies ist in jeder Windows-Installation unabhängig von der Sprache der Windows-Version immer das lokale Konto BUILTIN\Administrator.

Die Einstellungen lassen sich auch theoretisch direkt in der Windows Registry in HKLM\SOFTWARE\Policies\Microsoft Services\AdmPwd vornehmen. Diese sind im Dokument Local Administrator Password Management – Detailed Technical Specification beschrieben.

5. Die Group Policy CSE muss auf allen Systemen, auf denen das lokale Administratorkennwort geändert werden soll, installiert werden. Dabei wird die Datei dll nach %ProgramFiles%\LAPS\CSE\ kopiert und im System registriert. Mit regsvr32.exe lässt sich die DLL auch nachträglich registrieren.

Typischerweise wird diese automatisiert mit einer Management Suite wie Microsoft Endpoint Configuration Manager installiert, kann aber auch mit Hilfe von Group Policies installiert werden.

6. Empfehlenswert ist es, das Auditing der Leseoperationen auf das Attribut ms-Mcs-AdmPwd im Security Event Log, wie in Kapitel 5.3 des LAPS Operation Guides beschrieben, zu protokollieren.

Die Installation und Konfiguration ist detailliert in der LAPS-Dokumentation beschrieben, in der Technet Gallery findet Ihr auch eine ausführlich beschriebene Anleitung.

Sicherheit von LAPS

Oft fragen uns Kunden, ob LAPS sicher ist. An dieser Stelle möchten wir für euch die wichtigsten Informationen dazu zusammenfassen.

Speicherung und Übertragung des Kennworts

Das Kennwort des lokalen Administratorkontos wird im Attribut ms-Mcs-AdmPwd des Computer-Objekts im Klartext gespeichert. Das Attribut wird mit einer ACL geschützt und damit haben, sofern korrekt konfiguriert, nur berechtigte Personen Zugriff auf das Kennwort. Microsoft begründet die Entscheidung damit, dass eine Verschlüsselung eine erheblich höhere Komplexität der Lösung nach sich gezogen hätte, weil aufwändige Mechanismen zur Verteilung und Absicherung der Schlüssel implementiert hätten werden müssen. Der Schutz durch ACLs ist für die meisten Umgebungen ausreichend, dies muss jedoch jedes Unternehmen anhand der vorhandenen Sicherheitsanforderungen selbst bewerten.

Das Kennwort wird über einen mit Kerberos Encryption geschützten Kanal an den Domain Controller übermittelt und kann damit nicht einfach mit einem Netzwerk-Sniffer wie Wiresharek ausgelesen werden.

Ein weiteres Szenario, das es zu beachten gilt: Der Benutzer, der ein Windows-System in die Domäne „joined“, wird per Default als Owner im Computer-Objekt eingetragen und hat damit vollständige Berechtigungen auf dem Computer-Objekt und kann das in ms-Mcs-AdmPwd gespeicherte Klartext-Kennwort auslesen. In Enterprise-Umgebungen wird normalen Benutzern das Recht, Computer in die Domäne zu joinen in der Regel entzogen. Sollte das bei Euch doch gewünscht sein, ist es sinnvoll, die Domain Admin Gruppe per Skript als Owner auf allen Objekten zu setzen.

Client-Server-Kommunikation

Ein Artikel der Sicherheitsfirma Praetorian beschreibt eine Man-in-the-Middle-Attacke, bei der die LDAP-Session von Help Desk-Mitarbeitern zu einem „rogue“ Server umgeleitet wird, der dann die Klartext-Kennwörter abfangen kann. Als Gegenmaßnahme empfiehlt der Artikel, LDAP Signing per Group Policies zu aktivieren. Eine weitere Möglichkeit ist, die Konten der Help Desk-Mitarbeiter in die Gruppe Protected Users aufzunehmen. Mitglieder dieser Gruppe können sich nicht per NTLM authentifizieren. Allerdings kann das je nach Umgebung und verwendeter Applikationen zu Nebenwirkungen führen, weshalb dieses Szenario auf alle Fälle getestet werden muss.

Microsoft versucht schon seit 2019 (ADV190023), das Thema LDAP Signing zu pushen. Unsere Erfahrung zeigt allerdings, dass die Umstellung nicht schnell und einfach durchzuführen ist. Wer sich noch nicht damit beschäftigt hat, sollte zeitnah damit anfangen.

Client-Komponenten

Wird die Group Policy CSE AdmPwd.dll nicht per MSI, sondern manuell installiert, ist es wichtig, diese in ein nicht von einem nicht-administrativen Benutzer beschreibbaren Verzeichnis zu installieren. Sonst lässt sich diese mit einer eigenen DLL überschreiben, die das Kennwort im Klartext „abfängt“, um dieses missbräuchlich zu verwenden. Ein Angreifer, der es geschafft hat, administrative Berechtigungen auf dem lokalen System zu erlangen, kann dieses Szenario auch nutzen, um seinen administrativen Zugang zu persistieren. Eine Demonstration von diesem Angriff haben Maxime Clementz und Antoine Goichot auf einem Hack.lu Talk gezeigt.

Der Vollständigkeit halber wollen wir auch die Sicherheitslücke CVE-2014-1814 aus dem Jahr 2014 erwähnen. Die Lücke im Windows Installer Service ermöglicht es einem Angreifer, mittels Repair-Funktion eine bestehende Applikation zu überschreiben, sofern die MSI von einer vom Benutzer beschreibbaren Lokation installiert wurde. Die Lücke wurde gepatched und ist nach Windows 8 / 2012 R2 nicht mehr vorhanden und sollte somit für neue Installationen nicht mehr relevant sein.

Aus unserer Sicht ist LAPS bei korrekter Konfiguration sicher und wesentlich besser als die “klassischen” Alternativen.

Real-World-Erfahrungen

Im tagtäglichen Betrieb von LAPS kann es vorkommen, dass man auf folgendes Problem stößt. Nehmen wir mal an, wir müssen ein Backup zurückspielen, das schon etwas älter ist. Zwischen dem Backup und heute wurden automatisch sowohl das Kennwort des Computer Accounts als auch das LAPS-Kennwort geändert. Nach dem Restore stellt man fest, dass man sich nicht mittels Domänenaccount anmelden kann, weil die Vertrauensstellung zwischen dem Computer und der Domäne nicht mehr funktioniert. Versucht man sich nun mit dem im AD gespeicherten LAPS-Kennwort anzumelden, funktioniert auch das nicht, weil diese auch nicht übereinstimmen. Man hat effektiv keine Möglichkeit mehr, sich am System anzumelden.

Wir sehen für dieses Problem zwei Lösungen. Entweder, man überschreibt das lokale Administratorkennwort mit Tools wie der Ultimate Boot CD oder man schreibt die LAPS-Kennwörter per Script regelmäßig in eine Datei auf dem Domain Controller. Klingt erstmal unsicher, wenn es ein Angreifer allerdings schon auf den Domain Controller geschafft hat, ist die Sicherheit der lokalen Administratorkennwörter in der Regel das kleinste Problem.

Wem das zu umständlich ist, kann einen Blick auf AdmPwd.E werfen. Das Produkt ist vom ursprünglichen Entwickler von LAPS und LAPS konzeptionell sehr ähnlich, allerdings um einige nützliche Funktionen wie einer Kennwort-Historie erweitert. Aber auch hier gibt es einen Wehrmutstropfen: AdmPwd.E ist leider nicht kostenfrei.

Zusammenfassung

Insgesamt ist LAPS eine sichere, robuste und kostenlose Lösung für das Management der lokalen Administratorkennwörter, wenn auch mit kleineren Einschränkungen. Es nutzt die vorhandenen Komponenten des Active Directory und erfordert damit keine separate Infrastruktur und Training für die Administration. Berechtigungen für das Lesen und Zurücksetzen der Kennwörter können flexibel und granular an beliebige Gruppen und Benutzer vergeben werden.

Wenn euch der Artikel gefallen hat, könnt Ihr euch schon auf den nächsten Teil der Serie zum Thema Privileged Admin Workstation (PAW) freuen.