Windows Active Directory mit der PowerShell verwalten
Gut geordnet
Veröffentlicht in Ausgabe 03/2021 - SCHWERPUNKT
Das Active Directory (AD) ist mehr als 20 Jahre alt und Administratoren haben viele Erfahrungen bei der Wartung und Bedienung 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 aller anderen Objekte 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-Scripter, 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 die Einzeiler oder Skripte direkt mit farblicher Kennzeichnung ausführen und so 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.
Das Active Directory (AD) ist mehr als 20 Jahre alt und Administratoren haben viele Erfahrungen bei der Wartung und Bedienung 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 aller anderen Objekte 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-Scripter, 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 die Einzeiler oder Skripte direkt mit farblicher Kennzeichnung ausführen und so 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 Windowsversionen zur Verfügung steht und als Extension den "PowerShell Language Support for Visual Studio Code" bietet. Die Extension kommt dann mit intelligenten Vorschlägen für Parameter und der Einfärbung der Kommandos zur visuellen, besseren Verarbeitung von Tasks.
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 [1].
Auf Domänencontrollern werden Sie bei der Promotion gefragt, ob Sie die Verwaltungstools und PowerShell zusammen mit der Domänencontrollerrolle 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 Win-dows PowerShell). Diesen Vorgang können Sie aber auch per PowerShell erledigen:
Import-Module ServerManager
Add-WindowsFeature -Name "RSAT-AD-PowerShell" –IncludeAllSubFeature
Ist das erledigt, können Sie wie folgt einen Überblick über die verfügbaren Kommandos gewinnen:
Get-Command -Module ActiveDirectory
So erhalten Sie alle verfügbaren Cmd-lets, die Sie für das Microsoft 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.
Im Active Directory suchen
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 flofromm.
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 "corp.frickelsoft.net" wie folgt beschrieben wird:
Get-ADUser -Filter * -SearchBase "OU=Externals,DC=corp,DC=frickelsoft,DC=net"
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=corp,DC=Frickelsoft,DC=net”
Fragen Sie mit dem Get-ADGroup-Cmdlet explizit nach den Gruppenmitgliedern als Attribut, erhalten Sie diese nur als Textausgabe. Für die 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 die Mitgliederliste in einem weiteren Befehl 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, im zweiten Beispiel in eine CSV-Datei:
Get-ADGroup -Filter "Name -like 'HR*'" -SearchBase 'OU=Groups, DC=nttest,DC=corp,DC=frickelsoft,DC=net' -SearchScope SubTree | Get-ADGroupMember
Get-ADGroup -Filter "Name -like 'HR*'" -SearchBase 'OU=Groups,DC=nttest,DC=corp,DC=frickelsoft,DC=net' -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=corp,DC=frickelsoft,DC=net" | Set-ADUser -Add @{extensionAttribute4 = "M365"}
Über eine importierte CSV-Datei können Sie auch zahlreiche Benutzer bearbeiten:
Import-CSV 'C:\temp\csv\users.csv' | % { if($_.mail -like '*@frickelsoft.net') { Set-ADUser $_.SamAccountName -Add @{extensionAttribute4 = "M365"}}}
Dieser Befehl importiert eine CSV-Datei und geht diese zeilenweise durch. Das CSV-File beinhaltet Benutzerdefinitionem, wobei zwei Spalten im CSV genauer betrachtet werden: "mail" und "SamAccountName". Wenn die Mailaddresse in der CSV-Spalte "mail" mit "@frickelsoft. net" 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" 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 auch Konten von externen Partnern und Lieferanten oder Dienstkonten verwalten. Nicht mehr benötigte Konten deaktivieren Sie einfach:
Get-ADUser -Identity svc_low_SQL3 | Disable-ADAccount
Das klappt auch mit Konten von externen Identitäten, die in einer OU gruppiert sind. So sperren Sie Personen oder Dienstkonten, die sich schon 120 oder mehr Tage nicht angemeldet haben:
$lastLogonCutOff = (Get-Date).AddDays(-120)
Get-ADUser -Filter { LastLogonDate -lt $lastLogonCutOff -and Enabled -eq $true } -SearchBase "OU=Externals,DC=corp,DC=frickelsoft,DC=net" | 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. So erstellen Sie zum Beispiel einen neuen Service-Account, der sich an allen SQL-Servern anmelden soll:
$sqlServers = Get-ADComputer -Filter "Name -like 'SQL*'" -SearchBase "OU=Servers,OU=Tier1,DC=corp,DC=frickelsoft,DC=net" | 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 oder es erforderlich sein, 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 wollen Sie die Konten, deren Passworte nie ablaufen, so gering wie möglich halten. 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 Administration:
Search-ADAccount -PasswordNeverExpires | %{Add-ADGroupMember -Identity "PWDNeverExpires" -Members $_.samaccountName }
Müssen Sie bestimmte Accounts besonders vor Diebstahl schützen und sicherstellen, dass die verwendeten Passworte entsprechend komplex sind, können Sie eigene Passwortrichtlinien an diese Accounts heften. Mit wenigen Zeilen PowerShell erstellen Sie beispielsweise eine 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 "HighSecServiceAccountsPolicy" -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 HighSecSer-viceAccts -GroupCategory Security -GroupScope Global -DisplayName "High Sec Service Accts" -Path "OU=Groups,OU=Service Accounts, DC=corp,DC=frickelsoft,DC=net" -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= corp,DC=frickelsoft,DC=net" | % { 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-Objekte und Partitionen sowie deren Untersuchung:
$forest = Get-ADForest -Server "corp.frickelsoft.net"
foreach($domain in $forest.Domains) { Get-ADDomainController -Filter * -Server $Domain }
Die FSMO-Rollen-Inhaber zeigen Ihnen die folgenden beiden Cmdlets:
Get-ADForest | SELECT DomainNamingMaster, SchemaMaster
Get-ADDomain -Name corp.frickelsoft.net | 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.
Wollen Sie Geräte, die zur Domäne hinzugefügt wurden, auch im Azure AD als solche bekannt machen, müssen Sie "Hybrid Azure AD Join" konfigurieren. Ein Schritt bei der Konfiguration ist die manuelle oder automatisierte Erstellung des "Service Connection Objects" in der Konfigurationspartition des AD. So prüfen Sie, ob das Objekt erstellt 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 mit der PowerShell über diesen Befehl:
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 so:
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 Exchange-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 solchen, die Sie selbst im Azure AD als "unerwünscht" hinterlegen [2]. 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-AzureADPasswordProtectionSummaryReport -DomainController NTTEST-DC-01
DomainController: NTTEST-DC-01
PasswordChangesValidated: 4
PasswordSetsValidated: 2
PasswordChangesRejected: 7
PasswordSetsRejected: 5
…
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. Oft 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 Active Directory beginnen.
(jp)
Link-Codes
[1] Remote Server Administration Toolkit: https://docs.microsoft.com/de-de/windows-server/remote/remote-server-administration-tools/
[2] Azure AD Password Protection: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy/