Active Directory – User & Gruppen verwalten

Voraussetzungen und Einstieg

Bevor du loslegen kannst, brauchst du auf deinem Admin-PC die Remote Server Administration Tools (RSAT) mit der AD-DS-Komponente. Auf Windows 10/11 installierst du sie über:

Einstellungen > Apps > Optionale Features > Feature hinzufügen > “RSAT: Active Directory Domain Services”

Oder per PowerShell (als Admin):

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Danach erreichst du die wichtigsten Tools per Win+R:

Für die meisten Alltagsaufgaben arbeitest du in dsa.msc. Für PowerShell-Aufgaben benötigst du das ActiveDirectory-Modul – es ist nach der RSAT-Installation automatisch verfügbar.

Benutzer anlegen

Schritt-für-Schritt in ADUC

1. dsa.msc öffnen
2. In der Domänenstruktur zur richtigen OU (Organizational Unit) navigieren, z.B. firma.local > Benutzer > Mitarbeiter
3. Rechtsklick auf die OU > Neu > Benutzer
4. Felder ausfüllen:
   • Vorname / Nachname – korrekte Schreibweise, denn das ist der Anzeigename
   • Benutzeranmeldungsname (UPN): mmuster@firma.local – das ist das Login-Kürzel
   • Pre-Windows 2000-Anmeldename: mmuster – muss eindeutig in der Domäne sein
5. Passwort setzen und “Benutzer muss Kennwort bei der nächsten Anmeldung ändern” aktivieren
6. Fertigstellen

Per PowerShell anlegen

# Minimales Anlegen eines Benutzers
New-ADUser `
  -Name "Max Muster" `
  -GivenName "Max" `
  -Surname "Muster" `
  -SamAccountName "mmuster" `
  -UserPrincipalName "mmuster@firma.local" `
  -Path "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local" `
  -AccountPassword (ConvertTo-SecureString "Temp@Pass123!" -AsPlainText -Force) `
  -ChangePasswordAtLogon $true `
  -Enabled $true

# Prüfen ob der User angelegt wurde
Get-ADUser -Identity "mmuster" | Select-Object Name, Enabled, UserPrincipalName

Bulk-Import per CSV

Wenn du mehrere User auf einmal anlegen musst (z.B. Onboarding nach Betriebsübernahme), lohnt sich ein CSV-Import:

# CSV-Datei: Name,Vorname,Nachname,OU
# z.B.: mmuster,Max,Muster,"OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local"

Import-Csv "C:\Temp\neue_user.csv" | ForEach-Object {
    New-ADUser `
        -SamAccountName $_.Name `
        -GivenName $_.Vorname `
        -Surname $_.Nachname `
        -Name "$($_.Vorname) $($_.Nachname)" `
        -UserPrincipalName "$($_.Name)@firma.local" `
        -Path $_.OU `
        -AccountPassword (ConvertTo-SecureString "Willkommen1!" -AsPlainText -Force) `
        -ChangePasswordAtLogon $true `
        -Enabled $true
}

Gruppentypen und Gruppenscope verstehen

Das ist der Teil, den viele überspringen – und dann wundern sie sich, warum Berechtigungen nicht wie erwartet funktionieren.

Gruppentypen

Im Alltag arbeitest du fast ausschliesslich mit Sicherheitsgruppen.

Gruppenscope (Geltungsbereich)

Empfohlenes Muster für KMU mit einer Domäne (AGDLP-Prinzip):

Account → Global Group → Domain Local Group → Permission (Ressource)

Konkret: User mmuster ist in der globalen Gruppe GG-IT-Mitarbeiter. Diese ist Mitglied der domänenlokalen Gruppe DL-Freigabe-Projekte-Lesen. Diese Gruppe bekommt die Leseberechtigung auf \\server\Projekte.

Klingt komplex, macht aber die Verwaltung massiv einfacher, wenn 20 Mitarbeiter kommen und gehen.

