Tier 0 und privilegierter Zugriff: Domain Admins absichern

Die meisten Kompromittierungen von Active Directory beginnen nicht mit einem Zero-Day gegen einen Domänencontroller, sondern mit einem überprivilegierten Konto, das sich an einem unzureichend geschützten Rechner anmeldet. Ein IT-Admin verbindet sich per RDP mit seinen Domain-Admin-Anmeldeinformationen auf einen Helpdesk-Arbeitsplatz, um ein Druckerproblem zu lösen, ein Credential-Theft-Tool greift das Token ab, und der Angreifer marschiert direkt zu NTDS.dit. Das Tier-Modell soll diesen Weg konstruktionsbedingt unmöglich machen – nicht per Richtlinienmemo.

Dieser Leitfaden behandelt das Enterprise Access Model, die physische und logische Trennung von Tier 0 sowie die konkreten GPO-, Gruppen- und PowerShell-Arbeiten, mit denen Sie diese Trennung durchsetzen.

Das Tier-Modell: Tier 0, 1 und 2

Das klassische Drei-Ebenen-Modell von Microsoft (inzwischen Teil des umfassenderen Enterprise Access Model) trennt die Administration nach Schadensradius:

Das Modell funktioniert durch eine gerichtete Regel: Ein Tier-N-Admin-Konto darf sich nur an Tier-N-Systemen anmelden. Eine Tier-0-Anmeldeinformation darf niemals einen Tier-1- oder Tier-2-Rechner berühren, und ein Tier-1-Admin darf seine Anmeldeinformationen niemals auf einem Tier-2-Arbeitsplatz verwenden. Wird diese Regel ein einziges Mal verletzt – etwa durch eine Anmeldung mit einem Domain-Admin-Konto an einem Helpdesk-PC –, ist die Tier-Grenze verschwunden, denn Credential Theft auf diesem Rechner liefert nun Tier-0-Zugriff.

Was zu Tier 0 gehört

Seien Sie hier streng; ein schleichendes Aufblähen von Tier 0 ist der häufigste Fehler. Zu Tier 0 gehören:

• Domänencontroller (alle, für administrative Zwecke auch RODCs)
• Stamm- und ausstellende Zertifizierungsstellen der AD Certificate Services (eine kompromittierte CA kann Authentifizierungszertifikate für jeden Benutzer fälschen)
• AD-FS-Server und ihre Tokensignaturzertifikate
• Microsoft-Entra-Connect-/Entra-Connect-Sync-Server
• Backup- und Imaging-Systeme, die AD-Daten wiederherstellen oder lesen können
• Die Privileged Access Workstations selbst sowie alle Jump-/Bastion-Hosts, über die Tier 0 erreicht wird
• Die Sicherheitsgruppen: Domain Admins, Enterprise Admins, Schema Admins, Administrators (auf DCs), Account Operators, Backup Operators, Print Operators, Server Operators

Wenn Sie unsicher sind, ob etwas zu Tier 0 gehört, fragen Sie: „Kann der Angreifer die Domäne kompromittieren, wenn dieses System kompromittiert ist?“ Wenn ja, ist es Tier 0 – Punkt, egal wie unbequem das im Betrieb ist.

Getrennte Admin-Konten

Jeder menschliche Administrator, der Tier 0 berührt, benötigt ein dediziertes Konto, das für nichts anderes verwendet wird – keine E-Mail, kein Surfen, kein Teams. Eine praxistaugliche Namenskonvention:

florian.amette          -> standard user account (Tier 2, email, day-to-day)
adm-t0-famette          -> Tier 0 admin account (DCs, PKI, Entra Connect)
adm-t1-famette          -> Tier 1 admin account (member servers, apps)

Verwenden Sie kein einzelnes „Admin“-Konto über mehrere Tiers hinweg, und geben Sie dem Standardbenutzerkonto keine implizite Mitgliedschaft in privilegierten Gruppen. Setzen Sie das mit AdminSDHolder-geschützten Gruppen und regelmäßigen Mitgliedschaftsaudits durch, nicht mit Vertrauen.

Anmeldeverweigerungs-GPOs zur Durchsetzung der Grenze

