Windows LAPS und die Migration von Microsoft LAPS – Teil 2

Dies ist Teil 2 des Artikels, lesen Sie auch: Windows LAPS und die Migration von Microsoft LAPS – Teil 1.

Diese zweiteilige Artikelreihe hilft auch bei der Einrichtung von Windows LAPS, wenn Sie bisher kein Microsoft LAPS eingesetzt haben.

Deinstallieren von Legacy Microsoft LAPS

Das Legacy Microsoft LAPS wird im Verzeichnis „C:\Program Files\LAPS\CSE“ installiert. Die Installation hängt davon ab, ob LAPS als MSI installiert wurde oder ob die DLL anderweitig kopiert und registriert wurde.

Wenn es als MSI-Paket installiert wurde, kann es einfach mit dem PowerShell-Befehl deinstalliert werden:

.\msiexec.exe /x (get-wmiobject Win32_Product | ? { $_.Name -like "Local Administrator Password Solution" -and $_.Vendor -like "Microsoft Corporation"}).IdentifyingNumber /Q

Wenn die DLL manuell registriert wurde, helfen die folgenden PowerShell-Befehle:

.\regsvr32.exe /s /u "C:\Program Files\LAPS\CSE\AdmPwd.dll"
Start-sleep -seconds 10
Remove-Item "C:\Program Files\LAPS" -Recurse -Force

Nach der Prüfung empfehle ich, den neuen Windows LAPS zu installieren, indem man beispielsweise das neue Event-Log abfragt. Wenn dies erfolgreich ist, kann der Legacy LAPS deinstalliert werden und der neue LAPS übernimmt im Legacy-Modus. Anschließend kann die Migration schrittweise durchgeführt werden.

Umstellen auf Windows LAPS Modus

Für die Umstellung müssen einige Vorbereitungen getroffen werden. Um die LAPS PowerShell-Module nutzen zu können, muss das Update für Windows LAPS installiert sein. Zusätzlich zur Aktualisierung der Gruppenrichtlinienvorlagen muss auch das Active Directory Schema aktualisiert werden.

Aktualisierung des Active Directory Schema

Um auf Windows LAPS umzusteigen, muss das Microsoft Active Directory angepasst werden. Dazu muss ein Server auf die neueste Version aktualisiert werden, um über die notwendigen Dateien und PowerShell-Module zu verfügen.

Anschließend steht das entsprechende PowerShell-Modul „LAPS“ zur Verfügung.

Die folgenden Schritte müssen in der PowerShell mit administrativen Rechten ausgeführt werden. In diesem Fall sollten die Schritte direkt auf dem Domänencontroller ausgeführt werden, der auch die FSMO-Rolle Schemamaster innehat. Der Benutzer muss außerdem Mitglied der Gruppe „Schema Admins“ sein.

Führen Sie den Befehl „Update-LapsADSchema“ aus, um die notwendigen Änderungen am AD-Schema für Windows LAPS durchzuführen.

Nach der Aktualisierung des Schemas müssen die Berechtigungen im Active Directory für das neue LAPS noch korrekt gesetzt werden.

Aktualisierung der Berechtigung für die Computer

Um sicherzustellen, dass die Computerkonten über die erforderlichen Berechtigungen verfügen, müssen sie mit dem Befehl „Set-LapsADComputerSelfPermission -Identity (Get-ADDomain).DistinguishedName“ konfiguriert werden. Hierbei kann entweder eine einzelne Organisationseinheit (OU) oder die gesamte Domäne ausgewählt werden. Da ich LAPS in der gesamten Domäne einsetzen möchte, wähle ich die Option für die gesamte Domäne. Ich steuere die Migration, indem ich den neuen Modus über die OU-Struktur und die Verknüpfung der Gruppenrichtlinie aktiviere.

Setzten der Berechtigung zum Lesen der Kennwörter

Zusätzlich muss die Berechtigung zum Lesen der Passwörter auf OU-Ebene gesetzt werden. Hierfür wird der Befehl ‚Set-LapsADReadPasswordPermission‘ verwendet. Es ist möglicherweise erforderlich, eine granulare Vorgehensweise zu wählen, wenn eine Domäne ein AD-basiertes RBAC-Konzept verwendet. In diesem Fall müssen für jede Organisationseinheit (OU) individuelle Berechtigungen gesetzt werden. In meiner sicheren Testumgebung habe ich es in zwei Gruppen mit dem Befehl

