AD Security Hardening – Tier-Modell und Angriffsfläche reduzieren

Warum “normales” AD-Admin-Verhalten das Problem ist

Wenn du seit Jahren AD betreust, kennst du das Muster: Der Domain-Admin-Account meldet sich per RDP auf dem Fileserver an, um mal eben eine Freigabe zu reparieren. Der gleiche Account läuft am Nachmittag auf einer Workstation, weil dort ein Softwareproblem gelöst werden muss. Genau das ist der Angriffsvektor, mit dem die meisten Ransomware-Gruppen in Schweizer KMU innert Stunden von “ein Notebook ist infiziert” zu “wir haben die ganze Domäne” kommen.

Das Grundproblem heisst Credential Exposure auf niedrigeren Vertrauensstufen: Sobald ein privilegiertes Credential auf einem weniger vertrauenswürdigen System landet (Cache, LSASS-Speicher, Token), kann es dort gestohlen werden – unabhängig davon, wie gut Passwort-Policy oder MFA sonst sind. Microsofts Antwort darauf ist das Tier-Modell (heute Teil des breiteren Enterprise Access Model), ergänzt durch konkrete technische Massnahmen: Privileged Access Workstations, Protected Users, LAPS und eine Angriffsanalyse mit BloodHound, um zu sehen, wo die Theorie in deiner echten Domäne bereits gebrochen ist.

Dieser Artikel baut auf den Grundlagen aus Active Directory – Grundlagen und Benutzer und Gruppen in AD auf und geht davon aus, dass du GPOs, OU-Struktur und Kerberos-Grundmechanik bereits kennst.

Das Tier-Modell: Grundidee und die drei (bzw. vier) Ebenen

Die Kernregel des Tier-Modells ist denkbar einfach, aber in der Praxis schwer durchzuhalten:

Ein Credential aus einer höheren Vertrauensstufe darf niemals auf einem System einer niedrigeren Stufe verwendet werden.

Microsoft unterteilt klassisch in drei Tiers, wobei das aktuelle Enterprise Access Model Tier 0 als “Control Plane” nochmals schärfer fasst und Tier 1 in Management- und Workload-Ebenen aufteilt. Für ein KMU reicht in der Regel die klassische Dreiteilung als mentales Modell, du solltest aber wissen, dass Microsoft inzwischen granularer denkt.

Die zentrale Konsequenz für den Alltag: Ein Tier-0-Account (z. B. adm-t0-sweber) darf sich nur auf Domain Controllern und deren direkter Verwaltungsinfrastruktur anmelden – niemals auf einem Fileserver (Tier 1) und schon gar nicht auf einer Workstation (Tier 2). Umgekehrt darf ein Helpdesk-Account (Tier 2) niemals Rechte auf Tier-1- oder Tier-0-Systemen haben.

Warum “eine Anmeldung reicht” für einen Totalschaden sorgt

Meldet sich ein Domain-Admin-Konto per RDP auf einer Workstation an, landet sein Kerberos-Ticket-Granting-Ticket (TGT) beziehungsweise NTLM-Hash im LSASS-Prozessspeicher dieser Maschine. Ist die Workstation kompromittiert (z. B. durch eine Phishing-Mail mit Infostealer), kann ein Angreifer mit Tools wie Mimikatz diesen Hash extrahieren und hat damit faktisch Domain-Admin-Rechte – ganz ohne das Passwort je zu kennen. Das nennt sich Pass-the-Hash bzw. Pass-the-Ticket. Das Tier-Modell verhindert genau dieses Szenario strukturell, weil das privilegierte Credential gar nie auf der niedrigeren Ebene auftaucht.

Praktische Umsetzung im KMU: OU-Struktur und GPO-Trennung

firma.ch (Root)
├── Tier0
│   ├── Accounts        (adm-t0-*, gMSA für Tier-0-Dienste)
│   ├── Groups          (Domain Admins, Enterprise Admins, T0-Admins-Custom)
│   └── Servers         (DCs, ADFS, ADCS, Entra Connect)
├── Tier1
│   ├── Accounts        (adm-t1-*)
│   ├── Groups          (Server-Admins)
│   └── Servers         (Fileserver, SQL, App-Server)
├── Tier2
│   ├── Accounts        (adm-t2-*, Helpdesk)
│   ├── Groups          (Helpdesk-Admins)
│   └── Workstations
└── Company
    ├── Users           (normale Mitarbeiterkonten, keine Adminrechte)
    └── Computers