Gruppen erstellen und befüllen

In ADUC

1. Rechtsklick auf OU > Neu > Gruppe
2. Gruppenname, Scope und Typ festlegen
3. Gruppe öffnen > Reiter Mitglieder > Hinzufügen
4. User-Namen eingeben, Namen überprüfen anklicken, dann OK

Oder andersherum: User-Objekt öffnen > Reiter Mitglied von > Hinzufügen

Per PowerShell

# Gruppe erstellen
New-ADGroup `
  -Name "GG-IT-Mitarbeiter" `
  -GroupScope Global `
  -GroupCategory Security `
  -Path "OU=Gruppen,DC=firma,DC=local" `
  -Description "Alle IT-Mitarbeiter"

# User zur Gruppe hinzufügen
Add-ADGroupMember -Identity "GG-IT-Mitarbeiter" -Members "mmuster", "jschmidt"

# Mitglieder einer Gruppe anzeigen
Get-ADGroupMember -Identity "GG-IT-Mitarbeiter" | Select-Object Name, SamAccountName

# Alle Gruppen eines Users anzeigen
Get-ADPrincipalGroupMembership -Identity "mmuster" | Select-Object Name

# User aus Gruppe entfernen
Remove-ADGroupMember -Identity "GG-IT-Mitarbeiter" -Members "mmuster" -Confirm:$false

Delegation of Control – Helpdesk-Rechte ohne Domain-Admin

Ein klassischer Fehler in gewachsenen KMU-Umgebungen: Der Helpdesk bekommt “der Einfachheit halber” Mitgliedschaft in Domain Admins, nur um Passwörter zurücksetzen oder Konten entsperren zu können. Das ist unnötig riskant – jeder kompromittierte Helpdesk-Account wäre damit ein kompromittierter Domain-Admin. Sauberer ist die gezielte Delegation of Control auf OU-Ebene.

Delegation über den Assistenten (GUI)

1. In dsa.msc Rechtsklick auf die betroffene OU (z.B. OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local) > Objektverwaltung zuweisen (Delegate Control)
2. Gruppe auswählen, z.B. GG-Helpdesk
3. Bei den vordefinierten Aufgaben ankreuzen, was benötigt wird:
   • “Kennwörter für Benutzerkonten zurücksetzen und Benutzer zum Ändern des Kennworts beim nächsten Anmelden zwingen”
   • “Gesperrte Benutzerkonten lesen und entsperren”
   • Optional: “Benutzerkonten erstellen, löschen und verwalten” (nur wenn der Helpdesk wirklich neue User anlegen soll)
4. Assistent abschliessen

Damit kann GG-Helpdesk genau diese Aktionen nur innerhalb dieser OU ausführen – nicht in der ganzen Domäne, und schon gar nicht auf Domain Controllern oder privilegierten Konten.

Delegation per Kommandozeile mit dsacls

Für Dokumentation, Automatisierung oder Audits ist dsacls praktisch, weil sich die Rechte auch wieder auslesen lassen:

# Passwort-Reset-Recht für GG-Helpdesk auf der Mitarbeiter-OU setzen
dsacls "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local" /I:S /G "FIRMA\GG-Helpdesk:CA;Reset Password;user"

# Recht zum Entsperren von Konten (Schreibrecht auf lockoutTime-Attribut)
dsacls "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local" /I:S /G "FIRMA\GG-Helpdesk:WP;lockoutTime;user"

# Vergebene Rechte auf einer OU auflisten (zur Kontrolle)
dsacls "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local"

Fine-Grained Password Policies (PSO)

Standardmässig gilt für eine gesamte Domäne genau eine Passwortrichtlinie (Default Domain Policy). Das reicht selten: Ein Service-Account oder ein IT-Admin-Konto sollte strengere Vorgaben haben (länger, mehr Historie, kürzere maximale Gültigkeit) als ein normaler Mitarbeiter-Account. Dafür gibt es seit Windows Server 2008 Fine-Grained Password Policies, umgesetzt über sogenannte Password Settings Objects (PSO).

PSO anlegen und zuweisen

# Strengere Richtlinie für IT-Admin-Konten erstellen
New-ADFineGrainedPasswordPolicy -Name "PSO-IT-Admins" `
  -Precedence 10 `
  -ComplexityEnabled $true `
  -MinPasswordLength 16 `
  -PasswordHistoryCount 24 `
  -MaxPasswordAge "60.00:00:00" `
  -MinPasswordAge "1.00:00:00" `
  -LockoutThreshold 5 `
  -LockoutObservationWindow "00:30:00" `
  -LockoutDuration "00:30:00" `
  -ReversibleEncryptionEnabled $false

# PSO einer globalen Sicherheitsgruppe zuweisen (PSOs gelten für User oder globale Gruppen, nicht direkt für OUs)
Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-IT-Admins" -Subjects "GG-IT-Admins"

# Alle PSOs mit ihrer Priorität anzeigen
Get-ADFineGrainedPasswordPolicy -Filter * | Select-Object Name, Precedence, MinPasswordLength

# Welche Richtlinie gilt tatsächlich für einen bestimmten User?
Get-ADUserResultantPasswordPolicy -Identity mmuster

Wichtig ist der Parameter Precedence: Gilt für einen User mehr als ein PSO (z.B. weil er in mehreren Gruppen mit je eigenem PSO ist), gewinnt der niedrigste Precedence-Wert.

Mehr zu Passwortstrategien und ergänzenden Massnahmen findest du unter Passwort-Management.

Lokale Admin-Passwörter automatisieren: Windows LAPS

Ein häufiger Befund in Sicherheits-Audits: Alle Windows-Rechner haben das gleiche lokale Administrator-Passwort. Ist ein Gerät kompromittiert, kann ein Angreifer sich damit per Pass-the-Hash sofort seitlich (lateral movement) auf alle anderen Rechner der Domäne bewegen. Windows LAPS (Local Administrator Password Solution, seit Windows 11 22H2 / Server 2022 nativ im OS enthalten, Nachfolger des separaten “Legacy LAPS”-Tools) löst das, indem jeder Rechner ein eigenes, zufälliges, regelmässig rotierendes lokales Admin-Passwort bekommt – verschlüsselt in AD (oder Entra ID) hinterlegt.

Einrichtung Schritt für Schritt

# 1. Einmalig: AD-Schema um die LAPS-Attribute erweitern (Schema-Admin-Rechte nötig)
Update-LapsADSchema

# 2. OU berechtigen: Computerobjekte dürfen ihr eigenes Passwort-Attribut schreiben
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=firma,DC=local"

# 3. Helpdesk-Gruppe Leserecht auf das verschlüsselte Passwort-Attribut geben
dsacls "OU=Workstations,DC=firma,DC=local" /I:S /G "FIRMA\GG-Helpdesk:CA;ms-Mcs-AdmPwd;computer"

4. Danach per GPO konfigurieren: Computerkonfiguration > Richtlinien > Administrative Vorlagen > System > LAPS – dort mindestens “Kennwort-Sicherungsverzeichnis konfigurieren” auf Active Directory setzen sowie Länge, Komplexität und Rotationsintervall des Passworts festlegen. GPO auf die Workstation-OU verknüpfen.

5. Passwort eines Rechners abrufen (nur für berechtigte Gruppen sichtbar):

Get-LapsADPassword -Identity "PC-VERTRIEB-05" -AsPlainText

Dienstkonten ohne Klartext-Passwort: Group Managed Service Accounts (gMSA)

Klassische Service-Accounts sind ein Dauerbrenner in Sicherheits-Audits: statisches Passwort, das nie rotiert wird, oft im Klartext in einer Konfigurationsdatei oder einem Scheduled-Task-Wizard hinterlegt. Group Managed Service Accounts (gMSA) lösen das: AD verwaltet das Passwort komplett selbst (Standard-Rotation alle 30 Tage), es ist 240 Zeichen lang und wird nie im Klartext irgendwo gespeichert – nur autorisierte Computerkonten dürfen es überhaupt abrufen.

Voraussetzung: KDS-Root-Key

gMSA-Passwörter werden über den Key Distribution Service (KDS) abgeleitet. Dafür braucht die Domäne einmalig einen KDS-Root-Key:

# Produktiv: sofort wirksam machen, dann ca. 10 Stunden auf Replikation an alle DCs warten,
# bevor der erste gMSA erstellt wird (KDS-Root-Key muss überall repliziert sein)
Add-KdsRootKey -EffectiveImmediately

# Nur im Testlabor: den Key rückdatieren, um die Wartezeit zu umgehen
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

gMSA erstellen und einsetzen

# gMSA erstellen – nur Mitglieder der Gruppe GG-SQL-Server dürfen das Passwort abrufen
New-ADServiceAccount -Name "svc-sqlbackup" `
  -DNSHostName "svc-sqlbackup.firma.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "GG-SQL-Server" `
  -Enabled $true

