28

Like it now

Seit April 2023 verteilt Microsoft das LAPS (= „Local Administrator Password Solution„) auf aktuelle Systeme per Windows-Update. Es wurden unter der Haube ein paar Funktionen hinzugefügt, letztlich soll das Einrichten und Verwenden von LAPS vereinfacht werden. Ich habe in der Vergangenheit schon einen Artikel zu diesem Thema veröffentlicht: AD-Security: Verwendung von LAPS

Ein großer Mehrwehrt ist, dass das Kennwort nicht mehr in Klartext im AD gespeichert wird, sondern verschlüsselt.

Während in der bisherigen Variante zum einen auf jedem Client ein Stück Software installiert werden musste und zum anderen für das Auslesen das mitgelieferte Tool „LAPS Gui“ verwendet werden musste (alternativ natürlich auch per PowerShell möglich), soll nun die Installation überflüssig sein, denn das ist nun bei Windows bereits integriert. Ebenso ist die „LAPS Gui“ zum Auslesen überflüssig, da es nun einen weiteren Reiter („LAPS“) auf dem Computer-Objekt im AD gibt.

Derzeit wird das Übersicht über Windows LAPS | Microsoft Learn auf folgenden Systemen unterstützt:

• Windows Server 2019 (mit Updates vom 11. April 2023)
• Windows Server 2022 (mit Updates vom 11. April 2023)
• Windows 10 – 19042/19044/19045 (mit Updates vom 11. April 2023)
  • Windows 10 Enterprise Multi-Session, Version 20H2
  • Windows 10 Enterprise and Education, Version 20H2
  • Windows 10 IoT Enterprise, Version 20H2
  • Windows 10 Surface Hub
  • Windows 10 21H2
  • Windows 10 22H2
• Windows 11 – 21H2 (mit Updates vom 11. April 2023)
• Windows 11 – 22H2 (mit Updates vom 11. April 2023)

Wichtig:
Derzeit kann „Legacy-LAPS“ und „Windows-LAPS“ nicht parallel auf einem Client aktiv sein! D.h. am besten das „Legacy-LAPS“ für diese Clients deaktivieren bzw. deinstallieren und stattdessen per GPO die Einstellungen für „Windows-LAPS“ aktivieren.

Vergleich zwischen „Windows-LAPS“ und „Legacy-LAPS“

PowerShell-Befehle

Beide LAPS-Versionen verwenden das Modul „AdmPwd.PS“, allerdings gibt es ein paar Unterschiede. Diese liste ich hier grob auf:

Windows LAPS-Cmdlet	Legacy-Microsoft LAPS-Cmdlet
Get-LapsAADPassword	Nicht zutreffend
Get-LapsDiagnostics	Nicht zutreffend
Find-LapsADExtendedRights	Find-AdmPwdExtendedRights
Get-LapsADPassword	Get-AdmPwdPassword
Invoke-LapsPolicyProcessing	Nicht zutreffend
Reset-LapsPassword	Nicht zutreffend
Set-LapsADAuditing	Set-AdmPwdAuditing
Set-LapsADComputerSelfPermission	Set-AdmPwdComputerSelfPermission
Set-LapsADPasswordExpirationTime	Reset-AdmPwdPassword
Set-LapsADReadPasswordPermission	Set-AdmPwdReadPasswordPermission
Set-LapsADResetPasswordPermission	Set-AdmPwdResetPasswordPermission
Update-LapsADSchema	Update-AdmPwdADSchema

Zusätzlich zu namensbezogenen Änderungen arbeiten die PowerShell-Cmdlets von Windows LAPS für Windows Server Active Directory mit einem völlig anderen Satz von Schemaerweiterungen.

AD-Schema (Computer-Objekt)

Das neue „Windows-LAPS“ führt eine Reihe neuer Attribute ein, zwei davon lösen somit die bisherigen Attribute ab. Hier eine Auflistung der verwendete Attribute:

Windows LAPS-Schemaelement	Legacy-Microsoft LAPS-Schemaelement
msLAPS-PasswordExpirationTime	ms-Mcs-AdmPwdExpirationTime
msLAPS-Password	ms-Mcs-AdmPwd
msLAPS-EncryptedPassword	Nicht zutreffend
msLAPS-EncryptedPasswordHistory	Nicht zutreffend
msLAPS-EncryptedDSRMPassword	Nicht zutreffend
msLAPS-EncryptedDSRMPasswordHistory	Nicht zutreffend
ms-LAPS-Encrypted-Password-Attributes	Nicht zutreffend

LAPS Gui

Für das „Legacy-LAPS“ wird die zu installierende „LAPS Gui“ zum Auslesen des Kennworts verwendet oder mittels eines Powershell-Befehls. So oder so wird der im Attribut „“ hinterlegte Wert angezeigt. Sofern man die notwendigen Rechte hat, könnte man sich das auch über den Reiter „Attribut Editor“ im Computerobjekt anzeigen lassen.

