Active Directory Tiered Administration: Privilegien richtig strukturieren

In den meisten Active-Directory-Umgebungen gibt es zwei Klassen von Accounts: normale User und Domain Admins. Das ist das Problem. Ein Angreifer der einen Domain-Admin-Account kompromittiert - durch Phishing, Credential-Dumping oder Pass-the-Hash - kontrolliert die gesamte Infrastruktur. Das Tiered Administration Model löst dieses Problem durch strukturierte Privilegientrennung.

Das Problem: Flaches Privilegienmodell

In einer typischen AD-Umgebung ohne Tiering haben Domain Admins Zugriff auf alles: jeden Server (DC, Exchange, Datenbanken, Entwicklungsumgebungen), lokale Adminrechte auf allen Workstations und alle Dateishares. Das macht sie zum attraktivsten Angriffsziel im gesamten Netzwerk.

Ein Angreifer braucht für die vollständige Kompromittierung nur wenige Schritte: Eine Phishing-Mail an einen Domain Admin (der in vielen Umgebungen auch einen normalen Account für E-Mail und Office nutzt), Malware auf der Workstation, Credential Harvesting via Mimikatz (sekurlsa::logonpasswords), Pass-the-Hash zum Domain Controller, DCSync für alle Credentials aus dem AD, und schließlich ein Golden Ticket für permanenten Zugriff. In vielen Umgebungen ist dieser gesamte Ablauf in unter zwei Stunden realisierbar.

Das Tiered Administration Model (Microsoft)

Das von Microsoft entwickelte Modell trennt die Administrationsbereiche in drei strikt isolierte Ebenen:

Tier 0: Identity Control Plane

Hier befinden sich die kritischsten Systeme: Domain Controller, AD Connect, ADFS, PKI und MIM. Tier0-Admins dürfen ausschließlich von einer dedizierten PAW (Privileged Access Workstation) aus auf diese Systeme zugreifen.

Tier 1: Server Administration

Member Server, Exchange, SQL-Server und File Server. Tier1-Admins arbeiten von einer Tier1-PAW oder einem dedizierten Jump Server aus.

Tier 2: Workstation Administration

Client-PCs, Laptops und VDI. Tier2-Admins (typischerweise der Helpdesk) administrieren diese Systeme von einem Tier2-Admin-PC aus.

Die Kernregel lautet: Credentials dürfen niemals nach unten fließen. Ein Tier0-Admin darf nicht mit seinem Tier0-Account auf Tier1-Systeme zugreifen. Ein Tier1-Admin darf nicht mit seinem Tier1-Account auf Tier2-Systeme. Tier0-Accounts dürfen niemals auf normalen PCs verwendet werden.

Diese Trennung hat eine entscheidende Schutzwirkung: Wenn ein Tier2-PC kompromittiert wird, sind nur Tier2-Credentials gefährdet. Tier1-Credentials existieren nur auf Tier1-PAWs. Tier0-Credentials befinden sich ausschließlich auf luftdicht isolierten Tier0-PAWs. Selbst wenn ein Angreifer vollständige Kontrolle über Tier2 erlangt, gibt es keinen Pfad zu Tier0.

Schritt 1: Admin-Accounts strukturieren

Jeder Administrator benötigt mehrere getrennte Accounts: einen normalen User-Account für E-Mail und Office, einen Tier2-Admin-Account für Workstation-Administration, und je nach Aufgabenbereich einen Tier1- und/oder Tier0-Admin-Account.

Die empfohlene OU-Struktur legt diese Accounts separat ab:

Domain\
  Admin Accounts\
    Tier0\
    Tier1\
    Tier2\

# Tier0-Admin-Account erstellen:
New-ADUser -Name "adm-t0-mmuster" `
  -GivenName "Max" -Surname "Muster (T0)" `
  -SamAccountName "adm-t0-mmuster" `
  -UserPrincipalName "adm-t0-mmuster@firma.de" `
  -Path "OU=Tier0,OU=Admin Accounts,DC=firma,DC=de" `
  -AccountPassword (ConvertTo-SecureString "Zufälliges-Passwort-32-Zeichen!" -AsPlainText -Force) `
  -Enabled $true `
  -PasswordNeverExpires $false `
  -CannotChangePassword $false