# Computerkonto des Zielservers in die berechtigte Gruppe aufnehmen
Add-ADGroupMember -Identity "GG-SQL-Server" -Members "SRV-SQL01$"

# Auf dem Zielserver: gMSA installieren und testen
Install-ADServiceAccount -Identity "svc-sqlbackup"
Test-ADServiceAccount -Identity "svc-sqlbackup"

Den Dienst oder Scheduled Task konfigurierst du danach mit dem Konto FIRMA\svc-sqlbackup$ ohne Passwort – Windows holt es selbstständig vom KDS ab.

Tägliche Verwaltungsaufgaben

Passwort zurücksetzen

ADUC: Rechtsklick auf User > Kennwort zurücksetzen > neues Passwort eingeben + “Benutzer muss Kennwort bei nächster Anmeldung ändern” setzen.

# Passwort zurücksetzen
Set-ADAccountPassword `
  -Identity "mmuster" `
  -Reset `
  -NewPassword (ConvertTo-SecureString "NeuesTemp@2026!" -AsPlainText -Force)

# Gleichzeitig erzwingen, dass er es beim Login ändern muss
Set-ADUser -Identity "mmuster" -ChangePasswordAtLogon $true

Konto entsperren

Gesperrte Konten entstehen durch fehlgeschlagene Login-Versuche (Passwort vergessen, altes Passwort im Handy hinterlegt, etc.).

ADUC: User > Eigenschaften > Reiter Konto > Haken bei “Konto ist gesperrt” entfernen

# Einzelnes Konto entsperren
Unlock-ADAccount -Identity "mmuster"

# Alle gesperrten Konten auf einmal finden
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut

# Alle gesperrten Konten entsperren (vorsichtig einsetzen!)
Search-ADAccount -LockedOut | Unlock-ADAccount

Konto deaktivieren und reaktivieren

# Deaktivieren (z.B. beim Offboarding)
Disable-ADAccount -Identity "mmuster"

# Reaktivieren (z.B. nach Rückkehr aus Elternzeit)
Enable-ADAccount -Identity "mmuster"

# Alle deaktivierten Accounts anzeigen
Get-ADUser -Filter {Enabled -eq $false} | Select-Object Name, SamAccountName

Kontoablauf setzen

Nützlich für befristete Anstellungen oder externe Dienstleister:

# Konto läuft am 31.12.2026 ab
Set-ADAccountExpiration -Identity "mmuster" -DateTime "2026-12-31"

# Ablauf entfernen
Clear-ADAccountExpiration -Identity "mmuster"

Offboarding-Checkliste

Wenn ein Mitarbeiter das Unternehmen verlässt, ist eine geordnete Vorgehensweise wichtig:

1. AD-Konto deaktivieren (nicht löschen!)
2. Passwort zurücksetzen (verhindert, dass die Person weiter einloggen kann, selbst wenn sie das Passwort noch kennt)
3. Aus Gruppen entfernen oder Gruppen mit zu viel Zugriff prüfen
4. Postfach weiterleiten oder als Shared Mailbox umwandeln (Exchange/M365)
5. Home-Verzeichnis sichern und ggf. auf Nachfolger übertragen
6. Kontoablauf setzen als Sicherheitsnetz
7. Nach 30-60 Tagen: Konto endgültig löschen, Mailbox archivieren

# Schnell-Offboarding per PowerShell
$user = "mmuster"

Disable-ADAccount -Identity $user
Set-ADAccountPassword -Identity $user -Reset `
    -NewPassword (ConvertTo-SecureString ([System.Web.Security.Membership]::GeneratePassword(20,4)) -AsPlainText -Force)