Hier der Vergleich: links ein Domain-Controller vor dem April-Patchday – es fehlt der Reiter „LAPS“. Und rechts ein Domain-Controller nach dem April-Patchday mit vorhandenem „LAPS“-Reiter.

Darunter das Auslesen via „LAPS Gui“ bzw. in den Computereigenschaften im Reiter „Attribut Editor“ und via Powershell mit dem Befehl

Get-ADComputer -Identity PKI02 -Properties ms-Mcs-AdmPwd | select ms-Mcs-AdmPwd

---

Gruppenrichtlinie

Die Gruppenrichtlinie-Vorlage für das „Legacy-LAPS“ ist „AdmPwd.admx“ und bringt den Ordner „LAPS“ unter „Administrative Templates“ (siehe Bild links) während die Vorlage für das „Windows-LAPS“ ist „LAPS.admx“ und unter „“ (Bild rechts) eingliedert ist und zudem wesentlich mehr Konfigurationsmöglichkeiten enthält. Wichtig ist, sofern man den „Central Store“ verwendet, muss die Vorlage noch kopiert werden (siehe hierzu meinen Artikel ADMX-Templates: Lokaler Speicher vs. Zentraler Speicher).

---

Upgrade durchführen

Um auf die neueste Version upzudaten, müssen folgende Dinge durchgeführt werden:

1. Domain-Controller auf aktuellen Patch-Stand bringen (bei Windows Server 2022 ist das mindestens 20348.1668)
2. Gruppenrichtlinien-Vorlage („PolicyDefinition“) vom lokalen Speicher in den zentralen Speicher kopieren (siehe ADMX-Templates: Lokaler Speicher vs. Zentraler Speicher)
3. Active-Directory Schema-Update durchführen
4. Zwei AD-Gruppen für die Trennung der LAPS-Verteilung anlegen & mit entsprechenden Computer-Konten füllen)
5. Gruppenrichtlinien anpassen bzw. neue hinzufügen & verlinken

Patchstand der Domain-Controller

Falls der Patchstand älter als die Buildversion 20348.1668 ist, dann nach Windows-Updates suchen & installieren. Optimalerweise sind alle Domain-Controller auf dem selben Patchstand.

Gruppenrichtlinienvorlage

Analog zur Anleitung ADMX-Templates: Lokaler Speicher vs. Zentraler Speicher folgende Dateien kopieren:

• LAPS.admx
  • Quelle: C:\Windows\PolicyDefinitions
  • Ziel: C:\Windows\SYSVOL\sysvol\<NAME-DER-DOMAIN>\Policies\PolicyDefinitions\
• LAPS.adml
  • Quelle: C:\Windows\PolicyDefinitions\en-US
  • Ziel: C:\Windows\SYSVOL\sysvol\<NAME-DER-DOMAIN>\Policies\PolicyDefinitions\en-US

AD-Schema-Update

Der Account, mit welchem folgender PowerShell-Befehl ausgeführt wird, muss in den AD-Gruppen „Domain Admins“ und „Schema Admins“ sein:

Update-LapsADSchema

---

Berechtigung für das Kennwortsetzen für Computer

Es muss jetzt natürlich noch das Recht für Computer-Objekte gesetzt werden, sodass diese in das richtige AD-Attribut das neue Kennwort schreiben können.

Microsoft beschreibt das so:

Dem verwalteten Gerät muss die Berechtigung zum Aktualisieren seines Kennworts erteilt werden. Diese Aktion erfolgt, indem vererbbare Berechtigungen für die Organisationseinheit des Geräts festgelegt werden.

Letztlich muss dieser Powershell-Befehl auf jeder OU ausgeführt werden, in der Computer-Objekte liegen:

Set-LapsADComputerSelfPermission -Identity "OU=DEVICES,OU=COMPANY,OU=MY,DC=DEMOLABOR,DC=intern"

---

AD-Gruppen für LAPS-Verteilung & LAPS-Leserecht

Ich lege hierzu folgende zwei Gruppen an:

• LAPS-GPO_Legacy-LAPS
• LAPS-GPO_Windows-LAPS

In die erste Gruppe setze ich alle Computer-Konten, die entweder zu alt für das Windows-LAPS sind oder die aktuell noch nicht umgestellt werden sollen. In die zweite Gruppe setze ich alle Computer-Konten, die Windows-LAPS unterstützen und jetzt umgestellt werden sollen.

In meinem Beispiel soll das Computerkonto „PKI02“ in die Gruppe „LAPS-GPO_Windows-LAPS“.

