Das Problem: Seit Jahren nutzen wir auf fast allen Servern und Clients für den lokalen Administrator das gleiche Passwort. Eine Passwortänderung wurde in der Vergangenheit nach Best Practise über eine GPP (Group Policy Preferences) ausgerollt. Die GPP speichert das Passwort in den Konfigurationsteil der Policy ab. Dieser Teil der Konfiguration ist unsicher, weil das Passwort dort ausgelesen werden kann. * Folgende GPP konnten Passwörter speichern bis Microsoft Abhilfe geschaffen hat: Local user and group Mapped drives Services Scheduled tasks (Uplevel) Scheduled tasks (Downlevel) Immediate tasks (Uplevel) Immediate tasks (Downlevel) Data sources *Link zum Microsoft Artikel 13.Mai 2014: Vulnerability in Group Policy Preferences Could Allow Elevation of Privilege (2962486) https://technet.microsoft.com/en-us/library/security/ms14-025.aspx Die Lösung: Microsoft erkannte das Problem und entwickelte daraufhin ein neues Tool namens LAPS (Local Administrator Password Solution). Dieses Tool ermöglicht uns über einen Password Decryption Service (PDS) und einer Gruppenrichtlinie, eine automatisierte und dynamische Änderung der Passwörter nach individuellen Vorgaben: Passwortlänge in welchen zeitlichen Abständen es geändert werden soll und wer es lesen und ändern darf. Die Kommunikation zwischen den Domänencontrollern auf dem der PDS läuft sowie den zu verwaltenden Clients/Servern, ist verschlüsselt. Umsetzung: Downloadquelle: https://www.microsoft.com/en-us/download/details.aspx?id=46899 http://www.laps-e.net/ Voraussetzung: Das Active Directory muss zuvor über ein Schema-Update vorbereitet werden. Es werden 3 weitere Attribute hinzugefügt: ms-mcs-admpwd speichert das Passwort ms-mcs-admpwdexpirationtime speichert das Ablaufdatum des Passworts ms-mcs-admpwdhistory speichert vergangene Passwörter
Folgende Schritte sind während der Einrichtung durchzuführen: 1. Import des Active Directory Modul AdmPwd.ps 2. Active Directory Schema Update (hinzufügen von 2 neuen Attributen) 3. Berechtigungen auf die Computer/Server setzen damit diese das Passwort und die Gültigkeit in die neuen Attribute schreiben können 4. Berechtigungen zum Auslesen der Passwörter setzen (Domänen-Admins) 5. Berechtigungen zum Schreiben von Passwörtern setzen (Domänen-Admins) 6. Aktivierung des Security Auditing 7. Erstellen einer Gruppenrichtlinie zur Vorgabe der Passwortlänge und Gültigkeit Erklärung: Die Gruppenrichtlinie die die Passwortlänge und Gültigkeit vorgibt, wird auf ausgewählte OUs verknüpft, in der die Server/Clients enthalten sind. Die während der Einrichtung unter Punkt 3 vergebenen Rechte werden benötigt, damit die Server/Clients die neuen Active Directory Attribute beschreiben dürfen. Nach der Installation und Einrichtung können die unverschlüsselten Passwörter über 3 Wege eingesehen werden. Verschlüsselte Passwörter nur über die GUI! Einmal über den Attribut Editor des jeweiligen Computerobjekts:
Über ein Powershell Command; aber nur unverschlüsselte Passwörter! Get-ADComputer <Computer> -Properties ms-mcs-admpwd Select Name, ms-mcs- AdmPwd Oder über die LAPS GUI: An diesem Bild erkennen wir, dass allein die GUI, das im AD stehende verschlüsselte Passwort entschlüsseln und anzeigen kann.
Maintain keys Get password Reset password LAPS Enterprise 7.2.1 Kommunikationsdiagramm: Legend Green = solution specific Blue = Windows platform features Bold lines = encrypted connection Computer account Active Directory GPO Computer account Read password Reset password Password Decryption Service Audit Autodiscovery Audit log Public Private SRV record DNS Encryption keys API Password + Expiration + (History) GP Update Parameters Encryption key GP Update Parameters Encryption key Password + Expiration + (History) Configuration of solution Read password Reset password Key management Read password Reset password Read password Reset password Key management Service discovery Admin CSE Admin CSE Powershell module Fat client Web Managed machines Client tools Installation: Auf dem Domänencontroller installieren wir das Produkt mit allen Modulen, die GPO Extension kann weggelassen werden, sofern man den DC selbst nicht managen möchte. Während des Installationsprozesses werden einige Daten auf die Maschine kopiert und eine Firewall-Regel erstellt damit der Service ADMPwd PDS die Kommunikation zwischen den einzelnen Komponenten herstellen und steuern kann.
Dateien die während der Installation kopiert werden: CSE Die Installation der Client Side Extension erfolgt in den Pfad: Fat Client UI %ProgramFiles%\AdmPwd\CSE AdmPwd.dll Die Installation für den Fat Client erfolgt in den Pfad: PowerShell Module %ProgramFiles%\AdmPwd AdmPwd.ServiceUtils.dll AdmPwd.UI.exe AdmPwd.Utils.config AdmPwd.Utils.dll Die Installation der Powershellmodule erfolgt in den Pfad: %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS AdmPwd.PS.dll AdmPwd.PS.format.ps1xml AdmPwd.PS.psd1 AdmPwd.ServiceUtils.dll AdmPwd.Utils.config AdmPwd.Utils.dll %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS\en-US Group Policy template AdmPwd.PS.dll-Help.xml Die Installation für die Gruppenrichtlinien notwendigen Daten erfolgt in den Pfad: %WINDIR%\PolicyDefinitions LAPS.E.admx %WINDIR%\PolicyDefinitions\en-US LAPS.E.adml Der Password Decryption Service Die Installation für den PDS erfolgt in den Pfad: %ProgramFiles%\AdmPwd\Svc AdmPwd.PS.dll AdmPwd.Service.exe AdmPwd.Service.exe.config AdmPwd.Service.Messages.dll AdmPwd.Utils.config AdmPwd.Utils.dll
Die Firewall-Regel wird durch den Installationsprozess selbständig eingetragen. Zur Einrichtung führen wir diese Powershell-Befehle aus. Wir öffnen die ISE, kopieren uns die Befehle passen die Syntax der jeweiligen Umgebung an und führen diese dann nacheinander aus. Bevor wir die Powershell-Befehle absetzen müssen wir im AD noch eine Gruppe namens LapAdmin erstellen. Member dieser Gruppe können später mittels der Berechtigungen die verschlüsselten Passwörter lesen und zurücksetzen. Domänen-Admins müssen auch Mitglieder dieser delegierten Gruppe werden, sie haben keine Sonderrechte! # Import des neuen Moduls Import-module AdmPwd.PS #AD Schema Update. Es werden 3 weitere Attribute hinzugefügt Update-AdmPwdADSchema # Setzt Berechtigung auf die OU in der die Maschinen enthalten sind um das Passwort selbst ändern zu dürfen. Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Workstations,DC=ndsedv,DC=de" # Vergibt der AD Gruppe die Berechtigung die generierten Passwörter zu lesen. Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Workstations,DC=ndsedv,DC=de" - AllowedPrincipals LapAdmin # Vergibt der AD Gruppe die Berechtigun, die generierten Passwörter zu resetten. Set-AdmPwdResetPasswordPermission -OrgUnit "OU=Workstations,DC=ndsedv,DC=de" - AllowedPrincipals LapAdmin # Weist dem PDS den NETWORK SERVICE Account zu um Passwörter zu behandeln und die Verschlüsselung zu managen. Set-AdmPwdServiceAccountPermission -Identity "OU=Workstations,DC=ndsedv,DC=de" -AllowedPrincipals "NETWORK SERVICE" # Erstellt ein neues Schlüsselpaar New-AdmPwdKeyPair -KeySize 4096
Es ist auch möglich weitere Gruppen im AD anzulegen um die Berechtigungen je nach Richtlinien-Vorgaben zu splitten. Es kann eine Gruppe geben die Passwörter nur lesen darf und eine Gruppe die das Passwort lesen und zurücksetzen darf. Nach der Abarbeitung der Befehle sehen wir in den Security-Eigenschaften die gesetzten Berechtigungen. Natürlich können die Berechtigungen auch manuell gesetzt werden. Der NETWORK SERVICE muss enthalten sein!
Der AdmPwd PDS Service wurde auch erfolgreich installiert und gestartet. Der PDS (Password Decryption Service) hat die zentrale Rolle im gesamten Konstrukt. Nach der Installation und dem automatischen Start des Dienstes wird ein SRV Record im DNS hinterlegt. Wegen dem Standard Port 61884 bitte mit einem Netzwerkkollegen Rücksprache halten.
Wir tragen in dem SRV Record noch die PwdAdmin Gruppe ein; wichtig für weitere Password Decrpytion Services. INFO: Nach der automatischen Einrichtung des Dienstes ist der NETWORK SERVICE der Besitzer dieses Records. Der letzte Befehl in der Powershell-ISE erzeugte die nötigen Dateien (Public- und Privat- Key) um die Verschlüsselung nutzbar zu machen. Privat- und Public-Key verbleiben auf dem DC (PDS) und der Public-Key wird an alle Clients weitergegeben.
Bevor wir die benötigten GPOs erstellen, kontrollieren wir ob die beiden Dateien LAPS.admx und LAPS.adml auch vorhanden sind.
Zuerst erstellen wir ein GPO namens LAPS und managen damit unsere Passwortrichtlinie. Sollte der lokale Administrator auf den zu managen Maschinen umbenannt worden sein, muss dieser zwingend in diese Richtlinie eingetragen werden. Danach öffnen wir den erzeugten *Public-Key mit Notepad kopieren uns den Schlüssel heraus und fügen diesen in den dafür vorgesehenen Teil der Richtlinie ein. Der Public-Key liegt in: *C:\Program Files\AdmPwd\Svc\CryptoKeyStorage\1_PublicKey.dat
Danach erstellen wir ein weiteres GPO namens LAPSSetup. Mit diesem GPO verteilen wir die CSE (Client Side Extension) an alle zu managen Clients und Server. Zu beachten ist hierbei, dass der Pfad eine Netzwerkfreigabe sein muss. Wir puschen die Policy auf die Clients und starten diese neu. Die Installation beginnt in der Regel nach einem Neustart aber spätestens nach den zweiten; mit Systemrechten.
Optional: Dann habe ich noch eine Audit File System Policy erstellt. Nach dem erfolgreichen roll-out der CSE auf die Clients kopieren wir den Public-Key in das noch anzulegende Verzeichnis \Svc\CryptoKeyStorage. Ich habe mir dazu ein.msi Paket erstellt. Kann man natürlich auch über ein Start- oder Login Script erledigen.
Kontrolle der Berechtigungen auf die zu managen OUs: Nachdem die Gruppenrichtlinien gezogen haben sollte das Passwort im Computerobjekt bereits geschrieben worden sein. Sobald weitere Passwörter generiert wurden, wird auch das Attribut History gefüllt.
Und so sieht die History dann mal aus: Mit der GUI zu arbeiten ist natürlich wesentlich komfortabler. Ist bei einer aktiven Verschlüsselung sowieso ein Muss.
Weitere Beispiele: Eine etwas längere History:
INFORMATIONEN: Registry Eintrag auf einem gemanagten Client/Server GPO LAPS: An dieser Stelle der Registry sind die Vorgaben der Richtlinie hinterlegt. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft Services\AdmPwd] Troubleshooting: Wenn wir ein detailliertes Logging wünschen, um später oder zu Prüfzwecken Troubleshooting betreiben zu können, dann müssen wir in der Registry unter diesem Pfad den fett-schwarzen Wert setzen. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D- 087DE603E3EA}] "ExtensionDebugLevel"=dword:00000002 Die Ergebnisse des Loggings sehen wir in den Windows Protokollen unter Anwendung ein.
Folgende ID`s werden geschrieben, wenn das Passwort über den Prozess (PDS) geändert wurde: ID 1: Beginning processing with flags 0x1011 ID 11: Admin Password was not manipulated with (0). Also gesteuert ID 7: Local Administartor s password has been successfully encrypted. Also lokal ID 8: Local Administrator`s password has been reported to AD. In s Attribut übertragen ID 9: Local Administrator`s password has been changed. Erfolgreich ins AD geschrieben ID 10 100: Finished successfully. Auditing auf Public Key: Jeder versuchte Zugriff auf den lokalen Public Key wird geloggt, sofern das Auditing auf den (gemanagten Maschinen) aktiv geschaltet wurde. Mit diesem Befehl forcen wir eine Passwortänderung indem wir den Wert auf Null setzen: Get-ADComputer -SearchBase " OU=Workstations,DC=ndsedv,DC=de " -Filter * -Server winserver.ndsedv.de -Properties ms-mcs-admpwdexpirationtime % { Set-ADComputer -Identity $_ -Replace @{"ms-mcs-admpwdexpirationtime" = "0"} }