Set-LapsADReadPasswordPermission -Identity (Get-ADDomain).DistinguishedName -AllowedPrincipals "Domain Admins", "IFHLAPS\OGA--T1Accounts"

aufgeteilt.

Hierbei handelt es nicht um die im nächsten Kapitel behandelte Passwortverschlüsselung, die per GPO gesteuert wird. Die Gruppen sollten jedoch identisch oder verschachtelt sein. Ein Lesezugriff allein hilft nicht, wenn das Passwort nicht entschlüsselt werden kann.

Nachdem die Berechtigungen gesetzt wurden, kann auch die Gruppenrichtlinie konfiguriert werden. In einem der vorangegangenen Schritte wurden bereits die neuen GPO-Vorlagen in den Gruppenrichtlinien-Central-Store kopiert.

Die Möglichen Gruppenrichtlinien Einstellungen für Windows LAPS im Überblick

Die neuen Einstellungen für LAPS in der Gruppenrichtlinie befinden sich unter Computer Configuration / Policies / Administrative Templates / System / LAPS. Hier sind die Einstellungen im Detail aufgeführt.

Enable password backup for DSRM accounts

Das Beste für die Sicherheit von Active Directory. Die meisten Unternehmen ändern ihr Directory Service Recovery Mode „DSRM“ Kennwort nie und sind verwundbar für Angriffe geben den Domänenkontroller, wenn Konsolenzugriff vorhanden ist. Weitere Informationen zu den Gefahren und Auswirkungen finden Sie in dem Artikel „Active Directory Service Recovery Mode (DSRM)“

Configure size of encrypted password history

Mit dieser Einstellung können Sie festlegen, wie viele verschlüsselte Kennwörter in Active Directory gespeichert werden sollen.

Die Konfiguration dieser Einstellung hat keine Auswirkungen, es sei denn, das Kennwort wurde so konfiguriert, dass es in Active Directory gespeichert wird und die Kennwortverschlüsselung wurde aktiviert.

Wenn diese Einstellung aktiviert ist, werden die angegebenen Anzahl älterer Kennwörter in Active Directory gespeichert.

Wenn diese Einstellung deaktiviert oder nicht konfiguriert ist, werden keine älteren Kennwörter in Active Directory gespeichert.

Gültige Werte sind 0-12 Kennwörter.

Enable password encryption

Durch Aktivierung dieser Einstellung wird das verwaltete Kennwort vor der Übertragung an Active Directory verschlüsselt.

Die Einstellung hat jedoch nur dann eine Auswirkung, wenn das Kennwort für die Sicherung in Active Directory konfiguriert wurde und die Funktionsstufe der Active Directory-Domäne Windows Server 2016 oder höher ist.

Wenn die Domänenfunktionsstufe von Windows Server 2016 oder höher ist und diese Einstellung aktiviert ist, wird das Kennwort des verwalteten Kontos verschlüsselt.

Wenn die Domänenfunktionsstufe niedriger als Windows Server 2016 ist und diese Einstellung aktiviert ist, wird das Kennwort des verwalteten Kontos nicht im Verzeichnis gesichert.

Wenn diese Einstellung deaktiviert ist, wird das Kennwort des verwalteten Kontos nicht verschlüsselt.

Diese Einstellung ist standardmäßig aktiviert, wenn sie nicht konfiguriert ist.

Um sicherzustellen, dass die Einstellung nicht lokal über einen Reg-Key geändert werden kann, sollte sie immer aktiviert sein, sofern die Voraussetzungen erfüllt sind.

Configure authorized password decryptors

Konfigurieren Sie diese Einstellung, um festzulegen, welche Benutzer oder Gruppen berechtigt sind, verschlüsselte Kennwörter zu entschlüsseln.

Beachten Sie, dass diese Einstellung nur wirksam ist, wenn die Kennwortverschlüsselung aktiviert ist.

Wenn die Einstellung aktiviert ist, können Mitglieder der angegebenen Gruppe verschlüsselte Passwörter entschlüsseln.

Wenn diese Einstellung deaktiviert oder nicht konfiguriert ist, können Mitglieder der Gruppe ‚Domain Admins‘ verschlüsselte Kennwörter entschlüsseln.

Die Einstellung muss entweder mit einer SID im String-Format (‚S-1-5-21-2127521184-1604012920-1887927527-35197‘) oder dem Namen einer Gruppe oder eines Benutzers im Format ‚domain\(Gruppe oder Benutzer)‘ konfiguriert werden. Der angegebene Benutzer oder die Gruppe muss vom verwalteten Gerät aufgelöst werden können. Andernfalls werden die Kennwörter nicht gesichert.