Zudem wird eine AD-Gruppe benötigt, die das Recht hat, das LAPS-Kennwort zu lesen (bzw. zu entschlüsseln, falls Verschlüsselung aktiviert ist). Da es bereits die AD-Gruppe „LAPS-CLIENTS-ReadAndReset“ gibt, muss hier nichts weiter gemacht werden. Für das Hinterlegen in der GPO kann entweder der Name (Im Format „DOMAIN\GROUP„, also in meinem Fall „DEMOLABOR\LAPS-CLIENTS-ReadAndReset“) oder die SID (also in meinem Fall „S-1-5-21-450352446-791334395-3255403168-1116“) verwendet werden.
Das Auslesen der SID geht bspw. mit diesem PowerShell-Befehl:

Get-ADGroup -Identity LAPS-CLIENTS-ReadAndReset -Properties * | select objectSID

---

Gruppenrichtlinien anpassen/hinzufügen

In der Anleitung AD-Security: Verwendung von LAPS wurden Gruppenrichtlinien für die Installation von LAPS und die Konfiguration angelegt:

• Clients:
  • C-C-PO-AT-LAPS_Step1_ClientSideExtenion-Installation_v1.0
  • C-C-PO-AT-LAPS_Step2_Activation_v1.0
• Server:
  • S-C-PO-AT-LAPS_Step1_ClientSideExtenion-Installation_v1.0
  • S-C-PO-AT-LAPS_Step2_Activation_v1.0

Bei allen vieren muss im Bereicht „Security Filtering“ nun die AD-Gruppe „Authenticated Users“ durch die AD-Gruppe „LAPS-GPO_Legacy-LAPS“ getauscht werden.

Zudem benenne ich die GPOs um, sodass klar ist, dass es sich um das ältere LAPS handelt. Im Namen der GPO ändere ich den „LAPS“-Teil zu „LAPS01-Legacy“.

Es werden dann neue GPOs angelegt:

• Clients:
  • C-C-PO-AT-LAPS02-Windows_Step1_ClientSideExtenion-UnInstallation_v1.0
  • C-C-PO-AT-LAPS02-Windows_Step2_Activation_v1.0
• Server:
  • S-C-PO-AT-LAPS02-Windows_Step1_ClientSideExtenion-UnInstallation_v1.0
  • S-C-PO-AT-LAPS02-Windows_Step2_Activation_v1.0

Im ersten Schritt wird die alte LAPS-Software deinstalliert und im zweiten Schritt werden die Einstellungen des neuen LAPS gesetzt.

Für die GPO „S-C-PO-AT-LAPS02-Windows_Step1_ClientSideExtenion-UnInstallation_v1.0“ wird analog zur Anleitung (AD-Security: Verwendung von LAPS) im Pfad „\\DEMOLABOR.intern\SysVol\DEMOLABOR.intern\scripts\LAPS\“ (= „C:\Windows\SYSVOL\sysvol\DEMOLABOR.intern\scripts\LAPS“) das Skript „LAPSuninstallCSE.bat“ angelegt, welches folgenden Inhalt hat:

msiexec /x \\DEMOLABOR.intern\SysVol\DEMOLABOR.intern\scripts\LAPS\LAPSx64.msi /quiet

Zudem wird bei „Security Filtering“ hier die zweite AD-Gruppe („LAPS-GPO_Windows-LAPS“) anstelle der „Authenticated Users“ eingetragen.

Für die GPO „S-C-PO-AT-LAPS02-Windows_Step2_Activation_v1.0“ nehme ich folgende Einstellungen vor:

• Configure authorized password decryptors
  • DEMOLABOR\LAPS-CLIENTS-ReadAndReset
• Configure password backup directory
  • Active Directory
• Do not allow password expiration time longer than required by policy
  • Enabled
• Enable password backup for DSRM accounts
  • Enabled
• Enable password encryption
  • Enabled
• Password settings
  • Complexity: Large letter + small letters + numbers + specials
  • Length: 16
  • Age (Days): 7
• Post-authentication actions:
  • Grace period (hours): 1
  • Actions: Reset password and logoff the managed account

Wichtig:
Zudem wird bei „Security Filtering“ hier die zweite AD-Gruppe („LAPS-GPO_Windows-LAPS“) anstelle der „Authenticated Users“ eingetragen!

---

Test des neuen Windows-Laps

Zum Testen habe ich den Server „PKI02“ genommen und folgende Schritte durchgeführt:

1. auf aktuelle Windows-Updates geprüft – es muss mindestens 2023-04 (April-Updates) installiert sein
2. Im AD das Computer-Objekt von AD-Gruppe „LAPS-GPO_Legacy-LAPS“ in AD-Gruppe „LAPS-GPO_Windows-LAPS“ verschoben
3. Server neugestartet (hierbei wurde das alte LAPS automatisch deinstalliert)
4. Nochmal „gpupdate /force“ ausgeführt

Danach konnte im „AD Users and Computers“ im Reiter „LAPS“ das Kennwort ausgelesen werden:

---