Wer regelmäßig fremde Domänen analysiert, hört auf, sich über einzelne Befunde zu wundern. Was zunächst wie individuelle Nachlässigkeit aussieht, ist in Wahrheit ein Satz sehr stabiler Muster – sie entstehen nicht aus Unwissen, sondern aus der Art, wie Verzeichnisdienste über Jahre wachsen: durch Hinzufügen, fast nie durch Entfernen.

Die sieben wiederkehrenden Muster

1. Das Konto, das seit Jahren niemand mehr benutzt – und das noch aktiv ist

Deaktivierung passiert beim Austritt zuverlässig. Das Löschen oder Archivieren passiert nicht, weil niemand die Verantwortung dafür übernehmen will. Problematisch sind aber weniger die deaktivierten Konten als die aktiven ohne Anmeldung: Projektkonten, Testkonten, Konten ehemaliger Aushilfen. Sie haben ein Passwort, oft ein altes, und niemandem fällt auf, wenn es benutzt wird.

2. „Passwort läuft nie ab“ als Dauerlösung

Ursprünglich für ein Dienstkonto gesetzt, dann für den Geschäftsführer, dann für die Buchhaltung, weil die Anrufe beim Servicedesk nervten. Der Haken selbst ist nicht das Problem – bei einem sehr langen, einmalig vergebenen Passwort ist er sogar vertretbar. Das Problem ist die Kombination mit einem acht Jahre alten Passwort aus einer Zeit vor jeder Passwortrichtlinie.

3. Dienstkonten, die alles dürfen

Der Klassiker: Ein Dienstkonto wird bei der Installation in die Domänen-Administratoren aufgenommen, weil die Anleitung des Herstellers das so vorsah oder weil die Fehlersuche schneller ging. Danach fasst es niemand mehr an. In der Auswertung fällt es auf, weil es einen SPN trägt, seit Jahren dasselbe Passwort hat – und in einer hochprivilegierten Gruppe steht.

4. Gruppen, in denen niemand mehr weiß, wozu sie gehören

Berechtigungsgruppen entstehen projektweise, die Benennung ändert sich alle paar Jahre, und irgendwann existieren drei Generationen nebeneinander. Praktisch relevant sind vor allem die verschachtelten Fälle: Die Gruppe A ist Mitglied in B, B in C, und C hat auf einem Fileserver Vollzugriff, an den bei der Erstellung von A niemand gedacht hat.

5. Zu viele Domänen-Administratoren

Eine Faustregel aus der Praxis: In einem Unternehmen mit unter 200 Mitarbeitern sind mehr als drei bis fünf Domänen-Administratoren fast immer ein Befund. Die Zahl steigt schleichend – ein externer Dienstleister hier, ein Projektkonto dort, ein zweites Konto für einen Kollegen, der es „nur kurz“ brauchte.

6. Computerkonten von Geräten, die es nicht mehr gibt

Sie sind selten gefährlich, aber sie verfälschen jede Auswertung: Wer Patchstände, Betriebssystemverteilung oder Lizenzbedarf ermittelt, rechnet mit Karteileichen. Und gelegentlich steht dahinter doch ein Gerät, das noch existiert – im Lager, im Homeoffice, oder als virtuelle Maschine, die niemand abgeschaltet hat.

7. Die Zertifikatvorlage aus einem Projekt von 2018

Sie wurde einmal für einen Test dupliziert, mit weit gefassten Registrierungsrechten versehen und nie zurückgebaut. Zusammen mit der Option, dass der Antragsteller den Antragsnamen selbst angibt, ergibt das einen der bekanntesten Eskalationspfade in Windows-Umgebungen.

Die Kennzahlen, die den Zustand beschreiben

Sie brauchen keine Vollanalyse, um den Zustand einer Domäne einzuschätzen. Sieben Zahlen genügen für eine erste Einordnung – und sie lassen sich in einem Durchlauf erheben:

# ISW - AD-Hygiene: die sieben Kennzahlen in einem Durchlauf
[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
Import-Module ActiveDirectory

$grenze = (Get-Date).AddDays(-90)
$alle   = Get-ADUser -Filter 'Enabled -eq $true' `
            -Properties LastLogonDate, PasswordLastSet, PasswordNeverExpires,
                        ServicePrincipalName, AdminCount, 'msDS-SupportedEncryptionTypes'

$kennzahl = [ordered]@{
  'Aktive Benutzerkonten'              = $alle.Count
  'Seit 90 Tagen keine Anmeldung'      = ($alle | Where-Object { $_.LastLogonDate -lt $grenze -or $null -eq $_.LastLogonDate }).Count
  'Passwort laeuft nie ab'             = ($alle | Where-Object PasswordNeverExpires).Count
  'Passwort aelter als 1 Jahr'         = ($alle | Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-365) }).Count
  'Dienstkonten mit SPN'               = ($alle | Where-Object { $_.ServicePrincipalName }).Count
  'Konten mit AdminCount = 1'          = ($alle | Where-Object { $_.AdminCount -eq 1 }).Count
  'Domaenen-Admins'                    = (Get-ADGroupMember 'Domänen-Admins' -Recursive -ErrorAction SilentlyContinue).Count
}

$kennzahl.GetEnumerator() | ForEach-Object {
    [pscustomobject]@{ Kennzahl = $_.Key; Wert = $_.Value }
} | Format-Table -AutoSize

# Verwaiste Computerkonten (seit 180 Tagen keine Anmeldung)
Get-ADComputer -Filter 'Enabled -eq $true' -Properties LastLogonDate, OperatingSystem |
  Where-Object { $_.LastLogonDate -lt (Get-Date).AddDays(-180) } |
  Select-Object Name, OperatingSystem, LastLogonDate |
  Sort-Object LastLogonDate

Warum das Aufräumen scheitert – und was hilft

Der Grund, warum diese Befunde über Jahre bestehen bleiben, ist selten mangelndes Wissen. Es ist die Verantwortungsfrage: Niemand löscht ein Konto, wenn nicht sicher ist, ob es noch gebraucht wird, und niemand entfernt eine Gruppenmitgliedschaft, wenn die Rückfrage einen Produktionsausfall auslösen könnte. Die Lösung liegt deshalb nicht in einem einmaligen Aufräumprojekt, sondern in einem Ablauf, der die Entscheidung von der Person entkoppelt.