Wenn Sie einzelne Services in eigene RBAC-Strukturen im AD abbilden, sollten hier nur die Gruppen der entsprechenden Service-Admins aufgenommen werden. Das bedeutet auch, dass es in solchen Fällen nicht ‚die eine Gruppe‘ gibt, sondern diese abhängig vom Dienst ist. Je nach GPO-Design sollten Sie diese Einstellung in den individuellen RBAC-GPOs der jeweiligen Dienste setzen und nicht in der Standard-Windows-LAPS-Richtlinie.

Name of administrator account to manage

Diese Richtlinieneinstellung definiert den Namen eines benutzerdefinierten Administratorkontos, für den das Kennwort verwaltet werden soll.

Wenn diese Einstellung aktiviert ist, verwaltet LAPS das Kennwort für ein lokales Konto mit diesem Namen.

Wenn diese Einstellung deaktiviert oder nicht konfiguriert ist, verwaltet LAPS das Kennwort für das bekannte Administratorkonto.

Es wird empfohlen, diese Richtlinieneinstellung NICHT zu aktivieren, um das integrierte Administratorkonto zu verwalten. Das integrierte Administratorkonto wird automatisch erkannt, da es anhand der bekannten SID identifiziert wird und nicht vom Kontonamen abhängt.

Configure password backup directory

Verwenden Sie diese Einstellung, um das Verzeichnis zu konfigurieren, in dem das Passwort des lokalen Administratorkontos gesichert werden soll.

Es gibt drei zulässige Einstellungen:

0 = Deaktiviert (das Passwort wird nicht gesichert),
1 = Das Kennwort wird in Azure Active Directory gesichert,
2 = Kennwort im Active Directory sichern.

Wenn keine Einstellung angegeben wird, wird diese standardmäßig auf 0 (Deaktiviert) gesetzt.

Wenn die Einstellung auf 1 konfiguriert ist und das verwaltete Gerät nicht mit Azure Active Directory verbunden ist, wird das lokale Administratorkennwort nicht verwaltet.

Wenn die Einstellung auf 2 konfiguriert ist und das verwaltete Gerät nicht mit Active Directory verbunden ist, wird das lokale Administratorkennwort ebenfalls nicht verwaltet.

Wenn die Einstellung deaktiviert oder nicht konfiguriert ist, wird das lokale Administratorkennwort ebenfalls nicht verwaltet.

Do not allow password expiration time longer than required by policy

Wenn diese Einstellung nicht aktiviert oder konfiguriert ist, ist es nicht erlaubt, ein Kennwort zu verwenden, das älter ist als das in der Richtlinie „Kennworteinstellungen“ festgelegte Kennwortalter. Wenn ein solches Kennwort erkannt wird, wird es sofort geändert und der Ablauf des Kennworts wird entsprechend der Richtlinie festgelegt.

Wenn diese Einstellung deaktiviert ist, kann die Ablaufzeit des Kennworts länger sein als in der Richtlinie ‚Kennworteinstellungen‘ vorgeschrieben.

Password Settings

Konfiguriert die Passwortparameter:

Passwortkomplexität: Welche Zeichen werden bei der Generierung eines neuen Passworts verwendet

Voreinstellung: Großbuchstaben + Kleinbuchstaben + Zahlen + Sonderzeichen

Passwort-Länge

Minimum: 8 Zeichen
Maximum: 64 Zeichen
Standard: 14 Zeichen

Passwortalter in Tagen

Minimum: 1 Tag (7 Tage, wenn das Backup-Verzeichnis als Azure AD konfiguriert ist)
Maximal: 365 Tage
Standard: 30 Tage

Post-authentication action

Diese Richtlinie legt fest, welche Aktionen nach der Authentifizierung ausgeführt werden, sobald eine Authentifizierung durch das verwaltete Konto erkannt wurde. Die Karenzzeit gibt an, wie viele Stunden gewartet werden, bevor die angegebenen Aktionen nach der Authentifizierung ausgeführt werden. Wenn die Karenzzeit größer als Null ist und diese Einstellung aktiviert ist, werden die angegebenen Post-Authentifizierungsaktionen nach Ablauf der Karenzzeit ausgeführt.

Wenn diese Einstellung deaktiviert oder nicht konfiguriert ist, werden die angegebenen Postauthentifizierungsaktionen nach einer Standardfrist von 24 Stunden ausgeführt.