Über GPOs setzt du dann User Rights Assignment so, dass Tier-1- und Tier-2-Konten explizit von “Allow log on locally” bzw. “Allow log on through Remote Desktop Services” auf Tier-0-Systemen ausgeschlossen werden (und umgekehrt Tier-0-Konten auf Tier-1/2-Systemen). Das lässt sich mit Authentication Policies und Silos (ab Windows Server 2012 R2 Functional Level) sogar zentral in AD selbst durchsetzen, statt nur per GPO auf jedem Server einzeln:

# Authentication Policy Silo für Tier 0 anlegen
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
  -UserAllowedToAuthenticateFrom "O:SYG:SYD:(A;;CR;;;WD)" `
  -Description "Nur Tier-0-Accounts duerfen sich auf Tier-0-Systemen anmelden"

# Tier-0-Admin-Gruppe dem Silo zuweisen
Set-ADAccountAuthenticationPolicySilo -Identity "adm-t0-sweber" -AuthenticationPolicySilo "Tier0-Silo"

# Kerberos Claims und Device Claims fuer Silo aktivieren (Voraussetzung)
Set-ADDomain -Identity firma.ch -KerberosArmoring Enabled

Privileged Access Workstations (PAW)

Das Tier-Modell auf Konten-Ebene reicht nicht, wenn die Quelle der Administration kompromittiert ist. Meldest du dich mit deinem Tier-0-Account auf deinem normalen Büro-Notebook an – auf dem auch Outlook, Browser und der letzte PDF-Anhang laufen – ist die Kontentrennung wertlos, sobald das Notebook Malware hat.

Eine Privileged Access Workstation (PAW) ist eine dedizierte, stark gehärtete Maschine, die ausschliesslich für administrative Tätigkeiten der jeweiligen Tier-Stufe genutzt wird. Kein E-Mail, kein Web-Browsing (ausser zu den Admin-Portalen selbst), keine Office-Dokumente.

PAW-Varianten für KMU-Budgets

Für ein Schweizer KMU mit 50–300 Mitarbeitenden ist meist eine Kombination sinnvoll: ein gehärteter Jump-Server für Tier-0-Zugriffe (RDP mit Restricted Admin Mode) plus physische oder Cloud-PC-PAWs für die zwei bis drei Personen, die tatsächlich Domain-Admin-Rechte brauchen.

Minimal-Hardening einer PAW

# Applocker/WDAC: nur signierte, freigegebene Software erlauben
New-CIPolicy -Level Publisher -FilePath C:\PAW\Policy.xml -UserPEs

# RDP Restricted Admin Mode erzwingen (kein Credential-Caching auf Zielsystem)
reg add "HKLM\System\CurrentControlSet\Control\Lsa" /v DisableRestrictedAdmin /t REG_DWORD /d 0 /f

# Windows Defender Application Control aktivieren + Credential Guard
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor

; GPO: Credential Guard aktivieren (Local Group Policy / Registry-Pfad)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard]
"EnableVirtualizationBasedSecurity"=dword:00000001
"RequirePlatformSecurityFeatures"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA]
"LsaCfgFlags"=dword:00000001

Credential Guard isoliert LSASS-Secrets in einem virtualisierten, vom OS-Kernel getrennten Container (VBS), sodass klassisches Mimikatz-Dumping selbst bei lokaler Admin-Kompromittierung ins Leere läuft. Voraussetzung: UEFI, Secure Boot, TPM 2.0 und ein 64-Bit-CPU mit Virtualisierungserweiterungen (VT-x/AMD-V).

Kerberoasting verstehen und abwehren

Kerberoasting ist der wohl unterschätzteste Angriff in AD-Umgebungen, weil er mit einem völlig legitimen, unauthentifizierten Kerberos-Feature funktioniert: Jeder authentifizierte Domänenbenutzer darf ein Service Ticket (TGS) für jeden Dienst mit registriertem Service Principal Name (SPN) anfordern – etwa für einen SQL-Server-Dienstaccount.

Der Ablauf

1. Angreifer (mit einem gewöhnlichen, unprivilegierten Domänen-Account) fragt beim Domain Controller ein TGS für einen SPN an, z. B. MSSQLSvc/sql01.firma.ch:1433.
2. Der DC verschlüsselt einen Teil des Tickets mit dem NTLM-Hash des Passworts des zugehörigen Dienstkontos – das ist Standardverhalten, kein Fehler.
3. Der Angreifer nimmt das Ticket offline mit und versucht per Brute-Force/Dictionary-Attack (mit Tools wie Hashcat), das Passwort zu knacken.
4. Ist das Dienstkonto-Passwort schwach (was bei alten Service-Accounts erschreckend oft der Fall ist – “wurde 2016 gesetzt und nie geändert”), hat der Angreifer nach Minuten bis Stunden das Klartextpasswort.

# So einfach findet ein Angreifer kerberoastbare Accounts (PowerShell, kein Tool-Download noetig)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName |
  Select-Object Name, ServicePrincipalName

Gegenmassnahmen, priorisiert nach Aufwand/Nutzen

# gMSA erstellen und einem SQL-Server zuweisen
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))  # einmalig pro Forest, KDS-Root-Key

New-ADServiceAccount -Name "gmsa-sql01" `
  -DNSHostName "sql01.firma.ch" `
  -PrincipalsAllowedToRetrieveManagedPassword "SQL01$" `
  -KerberosEncryptionType AES256

