Active Directory administrieren per PowerShell
Das Active Directory ist in den meisten Unternehmen als Verzeichnisdienst der Standard zur Authentifizierung und Rechtevergabe für Services des eigenen Datenzentrums. Bei einem so zentralen Dienst sollte bei der Automatisierung besser alles glatt laufen. Daher zeigt unser Workshop, wie Sie im AD suchen, Konten verwalten, kritische Accounts besonders absichern und welche PowerShell-Helfer Sie nutzen sollten.
In Kürze
- PowerShell vereinfacht die Administration von Active Directory durch zahlreiche integrierte AD-Cmdlets.
- Benutzer, Gruppen, Computer und Dienstkonten lassen sich effizient suchen, erstellen, ändern und automatisieren.
- Mit Filtern, SearchBase und der Pipeline können Administratoren komplexe Abfragen und Massenänderungen komfortabel umsetzen.
- PowerShell unterstützt außerdem die Verwaltung von Passwortrichtlinien, Dienstkonten, Forests, Domänen und Sicherheitsfunktionen.
- Visual Studio Code und die PowerShell ISE erleichtern das Erstellen, Testen und Debuggen von Administrationsskripten.
Das Active Directory (AD) ist über 20 Jahre alt und hat in dieser Zeit zahlreiche Veränderungen hinsichtlich Anwendungen, Schnittstellen und Integration erfahren. Über die Jahre haben Administratoren viele Erfahrungen bei der Wartung und Bedienung des AD gesammelt, doch auch deren Werkzeuge und wie sie programmatisch und automatisiert Änderungen im Directory auslösen, hat sich verändert.
Sowohl in der Administration der Daten, also Benutzer, Computer, Dienstkonten und allen anderen Objekten im Verzeichnis, als auch bei den Skripten zur Steuerung des Verzeichnisdienstes selbst – also des Services, die auf Windows laufen und die Domänenfunktion bereitstellen. Was früher über VBSkripte, reinem LDAP, Win32-Calls und später via .NET automatisiert wurde, geht für Administratoren nun etwas einfacher und gekapselt via PowerShell.
PowerShell-Helfer nutzen
Es lohnt selbst für Anfänger oder Gelegenheits-Skripter, ein paar ordentliche Werkzeuge für das Erstellen von Skripten oder Einmal-Kommandos im Werkzeugkasten zu haben. Zum einen lassen sich die Kommandos dann mit Autovervollständigung zusammenbauen, wonach sich Parameter vorschlagen und einfach einsetzen lassen, zum anderen lassen Tools Einzeiler oder Skripte direkt mit farblicher Kennzeichnung ausführen, womit sie Copy und Paste in eine separate PowerShell-Session überflüssig machen.
Zudem erlauben sie, einzelne Zeilen aus längeren Skripten separat auszuführen, um diese Schritt-für-Schritt zu testen. Natürlich ist es ebenso möglich, eine eigene PowerShell-Session zu öffnen und die Kommandos direkt einzugeben und zu verarbeiten – aber wieso es sich schwieriger als notwendig machen?
Mit Windows kommt die "PowerShell ISE" (Integrated Scripting Environment) als Beigabe hinzu: Diese ist sofort für die PowerShell einsatzbereit, wird aber nicht mehr aktiv von Microsoft weiterentwickelt. Wer seine Windows-AD-Kommandos weiterhin damit erstellen möchte, kann das tun, vor allem, weil das Tool ein Bordmittel ist und auf Domänencontrollern in gleichem Funktionsumfang zur Verfügung steht.
Eine Alternative ist Visual Studio Code, das gratis als Download für alle gängigen Windows-Versionen zur Verfügung steht und als Extension den "PowerShell Language Support for Visual Studio Code" bietet. Die Erweiterung bringt dann intelligente Vorschläge für Parameter und die Einfärbung der Kommandos zur besseren visuellen Verarbeitung von Tasks mit. Generell gilt: Die Tools zur Verwaltung des Active Directory, in diesem Fall PowerShell, müssen Sie nicht direkt auf dem Domänencontroller installieren.
Eine Admin-Maschine, auf der Sie PowerShell ISE oder Visual Studio Code einrichten, die in Zielforest oder -domäne integriert ist, reicht vollkommen aus. So müssen Sie keine Executables aus dem Internet auf die DCs bringen und aktuell halten – eine Verwaltungsmaschine, auf der sich mehrere Admins verbinden können, reicht vollkommen aus. Dort kann ja auch das Skript-Repository liegen. Und im Idealfall läuft auf einem Domänencontroller sowieso keine GUI.
Die Installation von VSCode läuft einfach: Die Visual-Studio-Seite listet die relevanten Installationspakete auf – für Windows Server ist das x64-Paket relevant. Die Installation kann sowohl für das komplette System, dann als Admin-Installation für alle Benutzer eines Admin-Servers, oder als User-Installer ohne Admin-Rechte für den eigenen Rechner heruntergeladen werden.
PowerShell-Zugriff auf das AD vorbereiten
Microsoft liefert für das AD einige fertige PowerShell-Kommandos mit, die nach deren Installation eine einfache Interaktion mit dem AD ermöglichen. Diese Cmdlets interagieren dann mit den entsprechenden Diensten, die auf Domänencontrollern arbeiten und nutzen die APIs, die Microsoft als Teil des AD zur Verfügung stellt. Sie müssen sich also nicht mit der eigentlichen API oder den Funktionen auseinandersetzen, solange Ihnen die PowerShell-Wrapper genügen. Diese PowerShell-Kommandos sind ab Windows 10 Version 1809 Teil des OS und werden als Feature manuell aktiviert, ältere Windows-10-Versionen benötigen das "Remote Server Administration Toolkit", das das PowerShell-Modul ebenfalls beinhaltet.
Auf Domänencontrollern werden Sie bei der Promotion gefragt, ob Sie die Verwaltungstools und PowerShell zusammen mit der DC-Rolle installieren wollen. Ist das Modul nicht vorhanden, können Sie es nachträglich über den Server Manager installieren, mit dem Sie das Windows-Feature einschalten (Role Administration Tools / AD DS and AD LDS Tools / Active Directory Module for Windows PowerShell). Diesen Vorgang können Sie aber auch per PowerShell durchführen:
Import-Module ServerManager Add-WindowsFeature -Name "RSAT-AD-PowerShell" -IncludeAllSubFeature
Ist das erledigt, gewinnen Sie wie folgt einen Überblick über die verfügbaren Befehle:
Get-Command -Module ActiveDirectory
So erhalten Sie alle verfügbaren Cmdlets, die Sie für das Active Directory nutzen können. Sie erkennen dabei schnell, dass die Kommandos alle das bekannte PowerShell-Verb am Anfang und danach das Kommando mit dem Präfix "AD*" führen. Sie werden auch schon bekannte Objekte unter den Cmdlets erkennen: ADUser, ADGroup, ADComputer, ADGroupMember, ADAccount und viele mehr.
Dieser Artikel erschien im IT-Administrator Sonderheft I/2024
"PowerShell – Infrastrukturen
automatisiert verwalten"
Das Sonderheft I/2024 liefert auf 205 Seiten praktisches Know-how zum Umgang mit der Microsoft-Skriptumgebung und deren Einsatz zur Automatisierung wichtiger Serversysteme. Das Autorenteam wirft unter anderem einen Blick auf die Methoden und Techniken, die die PowerShell für die Administration bereitstellt.
Bestellen Sie das Sonderheft hier als E-Paper
(Die gedruckte Ausgabe ist leider vergriffen)
Im Active Directory suchen
Sehr interessant sind die Benutzer im AD, nach denen Sie mit Get-ADUser fragen. Als Anhaltspunkt für die Suche dient entweder der sAMAccountName, der distinguishedName, die objectGUID oder die SID:
Get-ADUser -Identity peter.neudorf
Suchen wir nach allen Mitarbeitern einer bestimmten Abteilung, hilft der Filter bei der Eingrenzung auf Attributebene:
Get-ADUser -Filter "Department -like 'IT*'"
Der Filter funktioniert mit allen gängigen Attributen. Sind alle relevanten Benutzer bereits in Organisationseinheiten gruppiert, können Sie diese unter Angabe des Verzeichnispfades als "SearchBase" finden. Hier gilt die LDAP-Notation, in der die Organisationseinheit (Organizational Unit, OU) namens "Externals" in der Domäne "contoso.com" wie folgt beschrieben wird:
Get-ADUser -Filter * -SearchBase "OU=Externals,DC=contoso,DC=com"
SearchBase können Sie natürlich auch mit einem Filter kombinieren. Das Search-ADAccount-Cmdlet ist ebenfalls nützlich, wenn Sie auf der Suche nach AD-Konten sind, aber nicht benutzer- oder computerspezifisch suchen wollen. Der folgende Befehl findet alle ausgesperrten Konten:
Search-ADAccount -LockedOut
Inaktive Konten, sowohl Benutzer als auch Computer, finden Sie so:
Search-ADAccount -AccountInactive -TimeSpan 120.00:00:00 | ft Name,LastLogonDate,Enabled
Gruppen inspizieren Sie am besten mit dem Get-ADGroup-Cmdlet:
Get-ADGroup -Filter * -Properties member
Das Cmdlet gibt ihnen einen guten Überblick über die Eigenschaften einer Gruppe. Neben SearchBase lassen sich Gruppen auch mit dem "Filter" besser eingrenzen, wenn Sie etwa nur Sicherheitsgruppen suchen:
Get-ADGroup -Filter "GroupCategory -eq 'Security'" -SearchBase "OU=Groups,DC=contoso,DC=com”
Fragen Sie mit dem Get-ADGroup-Cmdlet explizit nach den Gruppenmitgliedern als Attribut, erhalten Sie diese nur als Textausgabe.
Zur Weiterverwendung der Gruppenmitglieder als PowerShell-Objekte bietet sich das Get-ADGroupMember-Cmdlet an, das nur die Gruppenmitglieder zurückgibt:
Get-ADGroupMember -Identity 'Enterprise Admins' -Recursive Get-ADGroupMember -Identity 'Domain Admins' -Recursive
Der Schalter "Recursive" löst auch "nested groups", also verschachtelte Gruppenmitgliedschaften, auf. Möchten Sie also die Mitgliederliste in einem weiteren Kommando via Pipe wiederverwenden, kommt das Get-ADGroupMember-Cmdlet zum Einsatz:
Get-ADGroupMember -Identity 'Domain Admins' -Recursive | Get-ADUser -Properties Emailaddress, lastLogonDate | Export-CSV -Path "C:\temp\csv\Domain Admins.CSV"
Alle Gruppen werden aber weiterhin mit dem Get-ADGroup-Cmdlet inspiziert und falls gewünscht auch exportiert:
Get-ADGroup -Filter "Name -like 'HR*'" -SearchBase 'OU=Groups, DC=contoso,DC=com' -SearchScope SubTree | Get-ADGroupMember Get-ADGroup -Filter "Name -like 'HR*'" -SearchBase 'OU=Groups,,DC=contoso,DC=com' -SearchScope SubTree | Export-CSV -Path 'C:\temp\csv\HR_departmental_groups.csv'
Änderungen vornehmen
Benutzer einer bestimmten OU können Sie mit einem Einzeiler so modifizieren, dass alle einen bestimmten Attributwert besitzen. Damit können Sie dann von anderen Programmen – etwa AADConnect für die Synchronisation in die Cloud – gefunden und verarbeitet werden:
Get-ADUser -Filter * -SearchBase "OU=Externals,DC=contoso,DC=com" | Set-ADUser -Add @{extensionAttribute4 = "M365"}
Über eine importierte CSV-Datei können Sie Benutzer auch in großen Mengen bearbeiten:
Import-CSV 'C:\temp\csv\users.csv' | % { if($_.mail -like '*@contoso.com) { Set-ADUser $_.SamAccountName -Add @{extensionAttribute4 = "M365"}}}
Dieser Befehl importiert eine CSV-Datei und geht diese zeilenweise durch. Das CSV-File beinhaltet Benutzerdefinitionen, wobei zwei Spalten im CSV genauer betrachtet werden: "mail" und "sAMAccountName". Wenn die Mailaddresse in der CSV-Spalte "mail" mit "@contoso.com" endet, wird "extensionAttribute4" des Benutzers im AD auf "M365" gesetzt. Für die anderen Benutzer, die in der CSV-Datei zu finden sind, passiert nichts. Um den Wert der Spalte "region" Benutzer für Benutzer in ein AD-Attribut – wie etwa "preferredDataLocation" für Office 365 – zu überführen, modifizieren Sie das Kommando und übernehmen anstelle eines festen Werts den Zellenwert aus der CSV-Datei:
Import-CSV '.\Downloads\users.csv' | % { Set-ADUser -Identity $_.sAMAccountName -Add @{preferredDataLocation = $_.region }}
Besondere Accounts verwalten
Natürlich wollen Sie nicht nur normale Benutzerkonten, sondern Konten von externen Partnern und Lieferanten oder Dienstkonten verwalten. Konten, die Sie nicht mehr benötigen, können Sie einfach deaktivieren:
Get-ADUser -Identity svc_low_SQL3 | Disable-ADAccount
Das funktioniert auch mit den Konten von externen Identitäten, die in einer OU gruppiert sind. Um die Personen oder Dienstkonten zu sperren, die sich schon 120 oder mehr Tage nicht angemeldet haben, nutzen Sie die Suche und das Disable-Account-Cmdlet:
$lastLogonCutOff = (Get-Date).AddDays(-120)
Get-ADUser -Filter { LastLogonDate -lt $lastLogonCutOff -and Enabled -eq $true } -SearchBase "OU=Externals,DC=contoso,DC=com" | Disable-ADAccount
Im besten Fall sind die Dienstkonten, die Sie als normale Benutzerkonten und nicht als "Group Managed Service Accounts" (gMSA) anlegen, soweit beschränkt, dass der Logon nur an bestimmten Maschinen stattfinden darf, um Missbrauch zu vermeiden. Das definieren Sie mithilfe des "LogonWorkstations"-Parameters:
Set-ADUser svc_low_SQL3 -LogonWorkstations "SQL3"
Das Attribut "LogonWorkstations" erwartet eine kommaseparierte Liste von Maschinennamen. Möchten Sie etwa einen neuen Serviceaccount erstellen, der sich an allen SQL-Servern anmelden soll, können Sie die Liste in drei Zeilen zusammenbauen:
$sqlServers = Get-ADComputer -Filter "Name -like 'SQL*'" -SearchBase "OU=Servers,OU=Tier1,DC=contoso,DC=com" | SELECT sAMAccountName | %{$_.sAMAccountName.Trim("$")}
$sqlServers = $sqlServers -join ",”
Set-ADUser svc_high_SQL3 -LogonWorkstations $sqlServers
Soll der Service Account nur für ein zeitlich begrenztes Projekt gültig sein oder es erforderlich ist, dass der Besitzer des Accounts auf alle Fälle in spätestens 90 Tagen zurückkommt und den Account verlängert, setzen Sie ein Ablaufdatum:
Set-ADAccountExpiration -Identity svc_low_SQL3 -TimeSpan 90.00:00:00
Mit Sicherheit möchten Sie die Konten, deren Passworte nie ablaufen, so gering wie möglich halten oder im besten Fall sogar komplett eliminieren. Außer Dienstkonten sollten im AD keine Konten zu finden sein, deren Passwort nicht abläuft:
Search-ADAccount -PasswordNeverExpires | Export-CSV C:\temp\csv\neverexpires.csv
Oder Sie verfrachten solche Accounts in eine Gruppe zur delegierten Verwaltung:
Search-ADAccount -PasswordNever- Expires | %{Add-ADGroupMember -Identity "PWDNeverExpires" -Members $_.samaccountName }
Müssen Sie bestimmte Accounts besonders vor Diebstahl schützen und sicherstellen, dass die verwendeten Passworte entsprechend komplex ausfallen, können Sie eigene Passwortrichtlinien an diese Konten heften. Mit wenigen Zeilen PowerShell erstellen Sie beispielsweise ein neues "Password Settings Object", das benutzerdefinierte Passwortrichtlinien beinhaltet, und weisen es einer Gruppe von Dienstkonten zu. Zunächst erstellen Sie das Passwortrichtlinien-Objekt, das manuelle Entsperrung und komplexe, lange Passworte erzwingt:
New-ADFineGrainedPasswordPolicy -Name "HighSecServiceAccounts-
Policy" -Precedence 500 -ComplexityEnabled $true -Description "Password Policy for
High Sec Service Accts" -DisplayName "High Sec Service
Accs PassPolicy" -LockoutDuration "00:00:00" -LockoutObservationWindow
"00:00:00" -LockoutThreshold 7 -MinPasswordAge "01:00:00" -PasswordHistoryCount 20 -MinPasswordLength 16
Danach definieren Sie eine neue AD-Gruppe, in die Sie die Dienstkonten als Mitglieder hinzufügen und anschließend die Richtlinie zuweisen:
New-ADGroup -Name "High Sec Service Accts" -SamAccountName HighSecServiceAccts -GroupCategory Security -GroupScope Global -DisplayName "High Sec Service Accts" -Path "OU=Groups,OU=Service Accounts,DC=contoso,DC=com" -Description "Members of this group are High Security Service Accounts" # Add-ADFineGrainedPasswordPolicySubject -Identity HighSecServiceAccountsPolicy -Subjects 'HighSecServiceAccts'
Zum Schluss suchen und finden Sie die zu schützenden Dienstkonten im AD:
Get-ADUser -Filter 'DisplayName -like "SVC_HIGH_*"' -SearchBase "OU=Service Accounts,DC=contoso, DC=com" | % { Add-ADGroupMember "High Sec Service Accounts" -Members $_ }
Bei der nächsten Passwortänderung müssen sich die Dienstkonten – oder der Admin, der das Passwort zurücksetzt und ändert – an die neuen Passwortrichtlinien halten.
Forest und AD-Dienst managen
Die PowerShell erlaubt, neben der Datenverwaltung im Directory auch den AD-Dienst selbst zu inspizieren. Die Cmdlets ermöglichen das Anlegen neuer Domänencontroller, Domänen, AD-Objekten und Partitionen sowie deren Untersuchung:
$forest = Get-ADForest -Server "contoso.com"
foreach($domain in $forest.Domains) { Get-ADDomainController -Filter * -Server $Domain }
Die FSMO-Rolleninhaber finden Sie mit
Get-ADForest | SELECT DomainNamingMaster, SchemaMaster Get-ADDomain -Name contoso.com | SELECT InfrastructureMaster, PDCEmulator, RIDMaster
Im Get-ADDomain- und Get-ADForest-Cmdlet befinden sich noch zusätzliche Properties, die Sie für eine Inventarisierung oder Überprüfung nutzen können: der DomainFunctionalLevel ist in "DomainMode" mit jeder Domäne, der ForestFunctionalLevel in "ForestMode" auf den Forest-Objekten zu finden.
Möchten Sie Geräte, die zur Domäne hinzugefügt wurden, auch in Entra ID als solche bekannt machen, müssen Sie die Konfiguration für "Hybrid Entra ID Joined"-Geräte vervollständigen. Ein Schritt ist dabei das manuelle oder automatisierte Erstellen des "Service Connection Objects" in der Konfigurationspartition des AD. So prüfen Sie, ob das Objekt angelegt wurde:
configPartition = (Get-ADRootDSE). configurationNamingContext Get-ADObject -Filter * -SearchBase "LDAP://CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,$($configPartition)”
Die AD-Schemaversion prüfen Sie via
Get-ADObject (Get-ADRootDSE). schemaNamingContext -Property objectVersion
Wobei die Version 88 für Windows Server 2019 spricht, 87 für Windows Server 2016 und 69 für Windows Server 2012 R2. Nutzen Sie Exchange, finden Sie die Schemaversion für Exchange auf ähnliche Weise:
Get-ADObject -Identity "CN=ms-Exch-Schema-Version-Pt,$((Get-ADRootDSE).schemaNamingContext)" -Properties rangeUpper | SELECT rangeUpper
Exchange Server 2019 und neuer hat eine Versionsnummer von 17000 oder höher, die Version 2016 liegt bei 15317 bis 15333.
Password Protection auswerten
Wenn Sie Azure AD nutzen und dort Premium-Lizenzen besitzen, verwenden Sie wahrscheinlich auch die "Password Protection for Windows AD"-Funktion, die die Passwortüberprüfung auf Domänencontrollern mit Logik und Einsichten aus dem Azure AD erweitert. Die Funktion verbietet Benutzern beim Passwortwechsel die Wahl von gängigen oder leicht zu erratenden Passworten oder die Sie selbst im Azure AD als "unerwünscht" hinterlegen.
Der dafür auf dem Domänencontroller benötigte Agent protokolliert bei seiner Arbeit, wie viele Änderungen von Passworten zurückgewiesen wurden, weil sie "zu schwach" sind oder auf Ihrer "nicht erwünscht"-Liste liegen:
Get-AzureADPasswordProtection- SummaryReport -DomainController ZRH-DC-01 DomainController: ZRH-DC-01 PasswordChangesValidated: 4 PasswordSetsValidated: 2 PasswordChangesRejected: 7 PasswordSetsRejected: 5 …
Das Kommando lässt sich auch für das gesamte AD nutzen – mit den Schaltern "-Forest" oder" -Domain":
Get-AzureADPasswordProtectionSummaryReport -Domain contoso.com
Fazit
Unser AD-PowerShell-Rundumschlag zeigt, dass Sie schon mit geringen Mitteln gängige Suchen und Tasks automatisieren und kleine Mini-Skripte zur Arbeitserleichterung erstellen und in Ihrem Lieblings-IDE hinterlegen können. Häufig braucht es gar nicht viel: Wer etwas strukturiert seine Administrationsworkstation mit einem guten Code-Editor für die PowerShell ausstattet, kann recht zügig und flexibel mit der Automation des AD beginnen.
PowerShell ermöglicht die automatisierte Verwaltung von Benutzern, Gruppen, Computern und Dienstkonten. Wiederkehrende Aufgaben lassen sich als Skripte speichern und jederzeit reproduzierbar ausführen, wodurch Fehler reduziert und Zeit eingespart werden.
Zu den wichtigsten Cmdlets zählen Get-ADUser, Set-ADUser, New-ADUser, Remove-ADUser, Get-ADGroup, Get-ADGroupMember, Search-ADAccount sowie zahlreiche weitere Befehle zur Verwaltung von Domänen, Forests und Richtlinien.
Unter aktuellen Windows-Versionen ist das Modul Bestandteil der Remote Server Administration Tools (RSAT) beziehungsweise der Windows-Features. Auf Domänencontrollern wird es in der Regel zusammen mit den Active-Directory-Diensten installiert.
Ja. Die Verwaltung muss nicht direkt auf einem Domänencontroller erfolgen. Mit installiertem Active-Directory-Modul können Administratoren PowerShell bequem von einer Verwaltungs-Workstation oder einem Admin-Server aus nutzen.
Hierfür stehen Cmdlets wie Get-ADUser, Get-ADGroup und Search-ADAccount zur Verfügung. Mithilfe von Filtern, Organisationseinheiten (SearchBase) und LDAP-Pfaden lassen sich Suchergebnisse gezielt eingrenzen.
Ja. PowerShell eignet sich besonders für Massenänderungen. Über die Pipeline oder den Import von CSV-Dateien können Attribute vieler Benutzer oder Gruppen in einem einzigen Skript geändert werden.
Mit PowerShell lassen sich inaktive Konten erkennen, Dienstkonten absichern, Passwortrichtlinien zuweisen, Konten deaktivieren sowie sicherheitsrelevante Einstellungen und Konfigurationen regelmäßig überprüfen.
Microsoft empfiehlt heute Visual Studio Code mit der PowerShell-Erweiterung. Die PowerShell ISE ist weiterhin nutzbar, wird jedoch nicht mehr aktiv weiterentwickelt.
Ja. Cmdlets wie Get-ADForest, Get-ADDomain oder Get-ADDomainController liefern Informationen über Forests, Domänen, FSMO-Rollen, Domänencontroller und weitere Komponenten der Active-Directory-Infrastruktur.
PowerShell eignet sich sowohl für Administratoren kleiner Windows-Netzwerke als auch für Unternehmen mit komplexen Active-Directory-Umgebungen. Besonders bei wiederkehrenden Aufgaben und großen Benutzerbeständen spielt die Automatisierung ihre Stärken aus.