# Aus allen Gruppen entfernen (ausser "Domain Users", das geht eh nicht)
Get-ADPrincipalGroupMembership -Identity $user |
    Where-Object {$_.Name -ne "Domain Users"} |
    ForEach-Object { Remove-ADGroupMember -Identity $_.Name -Members $user -Confirm:$false }

Write-Host "Offboarding $user abgeschlossen." -ForegroundColor Green

Suchen und Filtern in AD

# User mit bestimmtem Attribut suchen
Get-ADUser -Filter {Department -eq "IT"} -Properties Department | Select-Object Name, Department

# User, die sich in den letzten 90 Tagen nicht angemeldet haben
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {LastLogonDate -lt $cutoff -and Enabled -eq $true} `
    -Properties LastLogonDate | Select-Object Name, LastLogonDate | Sort-Object LastLogonDate

# User in einer bestimmten OU
Get-ADUser -SearchBase "OU=Mitarbeiter,OU=Benutzer,DC=firma,DC=local" -Filter * |
    Select-Object Name, SamAccountName

# Alle Mitglieder einer Gruppe inkl. verschachtelter Gruppen
Get-ADGroupMember -Identity "GG-IT-Mitarbeiter" -Recursive | Select-Object Name

Reporting: Stale Accounts finden

“Stale Accounts” – Konten, die seit Monaten nicht mehr genutzt wurden – sind ein beliebtes Ziel für Angreifer, weil sie oft übersehen werden. Ein regelmässiger Report gehört in jede saubere AD-Pflege:

# Inaktive, aber noch aktivierte User-Konten (LastLogonTimestamp ist repliziert, daher domänenweit zuverlässig)
$cutoff = (Get-Date).AddDays(-90)
Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonTimestamp, PasswordLastSet |
    Where-Object { $_.LastLogonTimestamp -and [DateTime]::FromFileTime($_.LastLogonTimestamp) -lt $cutoff } |
    Select-Object Name, SamAccountName, @{N='LetzterLogin';E={[DateTime]::FromFileTime($_.LastLogonTimestamp)}} |
    Export-Csv "C:\Reports\stale_users.csv" -NoTypeInformation -Encoding UTF8

# Das Gleiche für Computerkonten (typisch für ausrangierte Laptops, die nie ausgetragen wurden)
Get-ADComputer -Filter {Enabled -eq $true} -Properties LastLogonTimestamp |
    Where-Object { $_.LastLogonTimestamp -and [DateTime]::FromFileTime($_.LastLogonTimestamp) -lt $cutoff } |
    Select-Object Name, @{N='LetzterLogin';E={[DateTime]::FromFileTime($_.LastLogonTimestamp)}}

Reporting: Verschachtelte Gruppen sichtbar machen

Tief verschachtelte Gruppen (Gruppe in Gruppe in Gruppe) erschweren Troubleshooting massiv und können in Extremfällen sogar den Kerberos-Token eines Users sprengen (Standard-Limit ca. 48 KB, “Token Bloat”). Eine einfache Funktion zeigt die Verschachtelungstiefe:

function Get-NestedGroupDepth {
    param($GroupName, $Depth = 0)
    $members = Get-ADGroupMember -Identity $GroupName | Where-Object { $_.objectClass -eq 'group' }
    foreach ($m in $members) {
        [PSCustomObject]@{ Gruppe = $GroupName; Untergruppe = $m.Name; Tiefe = $Depth + 1 }
        Get-NestedGroupDepth -GroupName $m.Name -Depth ($Depth + 1)
    }
}

Get-NestedGroupDepth -GroupName "GG-IT-Mitarbeiter" | Format-Table -AutoSize

Als Faustregel: Mehr als 2-3 Verschachtelungsebenen sind in einer KMU-Umgebung fast immer ein Zeichen dafür, dass die Gruppenstruktur aufgeräumt werden sollte.

Auditing von Gruppenänderungen

Wer wurde wann in die Gruppe Domain Admins aufgenommen? Ohne aktiviertes Auditing lässt sich diese Frage im Nachhinein schlicht nicht beantworten – und genau das fragen Auditoren (und Versicherungen, siehe auch NIS2) gerne als Erstes.

Auditing aktivieren

Am saubersten per GPO: Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Kontenverwaltung > “Sicherheitsgruppenverwaltung” auf Erfolg (und optional Fehler) setzen, verknüpft mit den Domain Controllern.

Alternativ direkt auf einem DC per auditpol:

auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable

Relevante Event-IDs

Events auswerten

# Die letzten 50 Gruppenänderungen auf einem DC anzeigen
Get-WinEvent -FilterHashtable @{LogName = 'Security'; Id = 4728, 4729, 4732, 4733, 4756, 4757 } -MaxEvents 50 |
    Select-Object TimeCreated, Id, Message

Besonders wichtig: Überwache speziell Änderungen an Domain Admins, Enterprise Admins, Schema Admins und anderen Tier-0-Gruppen engmaschig – idealerweise mit einer Alarmierung, nicht erst beim nächsten manuellen Review. Mehr dazu im Artikel zum AD-Tier-Modell.

Troubleshooting häufiger Probleme

User kann sich nicht anmelden

Berechtigungen wirken nicht

1. Gruppenrichtlinien neu einlesen: gpupdate /force auf dem Client
2. Token-Problem: Der Sicherheitstoken eines Benutzers wird bei der Anmeldung erstellt. Wenn du nach dem Gruppenhinzufügen keine Wirkung siehst, muss sich der User ab- und wieder anmelden (neuer Token mit aktuellen Gruppenmitgliedschaften)
3. Verschachtelung prüfen: Get-ADPrincipalGroupMembership -Identity mmuster -Recursive
4. NTFS vs. Share-Berechtigungen: Beide Ebenen müssen passen (siehe Dateifreigaben & Berechtigungen)

Replikationsprobleme zwischen DCs

# Replikationsstatus prüfen
repadmin /showrepl

# Replikation erzwingen
repadmin /syncall /AdeP

Weiterlernen

• Microsoft Learn: Verwalten von Benutzerkonten in ADUC
• Microsoft Learn: Active Directory-Sicherheitsgruppen
• Microsoft Learn: New-ADUser (PowerShell Referenz)
• Microsoft Learn: Add-ADGroupMember (PowerShell Referenz)
• Microsoft Learn: Fine-Grained Password Policies konfigurieren
• Microsoft Learn: Group Managed Service Accounts verwalten
• Microsoft Learn: Windows LAPS PowerShell-Cmdlets im Überblick
• Microsoft Learn: Audit Security Group Management
• WindowsPro: Globale, domänenlokale und universale Gruppen erklärt
• Petri: Manage Active Directory Groups Using PowerShell

Passende Wiki-Seiten: AD Grundlagen | AD Security Hardening & Tier-Modell | GPO Grundlagen | Passwort-Management | PowerShell IT-Alltag | Dateifreigaben & Berechtigungen | SIEM/SOC-Grundlagen