Admin-Tiering und Protected Users für Active Directory

Die meisten Kompromittierungen von Active Directory folgen demselben Muster. Ein Angreifer landet auf einem Arbeitsplatz, findet im Speicher privilegierte Anmeldedaten, weil sich dort ein Administrator angemeldet hat, und verwendet sie weiter, bis er einen Domänencontroller erreicht. Credential Guard, EDR und LAPS erschweren das, doch die eigentliche Ursache ist architektonisch: Hochprivilegierte Anmeldedaten wurden auf einem Computer offengelegt, den ein gewöhnlicher Benutzer kompromittieren kann.

Das Tier-Modell beseitigt diese Offenlegung. Seine Regel ist kurz: Ein Konto darf sich nur an Systemen seines eigenen Tiers anmelden. Ein Domain Admin tippt nie ein Kennwort auf einem Arbeitsplatz ein, ein Server-Admin meldet sich nie an einem Benutzer-Laptop an, und Helpdesk-Konten berühren nie Server. Dieser Leitfaden übersetzt diese Regel in Gruppenrichtlinien, Gruppenmitgliedschaften und Prüfungen.

Die drei Tiers

Am schwierigsten ist es, bei Tier 0 ehrlich zu sein. Alles, was ein Tier-0-Asset kontrollieren kann, ist Tier 0: der Hypervisor-Cluster mit den virtuellen DCs, der Backup-Server, der NTDS.dit wiederherstellen kann, das Softwareverteilungstool mit einem Agenten auf den DCs, der Monitoring-Agent, der auf DCs als SYSTEM läuft. Wenn Ihr SCCM-Standortserver Software auf Domänencontroller verteilt, ist SCCM Tier 0.

Microsoft beschreibt inzwischen ein umfassenderes Enterprise Access Model mit Steuerungs-, Verwaltungs-, Daten-/Workload-, Benutzer- und App-Zugriffsebene, das dieselbe Idee auf Entra ID und Cloud-Workloads ausdehnt. Für ein lokales AD sind die drei Tiers der Weg, es umzusetzen.

Schritt 1: Konten trennen

Jeder Administrator erhält ein Konto pro Tier, in dem er arbeitet, zusätzlich zu seinem normalen Benutzerkonto:

• jdoe - E-Mail, Surfen, Office. Nirgends Administratorrechte.
• adm-t2-jdoe - lokaler Admin auf Arbeitsplätzen (idealerweise über LAPS statt über Gruppenmitgliedschaft).
• adm-t1-jdoe - Admin auf Mitgliedsservern.
• adm-t0-jdoe - Domain Admins oder delegierte Tier-0-Rechte. Nur wenige Personen.

Legen Sie eine OU-Struktur an, die die Tiers abbildet (Admin\Tier0, Admin\Tier1, Admin\Tier2, jeweils mit Accounts, Groups, Devices), damit GPOs und Delegierungen jedes Tier sauber adressieren können.

Verkleinern Sie dann die privilegierten Gruppen. Prüfen Sie, wer tatsächlich darin ist, einschließlich verschachtelter Mitgliedschaften:

foreach ($g in "Domain Admins","Enterprise Admins","Schema Admins","Administrators",
               "Account Operators","Server Operators","Backup Operators","Print Operators") {
  Get-ADGroupMember -Identity $g -Recursive |
    Select-Object @{n="Group";e={$g}}, SamAccountName, objectClass
}

Account Operators, Server Operators, Backup Operators und Print Operators bieten alle Wege zur Kompromittierung eines Domänencontrollers. Sie sollten leer sein. Schema Admins und Enterprise Admins sollten außer bei geplanten Änderungen leer sein.

Schritt 2: Anmeldeeinschränkungen per GPO erzwingen

Das Tier-Modell wirkt nur, wenn es erzwungen und nicht bloß dokumentiert wird. Verwenden Sie User Rights Assignment unter Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies, angewendet pro Tier-OU:

Verweigerungsrechte haben Vorrang vor Zulassungsrechten; die Einschränkung greift also auch dann, wenn jemand adm-t0-jdoe zur lokalen Administratorengruppe eines Arbeitsplatzes hinzufügt. Nehmen Sie die integrierten Gruppen Domain Admins und Enterprise Admins in die Tier-0-Verweigerungslisten auf Arbeitsplätzen und Mitgliedsservern auf.

Ein Hinweis zur Netzwerkanmeldung: „Deny access to this computer from the network“ für Tier-0-Konten auf Servern blockiert SMB, WinRM und ähnliche Remoteverwaltung durch diese Konten, und genau das ist beabsichtigt. Testen Sie zuerst mit einer Pilot-OU, denn manche älteren Verwaltungstools setzen voraus, dass sich ein Domain Admin überall anmeldet.

Schritt 3: Tier-0-Personen in Protected Users aufnehmen

Protected Users ist eine integrierte globale Sicherheitsgruppe (Windows Server 2012 R2 und neuer), die auf ihre Mitglieder nicht konfigurierbare Schutzmaßnahmen anwendet. Auf Geräten mit Windows 10 / Windows 11 oder Windows Server 2012 R2 und neuer, und für die Schutzmaßnahmen auf den Domänencontrollern mit Domänenfunktionsebene Windows Server 2012 R2 oder höher, gilt:

• NTLM-Authentifizierung wird abgelehnt; es gibt also keinen NTLM-Hash, der gestohlen oder weitergeleitet werden könnte.
• Kerberos verwendet für die Vorauthentifizierung weder DES noch RC4.
• Das Konto kann nicht delegiert werden (weder eingeschränkt noch uneingeschränkt).
• Die TGT-Lebensdauer ist auf vier statt zehn Stunden begrenzt.
• Anmeldedaten werden nicht zwischengespeichert: kein Verifier für zwischengespeicherte Anmeldungen, kein CredSSP- oder WDigest-Klartext, keine langfristigen Schlüssel im Speicher.