# Tier0-Account zu Domain Admins hinzufügen:
Add-ADGroupMember -Identity "Domain Admins" -Members "adm-t0-mmuster"

# WICHTIG: Den normalen User-Account aus "Domain Admins" entfernen!
Remove-ADGroupMember -Identity "Domain Admins" -Members "mmuster" -Confirm:$false

Schritt 2: Anmelde-Einschränkungen via GPO

Das Ziel ist, dass Tier0-Accounts sich ausschließlich an Tier0-PAWs anmelden dürfen. Dies wird über GPOs durchgesetzt.

GPO: “Tier0 Admin Login Restriction” - verknüpft mit den OUs für Domain Controller und Tier0-PAWs:

Unter Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment werden folgende Einstellungen gesetzt:

• “Allow log on locally”: nur Tier0-Admins-Gruppe (nicht Domain Users)
• “Deny log on locally” auf allen anderen Systemen: Tier0-Admins-Gruppe
• “Deny log on through Remote Desktop Services”: Tier0-Admins auf Tier1- und Tier2-Systemen

Zur Überprüfung der aktuellen Situation eignen sich folgende PowerShell-Abfragen:

# Wer ist wo angemeldet? (aktuell)
Get-ADComputer -Filter * -Properties LastLogonDate |
  ForEach-Object {
    Invoke-Command -ComputerName $_.Name -ScriptBlock {
      query user
    } -ErrorAction SilentlyContinue
  }

# Anmeldehistorie prüfen (Event ID 4624):
Get-WinEvent -LogName Security |
  Where-Object {$_.Id -eq 4624} |
  Select-Object TimeCreated, @{N="User";E={$_.Properties[5].Value}},
                @{N="Workstation";E={$_.Properties[11].Value}} |
  Where-Object {$_.User -like "adm-t0-*"} |  # Tier0-Accounts
  Group-Object Workstation |
  Select-Object Name, Count
  # → Sollte NUR Tier0-PAW-Namen zeigen!

Schritt 3: PAW (Privileged Access Workstation) einrichten

Eine PAW ist ein dedizierter Hardware-PC (oder eine dedizierte VM) der ausschließlich für Admin-Aufgaben verwendet wird. Auf einer PAW gibt es keine E-Mail, keinen Browser und kein Office.

Anforderungen an eine Tier0-PAW

• Eigenes physisches Gerät (keine VM auf gemeinsamer Infrastruktur)
• Physisch sicher aufbewahrt (kein Diebstahl möglich)
• Nur Tier0-Admins dürfen sich anmelden
• Kein Internet-Zugang außer für Windows- und AD-Updates
• Windows Hello for Business (FIDO2 für Login)
• BitLocker mit TPM-PIN
• Credential Guard aktiviert
• Device Guard / WDAC (Application Whitelisting)

PAW-GPO Härtung

Internet-Zugang einschränken (nur Update-Server erlaubt) via Windows Firewall Outbound-Regeln: erlaubt sind LDAP/LDAPS-Ports zu den AD-DCs, Windows Update-Server und bei Bedarf Monitoring/SIEM.

Software-Einschränkungen via Application Control (WDAC/AppLocker):

• Erlaubt: Windows-System-Binaries, AD-Admin-Tools
• Blockiert: Browser, Office, E-Mail, PowerShell für normale Nutzer

No-Browser-Policy via Group Policy → Software Restriction: chrome.exe und firefox.exe auf Disallowed setzen.

Schritt 4: Credential Guard

Credential Guard isoliert LSASS-Secrets in einem gehärteten Container (Virtual Secure Mode / Hyper-V basiert). Dies verhindert, dass Mimikatz mit sekurlsa::logonpasswords NTLM-Hashes auslesen kann, blockiert Pass-the-Hash für laterale Bewegung und erschwert Over-Pass-the-Hash-Angriffe erheblich.

Voraussetzungen: Windows 10/11 Enterprise oder Server 2016+, UEFI Secure Boot, Virtualization-based Security (VBS), TPM 2.0 (empfohlen).