# Auf dem Zielserver installieren und testen
Install-ADServiceAccount -Identity "gmsa-sql01"
Test-ADServiceAccount -Identity "gmsa-sql01"

# RC4 fuer ein Dienstkonto deaktivieren, nur AES256 erlauben
Set-ADAccountControl -Identity "svc-legacy-app" -UseDESKeyOnly $false
Set-ADUser -Identity "svc-legacy-app" -KerberosEncryptionType AES256

Golden Ticket, Silver Ticket und der DCsync-Weg dorthin

Während Kerberoasting “nur” ein Dienstkonto kompromittiert, zielt ein Golden-Ticket-Angriff auf die Wurzel des Vertrauens: den KRBTGT-Account. Jeder Domain Controller nutzt den Hash dieses Kontos, um Ticket-Granting-Tickets (TGTs) zu signieren. Kennt ein Angreifer diesen Hash, kann er beliebige TGTs für beliebige Benutzer (inklusive nicht-existenter!) fälschen – mit beliebiger Gruppenmitgliedschaft, beliebiger Gültigkeitsdauer (Standard oft 10 Jahre in Angriffs-Tools) und ganz ohne dass ein echtes Passwort je involviert war.

Wie Angreifer an den KRBTGT-Hash kommen

Der übliche Weg ist DCSync: Ein Angreifer mit Replikationsrechten (Replicating Directory Changes und Replicating Directory Changes All – normalerweise nur Domain Admins und DCs selbst) täuscht gegenüber einem echten DC vor, selbst ein Domain Controller zu sein, und “repliziert” einfach den KRBTGT-Hash (und praktisch jeden anderen Hash) ab.

# Pruefen, wer ausser Domain Admins/Enterprise Admins Replikationsrechte hat
# (jedes zusaetzliche Konto hier ist ein potenzielles DCSync-Risiko)
dsacls "DC=firma,DC=ch" | Select-String "Replicating Directory Changes"

Abwehr- und Erkennungsstrategie

# KRBTGT-Passwort rotieren - Skript von Microsoft (New-KrbtgtKeys.ps1) nutzen,
# NICHT manuell per Set-ADAccountPassword, da Replikationstiming kritisch ist
.\New-KrbtgtKeys.ps1 -TargetDomain firma.ch -Mode Rotate

Ein Silver Ticket ist die kleinere, gezieltere Variante: Statt den KRBTGT-Hash zu fälschen, wird nur der Hash eines einzelnen Dienstkontos (z. B. eines Fileservers) verwendet, um ein Service Ticket für genau diesen Dienst zu fälschen – unauffälliger, aber auf einen Dienst begrenzt.

Die Protected Users-Gruppe

Die eingebaute Gruppe Protected Users (verfügbar ab Windows Server 2012 R2 Domain Functional Level) ist ein scharfes, aber wirkungsvolles Werkzeug. Mitglieder dieser Gruppe erhalten automatisch mehrere Schutzmechanismen, ohne dass du einzeln GPOs konfigurieren musst:

• Kein NTLM-Fallback – Authentifizierung läuft ausschliesslich über Kerberos
• Kein DES oder RC4 in der Kerberos-Voranmeldung – nur noch AES
• Kein Kerberos-Delegation (weder unconstrained noch constrained) möglich
• Kein Credential-Caching – das TGT wird nicht länger als 4 Stunden zwischengespeichert und es gibt keinen Klartext-Cache für Offline-Login
• Keine NTLM-Hash- oder Klartext-Passwortspeicherung im LSASS-Speicher auf Windows 8.1/Server 2012 R2 und neuer

# Tier-0-Admin-Konten in Protected Users aufnehmen
Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-sweber", "adm-t0-mueller"

# Mitgliedschaft pruefen
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName

Zusätzlich gilt: Ein Cached-Logon-Limit von 4 Stunden bedeutet, dass Protected-Users-Konten sich nach dieser Zeit zwingend neu am Netzwerk authentifizieren müssen – offline arbeiten (z. B. Laptop ohne VPN) funktioniert für diese Konten praktisch nicht. Das ist für Tier-0/1-Admin-Konten meist kein Problem, weil diese ohnehin nur an fest verkabelter Infrastruktur genutzt werden sollten.

LAPS: Lokale Admin-Passwörter automatisch verwalten

Ein oft übersehenes Problem: Wenn alle Workstations denselben lokalen Administrator-Account mit demselben Passwort haben (weil das über das Standard-Image so verteilt wurde), reicht die Kompromittierung eines einzigen Geräts, um sich per Pass-the-Hash lateral auf alle anderen Geräte mit demselben lokalen Admin-Passwort zu bewegen. Das ist der klassische “Lateral Movement über lokale Admin-Konten”-Pfad.

Windows LAPS (seit April 2023 nativ in Windows 10/11 und Server 2019+ integriert, Nachfolger des separaten Legacy-LAPS-Tools) löst das, indem es für jeden Computer ein einzigartiges, zufälliges lokales Admin-Passwort generiert, es verschlüsselt in AD (oder Entra ID) hinterlegt und automatisch rotiert.

Einrichtung in AD

# AD-Schema fuer Windows LAPS erweitern (einmalig, Schema Admin Rechte noetig)
Update-LapsADSchema

# Berechtigungen setzen: welche OU darf Passwoerter fuer welche Computer lesen
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=firma,DC=ch" -AllowedPrincipals "Helpdesk-Tier2-Admins"
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=firma,DC=ch" -AllowedPrincipals "Helpdesk-Tier2-Admins"

# Passwort fuer einen Computer manuell auslesen (fuer berechtigte Helpdesk-Accounts)
Get-LapsADPassword -Identity "PC-VERTRIEB-042" -AsPlainText

# GPO-Einstellungen (Computer Configuration > Administrative Templates > System > LAPS)
Configure password backup directory: "Active Directory"
Password complexity: "Large letters + small letters + numbers + special characters"
Password length: 20
Password age (days): 30
Post-authentication actions: "Reset password and log off (3)"

Für Domain Controller selbst gilt eine Sonderregel: Der lokale Administrator eines DC entspricht praktisch dem Domain-Admin-Zugriff, daher solltest du DSRM-Passwörter (Directory Services Restore Mode) separat und regelmässig verwalten – LAPS deckt DCs standardmässig nicht ab, weil DCs keine “lokalen” Administratorkonten im klassischen Sinn mehr haben, sobald sie zum DC hochgestuft wurden.

Attack-Path-Analyse mit BloodHound

Alle bisherigen Massnahmen sind Theorie, bis du weisst, wo deine echte Domäne von der Theorie abweicht. BloodHound (heute meist in der Community-Edition, BHCE) ist das Standard-Werkzeug, um Angriffspfade in AD sichtbar zu machen – und zwar aus der Perspektive eines Angreifers, nicht aus der Perspektive der offiziellen Gruppenmitgliedschaften.

Warum “wer ist Domain Admin” nicht die richtige Frage ist

Die eigentliche Gefahr sind selten die offensichtlichen Domain-Admin-Konten – die werden überwacht. Gefährlich sind die indirekten Pfade: Ein Helpdesk-Mitarbeiter hat “Reset Password”-Recht auf eine OU, in der zufällig ein Service-Account mit Sitz in einer privilegierten Gruppe liegt. Oder: Ein Fileserver-Admin (Tier 1) hat versehentlich “GenericAll” auf ein GPO, das auf die Domain-Controller-OU wirkt. BloodHound sammelt genau diese Beziehungen (Gruppenmitgliedschaften, ACLs, Sitzungsdaten, Kerberos-Delegationen) und stellt sie als Graph dar, in dem du per Klick nach dem kürzesten Pfad zu “Domain Admins” fragen kannst.

Ablauf einer Attack-Path-Analyse

1. Sammeln (Collection) – mit SharpHound (dem Collector) Daten aus AD sammeln, entweder von einer Domain-beigetretenen Maschine mit Standard-User-Rechten oder remote
2. Importieren – die JSON-Dateien in die BloodHound-CE-Instanz laden (läuft lokal via Docker, mit Neo4j-Graphdatenbank im Hintergrund)
3. Analysieren – vordefinierte Cypher-Queries nutzen (“Find Shortest Paths to Domain Admins”, “Find Kerberoastable Users”, “Users with DCSync Rights”)
4. Priorisieren und beheben – die gefundenen Pfade nach Aufwand/Risiko sortiert schliessen
5. Wiederholen – nach jeder grösseren AD-Änderung (neue Gruppen, neue Delegationen) erneut sammeln