Wenn diese Einstellung auf Null gesetzt ist, werden keine Aktionen nach der Authentifizierung ausgeführt. Die Aktionen, die nach Ablauf der Karenzzeit ausgeführt werden sollen, sind das Zurücksetzen des Kennworts des verwalteten Kontos. Nach Ablauf der Karenzzeit wird das Kennwort des verwalteten Kontos zurückgesetzt und alle interaktiven Anmeldesitzungen mit dem verwalteten Konto werden beendet.

Es ist zu beachten, dass nach der Beendigung interaktiver Anmeldesitzungen noch andere authentifizierte Sitzungen bestehen können, die vom verwalteten Konto verwendet werden. Um sicherzustellen, dass das vorherige Passwort nicht mehr verwendet wird, ist ein Neustart des Geräts die einzige sichere Methode.

Nach Ablauf der Frist wird das Kennwort des verwalteten Kontos zurückgesetzt und das verwaltete Gerät sofort neu gestartet, wenn die Einstellung aktiviert ist.

Wenn diese Einstellung deaktiviert oder nicht konfiguriert ist, werden die Aktionen nach der Authentifizierung standardmäßig auf ‚Kennwort zurücksetzen und verwaltetes Konto abmelden‘ gesetzt.

Hinweis: Das DSRM-Konto auf Domänencontrollern kann nicht für Post-Authentifizierungsaktionen konfiguriert werden. Diese Richtlinie hat keine Auswirkungen auf Domänencontroller und wird ignoriert, auch wenn sie für einen DC konfiguriert wurde.

Für die Migration empfehle ich, die Gruppenrichtlinie schrittweise mit den zu migrierenden Organisationseinheiten zu verknüpfen. Nach der Migration kann sie dann auf Domänenebene verknüpft werden.

Tipps für eine gemischte Migration

Eine gemischte Migration liegt vor, wenn noch teilweise der veraltete LAPS installiert und genutzt wird, während an anderen Stellen bereits auf Windows LAPS umgestellt wurde. In diesem Fall gibt es einige Tipps, welche PowerShell-Befehle am besten geeignet sind.

Abfragen der Kennwörter immer mit den Windows LAPS (Get-LapsADPassword)
Setzten von Zeitstempel bzw. das Auslösen der Zurücksetzung mit beiden Befehlen, nur so ist sichergestellt, dass es auf jeden Fall passiert.

Auslesen der Kennwörter nach der Migration

Nachdem die Gruppenrichtlinie und die Computerberechtigung gesetzt wurden, übernimmt Windows LAPS die Kontrolle, auch wenn Legacy LAPS noch installiert ist. In diesem Fall hat die Gruppenrichtlinie für Windows LAPS Vorrang vor Microsoft LAPS. In diesem Fall ist die Windows LAPS GPO für die OU DHCP aktiviert.

Auf dem Server, IFH-DHCP02, sieht es so aus, wenn das Legacy LAPS installiert ist und das Legacy LAPS Passwort noch nicht abgelaufen ist. Da beide LAPS-Varianten eigene Active Directory-Attribute haben, können sie nebeneinander existieren. Später in diesem Artikel wird näher auf die Attribute eingegangen.

Es ist dennoch ratsam, den Legacy LAPS zu deinstallieren, um mögliche Probleme zu vermeiden. Obwohl der Windows LAPS den Legacy LAPS durch eine neue Richtlinie überschreibt.

In diesem Fall habe ich das Ablaufdatum für den Legacy LAPS so gesetzt, dass eine Änderung erforderlich wurde.

Das Legacy LAPS trägt ein Passwort in das Attribut Active Directory ein, jedoch ist das gültige Passwort das des Windows LAPS.

Im Attribute Editor ist erkennbar, dass die Legacy LAPS die Werte im AD eingetragen hat. Allerdings wurde die lokale Änderung verhindert.

Domänen Controller und der Directory Service Recovery Mode mit Windows LAPS

Wenn Sie mit dem Begriff Directory Service Recovery Mode (DSRM) nichts anfangen können, empfehle ich Ihnen einen Blick in den Hintergrundartikel „Active Directory Service Recovery Mode (DSRM)„.