Aktivierung via GPO (empfohlen):

Computer Configuration → Administrative Templates →
  System → Device Guard →
  "Turn On Virtualization Based Security": Enabled
  Platform Security Level: "Secure Boot and DMA Protection"
  Credential Guard Configuration: "Enabled with UEFI lock"

Der UEFI lock verhindert, dass Credential Guard per GPO deaktiviert werden kann - ein wichtiges Detail für die Sicherheit.

# Manuell für Test (OHNE UEFI lock):
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v RequirePlatformSecurityFeatures /t REG_DWORD /d 3
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 1

# Status prüfen:
Get-ComputerInfo | Select-Object DeviceGuardCredentialGuardRunning
# Oder via msinfo32 → "Device Guard Credential Guard Running" muss "Running" zeigen

Credential Guard schützt nicht gegen NTLM-Hashes auf älteren Systemen ohne VBS-Unterstützung, nicht gegen Kerberos-Ticket-Diebstahl (erschwert aber), und nicht auf Geräten ohne UEFI.

Schritt 5: Protected Users Security Group

Die Gruppe “Protected Users” erzwingt strenge Kerberos-Nutzung für alle ihre Mitglieder:

• Kein NTLM-Auth mehr (auch nicht für Legacy-Clients)
• Kerberos-Delegation blockiert (kein Unconstrained Delegation)
• Kerberos-Ticket-Lifetime: maximal 4 Stunden, nicht verlängerbar
• Kein RC4 Kerberos (nur AES256)
• Credentials werden nicht im Credential Manager gespeichert

Alle Tier0-Admin-Accounts (Domain Admins) sollten in diese Gruppe aufgenommen werden. Wichtige Ausnahme: Service-Accounts dürfen nicht hinzugefügt werden, da diese kein automatisches Ticket mehr erhalten und entsprechende Services damit nicht mehr funktionieren.

# Tier0-Admins zu Protected Users hinzufügen:
Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-mmuster"

# WARNUNG: Testen! Wenn alte Systeme NTLM brauchen → kein Auth möglich!
# Test in Pre-Prod bevor Rollout auf alle Admins

Zusammenfassung: Tiered Admin Rollout-Plan

Ein realistischer Implementierungsplan verteilt sich auf etwa 12 Wochen:

Woche 1-2: Analyse

• Aktuellen Stand prüfen: Wer ist in “Domain Admins”?
• Welche Accounts loggen sich wo ein? (Logon-Audit aktivieren)
• Gibt es bereits Ansätze einer Tier-Trennung?

Woche 3-4: OU-Struktur und Accounts

• OU-Struktur für Admin-Accounts anlegen
• Tier0/1/2-Admin-Accounts erstellen (pro Admin-Person)
• Domain Admin Group auf ausschließlich Tier0-Accounts reduzieren
• Normale User-Accounts aus Domain Admins entfernen

Woche 5-6: GPO-Restriktionen

• Logon-Restrictions via GPO einrichten
• Deny-Logon für Tier0-Accounts außerhalb des Tier0-Scope
• Test: Kann sich der Tier0-Admin noch am DC anmelden?

Woche 7-8: PAW-Setup

• Tier0-PAW beschaffen und konfigurieren
• Credential Guard auf allen Admin-Systemen aktivieren
• Protected Users: Tier0-Admins hinzufügen

Woche 9-12: Monitoring und Verfeinerung

• Alerting: Tier0-Account loggt sich auf Tier1/Tier2 ein?
• Alerting: Tier0-Account auf Domain Controller außer PAW?
• Quarterly Review: Tier0-Mitglieder prüfen

Langfristige Maßnahmen

• Just-in-Time-Access mit Microsoft Entra PIM
• Session Recording für Tier0-PAW-Sitzungen
• Regelmäßige Red-Team-Tests: “Kann ich noch lateral bewegen?”

---

Active Directory Sicherheitsreview nötig? AWARE7 führt AD-Sicherheitsassessments durch - von der BloodHound-Analyse der Angriffspfade bis zur Implementierung des Tiered Administration Models.

AD-Security-Assessment anfragen | Penetrationstest Active Directory