Gruppenmitgliedschaft allein hindert einen Admin nicht daran, sich im falschen Tier anzumelden – Sie brauchen explizite Verweigerungen von Anmelderechten. Erstellen Sie dedizierte GPOs und verknüpfen Sie sie je Tier:

GPO: „Tier 0 – Deny Logon From Lower Tiers“ (verknüpft mit der OU Domain Controllers und allen Tier-0-Server-OUs)

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment

Spiegeln Sie das mit einer GPO „Tier 1 – Deny Logon From Tier 0 and Tier 2“ auf den Mitgliedsserver-OUs und einer GPO „Tier 2 – Deny Logon From Tier 0 and Tier 1“ auf den Arbeitsplatz-OUs. Genau das verhindert, dass eine per Phishing auf einem Arbeitsplatz erbeutete Domain-Admin-Anmeldeinformation nutzbar ist: Selbst mit gültigen Anmeldeinformationen blockiert das Verweigerungsrecht die Anmeldung.

Die Gruppe Protected Users

Die Aufnahme von Tier-0-Konten in Protected Users (verfügbar seit Windows Server 2012 R2, durchgesetzt von DCs und Clients ab 2012 R2) härtet die Anmeldeinformation selbst:

• Blockiert die NTLM-Authentifizierung für das Konto vollständig
• Blockiert DES und RC4 bei der Kerberos-Vorauthentifizierung und erzwingt AES
• Deaktiviert das Zwischenspeichern von Anmeldeinformationen (keine zwischengespeicherte Anmeldung, kein CredSSP, kein WDigest)
• Verhindert die Erneuerung von Kerberos-Tickets über 4 Stunden hinaus und erzwingt eine erneute Authentifizierung

Add-ADGroupMember -Identity "Protected Users" -Members "adm-t0-famette"

Testen Sie zuerst mit einer Pilotgruppe – siehe „Was dabei bricht“ weiter unten. Kombinieren Sie das mit der Verschlüsselungshärtung aus Kerberos-Härtung, um die volle Wirkung zu erzielen.

Privileged Access Workstations (PAWs)

Eine Anmeldeverweigerungs-GPO verhindert die Anmeldung im falschen Tier, aber der Admin braucht trotzdem irgendeinen Ort, von dem aus er Tier 0 verwaltet. Das ist die PAW: ein gehärtetes, zweckgebundenes Gerät, das:

• keinen Browser, keinen E-Mail-Client und keine Office-Suite ausführt (oder nur einen stark eingeschränkten Browser, der auf das interne Admin-Portal begrenzt ist)
• in eine dedizierte Tier-0-OU mit eigenen restriktiven GPOs eingebunden ist
• dem angemeldeten Benutzer keine lokalen Administratorrechte über das Nötige hinaus gewährt
• das einzige Gerät ist, an dem sich Tier-0-Anmeldeinformationen anmelden dürfen (durchgesetzt durch die obigen Anmeldeverweigerungs-GPOs in umgekehrter Richtung – Tier-0-Konten werden überall außer in der PAW-OU verweigert)
• BitLocker, Credential Guard und aktuelle Patches als Grundlage nutzt

Minimal tragfähige PAW: eine abgesicherte VM oder ein Cloud PC, der ausschließlich für Tier-0-Aufgaben reserviert ist und per RDP von einem Standardarbeitsplatz aus erreicht wird – ohne sich jemals auf dem Arbeitsplatz selbst mit Tier-0-Anmeldeinformationen anzumelden.

Authentifizierungsrichtlinien und -silos

Domänen ab Windows Server 2012 R2 unterstützen Authentication Policies und Authentication Policy Silos, die Tier-Grenzen auf Ebene des Kerberos-KDC durchsetzen, statt sich allein auf GPO-Anmelderechte zu verlassen – eine Defense-in-Depth-Schicht, die auch dann greift, wenn eine GPO nicht angewendet wird.

# Silo erstellen, das Tier-0-Admins auf PAW- und DC-Zugriff beschränkt
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
    -UserAuthenticationPolicy "Tier0-UserAuthPolicy" `
    -ComputerAuthenticationPolicy "Tier0-ComputerAuthPolicy" `
    -Enforce