Früher hat der LAPS, wenn er auf einem Domänencontroller ausgeführt wurde, das Passwort des Domänenbenutzers „Administrator“ geändert. Der neue LAPS ist intelligenter und ändert automatisch das DSRM-Passwort auf einem Domänencontroller, was am Ehesten einem lokalen Administrator entspricht, auch ohne entsprechenden Parameter. Es ist wichtig, dass die Domänenfunktionsebene mindestens 2016 beträgt und die Domänencontroller auf Windows Server 2019 laufen.

Wenn aktiviert, füllt DSRM auch die Passworthistorie. Die Passworthistorie ist insbesondere bei der Wiederherstellung aus einem Backup wichtig und sollte aktiviert werden. Um die Passworthistorie anzuzeigen, verwenden Sie den Parameter „-IncludeHistory“ beim Befehl Get-LAPSADPassword.

Damit ist sichergestellt, dass die DSRM-Passwörter regelmäßig geändert werden. Es fällt auf, dass für den IFH-DC02 kein Kennwort angezeigt wird, da dieser noch einen Patch-Stand vor Windows LAPS hat.

EventIDs von Windows LAPS

Um die Ereignisprotokolle von Windows LAPS besser zu verstehen, sind hier die wichtigsten Event-IDs aufgeführt.

Hier ist die aktualisierte Tabelle:

EventID	Beschreibung
10003	Markiert den Beginn eines Hintergrundrichtlinienverarbeitungszyklus.
10004	Markiert das erfolgreiche Ende eines Hintergrundrichtlinienverarbeitungszyklus.
10005	Markiert das fehlgeschlagene Ende eines Hintergrundrichtlinienverarbeitungszyklus.
10018	Wird protokolliert, wenn Windows LAPS erfolgreich das On-Premise Active Directory mit einem neuen Passwort aktualisiert hat.
10020	Wird protokolliert, wenn Windows LAPS das verwaltete lokale Konto erfolgreich aktualisiert hat.
10021	Wird protokolliert, wenn die Richtlinie so konfiguriert ist, dass das Passwort im On-Premise Active Directory gesichert wird.
10022	Wird protokolliert, wenn die Richtlinie so konfiguriert ist, dass das Passwort in Azure Active Directory gesichert wird.
10023	Wird protokolliert, wenn Windows LAPS so konfiguriert ist, dass eine Legacy Microsoft LAPS-Richtlinie verwendet wird.
10029	Wird protokolliert, wenn Windows LAPS erfolgreich das Azure Active Directory mit einem neuen Passwort aktualisiert hat.
10031	Wird protokolliert, wenn ein Versuch, das Passwort zu ändern, blockiert wurde.
10041	Wird protokolliert, wenn eine erfolgreiche Authentifizierung für das angegebene verwaltete Konto erkannt wird.
10042	Wird protokolliert, wenn die im Event 10041 aufgeführte Frist erreicht ist.
10043	Wird protokolliert, wenn die Passwortrotation fehlschlägt.
10044	Wird protokolliert, wenn die Passwortrotation erfolgreich ist.

Fazit

Es ist wichtig, bei der Local Administrative Passwort Solution (LAPS) zu wissen, welche Einstellung oder Version aktiv ist und wann sie aktiv ist.

	Nur Legacy LAPS Policy	Nur neue LAPS Policy	Beide LAPS Policy
Nur Legacy LAPS installiert	Legacy LAPS	Inaktiv	Legacy LAPS
Beide LAPS installiert	Legacy LAPS	Neuer LAPS	Neuer LAPS *
Nur Windows LAPS installiert	Neuer LAPS (Legacy Mode)	Neuer LAPS	Neuer LAPS

* Beide Varianten von LAPS sind aktiv und schreiben Änderungen in das AD-Attribut. Allerdings kann nur die neue Variante das Attribut lokal ändern. Der Parallelbetrieb ist offiziell nur dann unterstützt, wenn die beiden LAPS-Varianten unterschiedliche Konten verwalten.

Vor der Umstellung auf die neue Windows LAPS Richtlinie sollte das alte Microsoft LAPS deinstalliert werden, um mögliche Konflikte zu vermeiden.

Meiner Meinung nach sind endlich die Funktionen nachgerüstet worden, die ich immer vermisst habe. Besonders die Historie ist bei einer Wiederherstellung von einem Backup unerlässlich. Es ist auch positiv zu erwähnen, dass das DSRM-Passwort auf den Domänencontrollern geändert wird und nicht mehr das des Domänenkontos ‚Administrator‘.

Ich finde die Integration in Azure AD perspektivisch vielversprechend, habe sie jedoch noch nicht im Detail untersucht.