# SharpHound Collection von einer Domain-Mitglieds-Workstation aus (Standard-User reicht)
.\SharpHound.exe -c All -d firma.ch --outputdirectory C:\BloodHound\Collection

# Nur Kerberoasting-relevante Daten sammeln (schneller, unauffaelliger fuer Pentest)
.\SharpHound.exe -c Session,LoggedOn -d firma.ch

# BloodHound CE lokal per Docker Compose starten (fuer den Blue-Team-Einsatz im eigenen Netz)
curl -L https://ghst.ly/getbhce -o docker-compose.yml
docker compose up -d
# Web-UI danach unter http://localhost:8080 erreichbar

Typische Cypher-Query, um alle Accounts mit DCSync-Rechten zu finden, die nicht in einer offiziellen Admin-Gruppe stecken sollten:

MATCH (u:User)-[:MemberOf|GetChanges|GetChangesAll*1..]->(d:Domain)
WHERE d.name = "FIRMA.CH"
RETURN u.name

Priorisierung der gefundenen Pfade

Entscheidungshilfe: Wo fange ich an?

Bei begrenztem Budget und begrenzter Zeit (der KMU-Alltag) lohnt sich diese Reihenfolge, sortiert nach Aufwand/Wirkung-Verhältnis:

1. Windows LAPS ausrollen (1-2 Tage)
        │
2. Service-Accounts inventarisieren, Kerberoasting-Risiko pruefen (Get-ADUser SPN-Filter)
        │
3. Kritische Service-Accounts auf gMSA migrieren, Rest auf 25+ Zeichen Passwoerter
        │
4. Getrennte Admin-Konten pro Tier einfuehren (adm-t0-*, adm-t1-*, adm-t2-*)
        │
5. Protected Users fuer Tier-0-Konten (nach Delegationstest!)
        │
6. BloodHound-Analyse durchfuehren, Top-5-Pfade schliessen
        │
7. PAW/Jump-Server fuer Tier-0-Zugriffe einfuehren
        │
8. Authentication Policy Silos fuer harte technische Durchsetzung
        │
9. KRBTGT-Rotation als wiederkehrenden Prozess etablieren (alle 6-12 Monate)

Diese Reihenfolge ist bewusst so gewählt, dass die ersten Schritte kaum Betriebsrisiko haben (LAPS, gMSA-Migration einzelner Dienste), während die späteren Schritte (Silos, PAW) mehr Testaufwand brauchen, aber auch strukturell am wirksamsten sind.

Fallstricke aus der Praxis

• Delegation vergessen zu testen – Protected Users oder Silos ohne vorherigen Delegationstest legen produktive RDS-/SQL-Umgebungen lahm.
• KRBTGT nur einmal rotiert – nach einem Incident reicht eine einzelne Rotation nicht; du brauchst zwei Rotationen im Abstand der Replikationskonvergenzzeit, sonst bleiben alte Golden Tickets zeitweise gültig.
• LAPS-Rollout ohne Backup-Plan – wenn AD selbst ausfällt (z. B. Ransomware auf den DCs), kommst du ohne Zugriff auf die LAPS-Passwörter nicht mehr auf die Workstations. Halte für den Notfall mindestens eine Offline-Kopie kritischer Passwörter in einem physisch getrennten Tresor.
• Tier-Modell nur auf dem Papier – eine Namenskonvention (adm-t0-*) ohne technische Durchsetzung (Silos, GPO-Logon-Restriktionen) hält niemanden davon ab, aus Bequemlichkeit doch den Tier-0-Account auf einer Workstation zu nutzen.
• Ein Admin-Konto für IT und Fachanwendung – gerade in kleinen Teams wird der gleiche Tier-1-Account auch für ERP- oder Datenbank-Administration verwendet; das sprengt die Tier-Grenzen faktisch wieder auf.

Weiterlernen

• Securing Privileged Access – Enterprise Access Model (Microsoft Learn)
• Windows LAPS Übersicht (Microsoft Learn, Deutsch)
• PAM Tier Model for Partitioning Administrative Privileges (Microsoft Learn)
• BloodHound Community Edition Dokumentation (SpecterOps)
• Golden Ticket Attack erklärt (CrowdStrike)
• Protected Users Security Group (Microsoft Learn)