# Mitgliedschaft ist zweiseitig: Konto im Silo zulassen, dann dem Konto das Silo zuweisen
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "adm-t0-famette"
Set-ADAccountAuthenticationPolicySilo -Identity "adm-t0-famette" -AuthenticationPolicySilo "Tier0-Silo"

Authentifizierungsrichtlinien können außerdem die Lebensdauer des Kerberos-TGT für Silomitglieder begrenzen und so das Zeitfenster eines Angreifers bei einem gestohlenen Ticket verkleinern.

Domain Admins und Enterprise Admins bereinigen

Prüfen Sie die Mitgliedschaften regelmäßig – in diesen Gruppen sammeln sich über Jahre veraltete Einträge an.

# Aktuelle Domain Admins und Enterprise Admins auflisten
Get-ADGroupMember -Identity "Domain Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

Get-ADGroupMember -Identity "Enterprise Admins" -Recursive |
    Select-Object Name, SamAccountName, objectClass

# Konten finden, die sich seit 90+ Tagen nicht angemeldet haben, aber weiterhin privilegiert sind
$cutoff = (Get-Date).AddDays(-90)
Get-ADGroupMember -Identity "Domain Admins" |
    Get-ADUser -Properties LastLogonDate |
    Where-Object { $_.LastLogonDate -lt $cutoff -or -not $_.LastLogonDate }

Zielzustand: Enterprise Admins sollte leer sein, außer während geplanter Änderungen auf Gesamtstrukturebene (Schemaerweiterungen, Hinzufügen neuer Domänen), und danach wieder geleert werden. Domain Admins sollte nur die kleine Menge namentlich zugeordneter Tier-0-Administratorkonten enthalten – keine Dienstkonten, keine „Nur für den Fall“-Konten, keine Herstellerkonten.

# Prüfen, ob eine bestimmte Benutzerrechtezuweisung (z. B. lokale Anmeldung verweigern) per GPO angewendet wurde
Get-ADGroup "Tier 1 Admins" | Select-Object -ExpandProperty SID
# Effektive Benutzerrechte auf dem Zielhost gegenprüfen (inklusive Domänen-GPOs):
secedit /export /cfg "$env:TEMP\rights.inf" /areas USER_RIGHTS
Select-String -Path "$env:TEMP\rights.inf" -Pattern "SeDenyInteractiveLogonRight"

Was dabei bricht

• Geplante Aufgaben und Dienste, die unter Domain-Admin-Konten laufen, schlagen auf Mitgliedsservern oder Arbeitsplätzen sofort fehl, sobald die Rechte „Deny log on as a batch job/service“ greifen. Inventarisieren Sie vor dem Rollout jede geplante Aufgabe und jeden Dienst mit Get-ScheduledTask / Get-CimInstance Win32_Service, gefiltert auf privilegierte Kontonamen, und migrieren Sie sie anschließend auf Group Managed Service Accounts (gMSAs) im Tier-1-Umfang.
• Delegierte Helpdesk-Abläufe, die ein gemeinsames „Admin“-Konto sowohl für Kennwortrücksetzungen als auch für Serverfehlerbehebung nutzen, funktionieren über Tier-Grenzen hinweg nicht mehr – Sie müssen Kennwortrücksetzungsrechte über OU-bezogene Delegierung vergeben statt über tierübergreifende Konten.
• Die Mitgliedschaft in Protected Users bricht NTLM-abhängige Legacy-Anwendungen, die zwischengespeicherte Anmeldung auf Nicht-DC-Rechnern und die Erneuerung von Kerberos-Tickets über 4 Stunden hinaus – pilotieren Sie vor einer breiten Einführung.
• Tier-0-Zugriff ausschließlich über PAWs verlangsamt die Notfallreaktion, sofern Sie nicht mindestens einen Break-Glass-Pfad (ein dokumentiertes, überwachtes, physisch gesichertes Verfahren) für die DC-Wiederherstellung bereitstellen, falls die PAW selbst nicht verfügbar ist.

Weiterführende Lektüre: Kerberos-Härtung für die Authentifizierungsschicht unter diesen Konten und Delegierung für die Risiken eingeschränkter Delegierung, die Tier-Grenzen umgehen können. Siehe auch die Glossareinträge zu Protected Users und DCSync.