[et_pb_section][et_pb_row][et_pb_column type=“4_4″][et_pb_text]
Wie kann ich lokale Benutzerkonten auf Clients in meiner Active Directory bändigen?
Das Problem von Wildwüchsigen lokalen Benutzerkonten auf Clients innerhalb der Organisation dürfe spätestens bei einem Security-Audit und dem Wunsch nach Password-Policys auch für lokale Benutzerkonten zum Vorschein bei einigen Organisationen zum Vorschein kommen.
Nicht selten findet man neben dem „Default Build-In-Administrator“ weitere Benutzer, wie „Admin“, „Test“ „User“ etc. als lokale Benutzer auf den einzelnen Clients. Best-Practice ist es, dass ausschließlich ein lokalen User mit Adminrechten lokal auf den Clients existiert und dieses Passwort sich gemäss eine Password-Expiration-Policy regelmässig ändert. Außerdem sollte sichergestellt sein, dass an einer zentralen Stelle (dem AD – Active-Directory) das Passwort gespeichert und für privilegierte User einsehbar ist.
Folgendes Vorgehen dafür habe ich erprobt:
Schritt 1: Identifizieren der lokalen User
Um eine Übersicht und eine Verwendung sowie Zuweisung der Konten für etwaige Services für eine bessere Transparenz zu bekommen, ist es sinnvoll einen aktuellen Export zu generieren und in diesem Benutzerkonten Services und Verwendungszwecke zu identifizieren und zu dokumentieren.
Kategorisieren und Dokumentieren der lokalen Accounts
Im weiteren Verlauf sollten die Accounts, welche man als „Überbleibsel“ etwaiger vorangegangenen Installationen und/oder Testzwecke hat ausfindig machen können deaktivieren.
Benutzerkonten, dessen Existenz durch Verwendung als Benutzern in Services begründet ist sollten in Erwägung gezogen werden durch Benutzerkonten im AD ersetzt zu werden. Hierfür ist es notwendig den entsprechenden zugewiesenen Service zu identifizieren und innerhalb diesen den Benutzer durch den neuangelegten Account im AD zu ersetzen. Sollten aus etwaigen Gründen ein Ersetzen des Users durch ein AD-Konto nicht möglich sein, kann zunächst das vorhandene lokale Benutzerkonto existent bleiben. Wichtig dabei ist, dieses für eine spätere Deaktivierung auszuschließen und entsprechend zu dokumentieren.
Anlegen der Sicherheitsgruppe „Lokale Admin“
GPO Policy zur Zuweisung der lokalen Administratoren
- Die GPO „DisableLocalUser“ wird erzeugt.
- In den System Preferences wird für die Einstellungen der lokalen Benutzer und Gruppe zunächst ein neuer Gruppeneintrag mit der Aktion „Aktualisieren“ erzeugt.
- Hier werden als Mitglieder die AD-Gruppe „Lokale Admins“ aus Schritt 3 sowie das lokale Computer Benutzerkonto „localadmin“ (Alternative für den Build-In Administrator) der Gruppe der lokalen Administratoren des jeweiligen Devices aufgenommen. Der entsprechende lokale Benutzer „localadmin“ wird während der Installation des LAPS-Client erzeugt.
Deaktivieren des Build-In-Administrators
Innerhalb der im Schritt 3 erzeugten GPO „DiableLocalUser“ wird der „Build-In Administrator“ deaktiviert.
Deaktivieren sämtlicher (weiterer) lokalen Benutzer
Um sicherzustellen, dass weiterhin benötigte Benutzer von der Deaktivierung ausgeschlossen sind,
ist es notwendig die zuvor kategorisierten und dokumentieren Benutzer in einem Script zum Deaktivieren der lokalen Konten aufzuführen. Ziel ist es stets die lokalen Konten durch AD-Konten zu ersetzten, sodass kontinuierlich weitere Benutzer durch Entfernen des Ausschlusses im Script als lokale Konten deaktiviert werden.
get-localuser | ? {($_.name -ne 'Administrator') –and ($_.name -ne 'DefaultAccount') –and ($_.name -ne 'donotdisable') –and ($_.name -ne 'IISUsr') –and ($_.name -ne 'WDAGUtilityAccount') –and ($_.name -ne 'admin') –and ($_.name -ne 'localadmin') } | disable-localuser -Confirm:$false
Das Script ist abzulegen unter \\domain.ad\netlogon\disable_local_user.ps1
Das Script kann anschließend als Startup-Script über die entsprechend Policy bereitgestellt werden.
Verwalten vom Password des Benutzers «localadmin» mittels LAPS
Damit LAPS anstelle des Build-In Administrators unseren Alternativen lokalen Administrator «localadmin» für die zentrale Stuerung des Passworts berücksichtigt sind Parameter während der Installation anzugeben sowie entsprechende Einstellungen in der GPO-Policy Voraussetzung.
Als zu berechtigende User-Gruppe für das Auslesen von Passwörtern der jeweiligen Benutzer «localadmin» der jeweiligen Devices ist die Sicherheitsgruppe «lokale Admins» vorgesehen, welche zuvor auch als Mitglieder der lokalen Build-In Gruppe «Administratoren» auf den Devices per System Preference Setting aufgenommen wurden. (Soll es in dem Fall sich um eine seperate Gruppe handeln, ist dies auch möglich).
- Herunterladen und Ausführen des LAPS-Setup.
- Benötigt auf dem DC werden die Management Tools:
- Management Tools: PowerShell Module (Unteranderem benötigt Setzten der Berechtigungen sowie Zurücksetzen des Passwords)
- Management Tools: GPO Editor Templates (ADMX-Files)
- Management Tools: Fat Client UI (Optional) (Hierbei handelt es sich um eine optionale Komponente zum Auslesen des Attributes)
- Benötigt werden auf dem Client:
- AdmPwD GPO Extensionso
- Management Tools: Fat Client UI (Optional auf Clients/Devices, auf denen das Password aus dem AD ausglesen und über eine UI ausgegeben werden soll.)
Datei-Referenzen
Die Installation für die Fat Client UI erfolgt in einem Ordner:
%ProgramFiles%\LAPS
AdmPwd.UI.exe
AdmPwd.Utils.config
AdmPwd.Utils.dll
Die Installation für die PowerShell-Module erfolgt im Ordner:
%WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS
AdmPwd.PS.dll
AdmPwd.PS.format.ps1xml
AdmPwd.PS.psd1
AdmPwd.Utils.config
AdmPwd.Utils.dll
%WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS\en-us
AdmPwd.PS.dll-Help.xml
Die Installation für die CSE erfolgt im Ordner:
%ProgramFiles%\LAPS\CSE
AdmPwd.dll
Die Installation für die Gruppenrichtliniendateien erfolgt in Ordnern:
%WINDIR%\PolicyDefinitions
AdmPwd.admx
%WINDIR%\PolicyDefinitions\en-US
AdmPwd.adml
Erweiterung des AD-Schemas
Durch Ausführung des folgendes Cmdlets wird das AD erweitert um folgende Attribute:
▪ ms-Mcs-AdmPwd – Speichert das Kennwort im Klartext
▪ ms-Mcs-AdmPwdExpirationTime – Speichert die Zeit zum Zurücksetzen des Passworts
Import-module AdmPwd.PS
Update-AdmPwdADSchema
Setzen der Berechtigung für die OUs
Als Parameter -Identity gilt es die OU der von LAPS zu managen Devices festzulegen.
Der Parameter -AllowedPrincipals bestimmt die Gruppe, welche das entsprechende Attribut, in dem
sich das Password des lokalen Benutzers «loladm» des jeweiligen Devices befindet.
Set-AdmPwdReadPasswordPermission -Identity "Clients" -AllowedPrincipals "Lokale Admins"
Berechtigung für Domputerkonten setzen
Set-AdmPwdComputerSelfPermission -Identity “Clients”
Konfigurieren der Policys für LAPS
Hinweis
Es wird eine neue GPO angelegt «LAPS» und mit der entsprechenden OU, in der sich die durch LAPS
zu verwaltenden Devices befinden.
Passwort Länge
Name des zu verwaltenden lokalen Benutzerkontos
Aktivieren der Passwort-Verwaltung durch LAPS (Local Admin Password Solution)
Deployment von LAPS für Devices
Bearbeiten des Customadminname
Für eine Nutzung von LAPS mit einem «Custom-Username, abweichend zum BildIn-Administrator ist
es erforderlich, dass dieser eigene spezifische Benutzer «loladm» während der Installation des LAPSClient genannt wird. Dafür erfolgt mittels des MSI-Editors «Orca» eine Modifikation der MSI.
Auswählen der Funktionen
Die zur Installation ausgewählten Funktionen können ebenfalls über das Modifizieren der MSI festgelegt werden. Die Funktion «CSE» ist zwingend auf den Devices, welche verwaltet werden sollen notwendig. Sofern das User-Interface (UI) für das Auslesen des Attributes für die Anwender bereitgestellt werden soll, ist es erforderlich den «Level» bei den Features «CSE», «Management» sowie bei «Mangement.UI» auf 1 festzulegen.
Wenn Sie ein Skript erstellen möchten, können Sie diese Befehlszeile verwenden, um eine stille Installation durchzuführen
msiexec /i \LAPS.x64.msi /quiet oder
msiexec /i \LAPS.x86.msi /silent
Ändern Sie einfach den in einen lokalen oder Netzwerkpfad. Beispiel:
msiexec /i \server\share\LAPS.x64.msi /quiet
Eine alternative Methode zur Installation auf verwalteten Clients besteht darin, die Datei AdmPwd.dll
auf den Zielcomputer zu kopieren und diesen Befehl zu verwenden:
regsvr32.exe AdmPwd.dll Darüber hinaus können Sie die Installation auch über SCCM, Intune oder einer manuellen Installation vornehmen.
Bereitstellen als GPO-Policy
Die zuvor modifizierte und abgespeicherte MSI kann im Netlogon Folder der Domain (\\domain.ad\netlogon\ ) Verzeichnis abgelegt und in Form einer Softwareeinstellung-Policy über die zuvor angelegte GPO «LAPS» für die entsprechende verlinkte OU ausgerollt werden.
Ergebnis
Das Ergebnis sollte sein, dass der «Build-In Administrator» der Clients deaktiviert ist und sich anstelle
dessen ein Benutzer «loladm» bzw. in diesem Fall „loladm“ sein. als Alternative für den ursprünglichen Administrator auf jeden Client befindet, dessen Passwort mittels LAPS verwaltet wird. Zudem
sollten sämtliche lokaler Nutzer, welche nicht zuvor über das Script ausgeschlossen worden sind
durch jenes deaktiviert worden sein. Wie auf dem Screenshot oben zu erkennen, ist dies der Fall.
Anzeigen des durch LAPS verwalteten User-Passwords
Sobald alles konfiguriert ist und die Gruppenrichtlinien auf den Clients aktualisiert wurden, können
Sie die Eigenschaften des Computerobjekts einsehen und die neuen Einstellungen sehen. Das Passwort wird im Klartext gespeichert. Das Ablaufdatum wird als die Anzahl der 100-Nanosekunden-Intervalle gespeichert, die seit der Stunde 0 am 1. Januar 1601 bis zu dem gespeicherten Datum/Uhrzeit verstrichen sind. Die Zeit wird im Active Directory immer in Greenwich Mean Time (GMT) gespeichert. Wenn Sie sie manuell umrechnen möchten, verwenden Sie diesen Befehl:
w32tm /ntte <number you want to convert>
Ausgeben über LAPS UI
Sofern Sie für die Installation wie oben beschrieben das LAPS UI als Komponente ausgewählt haben,
steht Ihnen die GUI zur Verfügung, von der Sie als berechtigter Benutzer, durch entsprechende Mitgliedschaft einer für das Attribut lesend berechtigte Sicherheitsgruppe das Password eines verwaltenden Devices auslesen können. Empfehlung hierfür ist die Installation auf den Clients oder TS der
berechtigten IT-Admins.
Passwort über PowerShell ausgeben
Sie können das Kennwort auch mit PowerShell abrufen:
Get-AdmPwdPassword -ComputerName <computername>
Versucht über die oben beschriebenen Wege ein nicht berechtigter Benutzer zuzugreifen, werden
ihm die Werte des entsprechenden Attributes «ms-Mcs-AdmPwd» nicht angezeigt bzw. als «Not set»
zurückgegeben.
Reset eines Passworts
Sie können das Kennwort auch mit PowerShell zurücksetzen.
Reset-AdmPwdPassword -ComputerName <Computername> -WhenEffective <data
time>
FAQ zu LAPS
Nein, für LAPS ist kein Agent erforderlich. Damit LAPS auf Workstations und Servern funktioniert, muss eine Gruppenrichtlinien-Client-Side-Erweiterung (CSE) installiert werden.
Nein, Sie können LAPS nicht verwenden, ohne die AD-Schemaänderungen zu installieren. Das Schema-Update fügt die Attribute ms-Mcs-AdmPwd und ms-Mcs-AdmPwdExpirationTime hinzu, die LAPS benötigt.
Nein. LAPS erfordert zwei Ergänzungen zu Ihrem AD-Schema. LAPS erfordert außerdem, dass eine zusätzliche Gruppenrichtlinien-Client-Side-Erweiterung (CSE) auf allen verwalteten Computern installiert wird. Sie müssen keinen zusätzlichen Anwendungsserver oder SQL-Server betreiben, um LAPS zu verwenden.
Das Attribut ms-Mcs-AdmPwd in AD ist ein vertrauliches Attribut, das durch eine Zugriffskontrollliste (ACL) geschützt ist. Nur Benutzer mit der Berechtigung, dieses Attribut einzusehen, können das Kennwort einsehen (d. h. Domänenadministratoren und alle anderen, denen sie den Zugriff delegiert haben). Die Beibehaltung desselben lokalen Administratorkennworts in großen Gruppen von Systemen stellt ein viel größeres Sicherheitsrisiko dar.
Nein, nur Benutzer mit entsprechenden Berechtigungen können die gespeicherten Kennwörter anzeigen. Sie können das PowerShell-Cmdlet Find-AdmPwdExtendedRights verwenden, um anzuzeigen, welche Gruppen und Benutzer die gespeicherten Kennwörter anzeigen können. Sie können das PowerShell-Cmdlet Set-AdmPwdReadPasswordPermission verwenden, um Gruppen und/oder Benutzern Zugriff auf die Kennwörter zu geben.
[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]