Fügen Sie jedes Tier-0- und Tier-1-Admin-Konto von Personen hinzu. Fügen Sie keine Dienstkonten, Computerkonten oder Ihr Notfallkonto hinzu (es muss auch funktionieren, wenn Kerberos es nicht tut). Testen Sie vorher: Alles, was diese Konten per NTLM authentifiziert, etwa eine Verwaltungs-Appliance, die sich per IP-Adresse verbindet, funktioniert dann nicht mehr, was meist schon für sich ein Befund ist.

Für Konten, die nicht in Protected Users aufgenommen werden können, setzen Sie am Kontoobjekt mindestens Account is sensitive and cannot be delegated.

Add-ADGroupMember -Identity "Protected Users" -Members adm-t0-jdoe, adm-t1-jdoe
Get-ADUser -Filter {AdminCount -eq 1} -Properties AccountNotDelegated |
  Select-Object SamAccountName, AccountNotDelegated

Schritt 4: Vom richtigen Ort aus administrieren

Anmeldeeinschränkungen legen fest, wohin ein Admin-Konto nicht darf; es braucht aber auch einen sicheren Ort, von dem aus es arbeitet. Eine Privileged Access Workstation (PAW) ist ein gehärtetes Gerät ausschließlich für die Administration: keine E-Mail, kein Surfen, strikte Anwendungssteuerung, Credential Guard aktiv und aus dem eigenen Tier verwaltet. Für Tier 0 ist das nicht verhandelbar. Für Tier 1 sind gehärtete Jump-Server ein verbreiteter Kompromiss.

Wenn Sie von einem weniger vertrauenswürdigen Gerät per RDP arbeiten müssen, verwenden Sie Remote Credential Guard (mstsc /remoteGuard) oder den Restricted Admin Mode (mstsc /restrictedAdmin), damit keine wiederverwendbaren Anmeldedaten an den Remotehost gesendet werden. Remote Credential Guard ist in der Regel vorzuziehen, weil die Kerberos-Anfragen auf dem Client bleiben und Sie trotzdem unter Ihrer eigenen Identität auf Netzwerkressourcen zugreifen können.

Schritt 5: Authentifizierungsrichtlinien und -silos (optional)

Für eine stärkere Durchsetzung als über Benutzerrechte schränken die Authentifizierungsrichtlinien und -silos von Active Directory (Domänenfunktionsebene 2012 R2+) ein, wo Tier-0-Konten Kerberos-Tickets erhalten können; geprüft wird das vom Domänencontroller selbst. So erhalten beispielsweise Mitglieder eines Silos „Tier0“ nur dann ein TGT, wenn sie sich von Computern in diesem Silo anmelden. Das erfordert Kerberos Armoring (FAST) und sorgfältige Tests, schließt aber Lücken, die GPO-basierte Verweigerungsrechte nicht schließen können, etwa ein Tier-0-Konto, das von einem nicht verwalteten Gerät aus genutzt wird.

Überprüfen

1. Wo haben sich Tier-0-Konten angemeldet? Auf Domänencontrollern zeigen die Ereignisse 4768 (TGT angefordert) und 4769 (Dienstticket angefordert) die Clientadresse; auf Mitgliedssystemen zeigt 4624 mit Anmeldetyp 2 (interaktiv), 10 (Remote interaktiv) oder 3 (Netzwerk), wo Konten verwendet wurden. Erstellen Sie einen Bericht über Tier-0-Konten, die sich von etwas anderem als einem DC oder einer PAW aus authentifizieren; er sollte leer sein.
2. Wirkt Protected Users? Auf einem DC protokolliert Applications and Services Logs > Microsoft > Windows > Authentication Fehler für Mitglieder von Protected Users (die Protokolle ProtectedUserFailures-DomainController und ProtectedUserSuccesses-DomainController auf DCs sowie ProtectedUser-Client auf Clients sind standardmäßig deaktiviert; aktivieren Sie sie zuerst). NTLM-Versuche von Mitgliedern erscheinen als Fehler.
3. Gibt es versteckte Pfade? Werkzeuge wie BloodHound (Community Edition) oder PingCastle bilden Angriffspfade über ACLs, verschachtelte Gruppen und Delegierungen ab. Führen Sie sie regelmäßig aus; Tiering auf dem Papier wird oft durch eine alte ACL auf einer OU oder ein von einer Tier-1-Gruppe bearbeitbares GPO unterlaufen.

Checkliste

• Liste der Tier-0-Assets schriftlich festgehalten, einschließlich Hypervisoren, Backup, PKI und Synchronisierungsservern
• Separate Admin-Konten pro Tier, keine Administratorrechte für Alltagskonten
• Operator-Gruppen leer, Schema/Enterprise Admins standardmäßig leer
• GPOs mit Anmeldeverweigerung auf Arbeitsplätzen, Mitgliedsservern und DCs
• Privilegierte Konten von Personen in Protected Users; übrige als „sensitive and cannot be delegated“ markiert
• PAWs für Tier 0; Remote Credential Guard für RDP
• Monatlicher Bericht über Tier-0-Anmeldungen außerhalb von Tier 0
• Regelmäßige Prüfung der Angriffspfade (BloodHound CE / PingCastle)

Tiering ist mehr organisatorische als technische Arbeit, und deshalb wird es gern übersprungen. Kombinieren Sie es mit eindeutigen lokalen Admin-Kennwörtern und Credential Guard, und ein einzelner per Phishing übernommener Laptop ist kein Weg mehr zu Ihren Domänencontrollern.