Tier-0-Assets identifizieren: vollständige AD-Inventur

Jede Tier-0-Maßnahme, die Sie später einführen – von Anmeldeverweigerungs-GPOs bis zu Authentifizierungssilos –, schützt nur die Liste der Assets, die Sie ihr übergeben. Die meisten Tiering-Projekte scheitern nicht an schwachen Maßnahmen, sondern an einer falschen Liste: der Backupserver, der NTDS.dit wiederherstellen kann, das vCenter, auf dem die DCs laufen, die Helpdesk-Gruppe, die über einen vergessenen ACE das Kennwort eines Domain Admins zurücksetzen kann. Angreifer interessiert nicht, welche Assets Sie als Tier 0 gekennzeichnet haben. Sie folgen Kontrollbeziehungen, bis eine davon die Domäne erreicht.

Dieser Leitfaden liefert eine wiederholbare Methode für diese Inventur: die anzuwendende Definition, die Kategorien, die die meisten Teams übersehen, die PowerShell-Befehle zur Aufzählung und die Art der Dokumentation, damit spätere Maßnahmen das Ergebnis nutzen können. Er geht tiefer als der Überblick in Tier 0 und privilegierter Zugriff, den Sie zum Tier-Modell selbst zuerst lesen sollten.

Die Definition: Kontrolle, nicht Wichtigkeit

Ein System ist Tier 0, wenn seine Kompromittierung einem Angreifer die Kontrolle über Active Directory verschafft. Diese Kontrolle kann direkt sein (Anmeldung an einem DC, Mitgliedschaft in Domain Admins) oder indirekt (Schreiben einer GPO, die mit der OU Domain Controllers verknüpft ist, Ausstellen eines Zertifikats, das sich als beliebiger Benutzer authentifiziert, Lesen der virtuellen Festplatte eines DC). Der Test ist transitiv: Wenn A B kontrolliert und B Tier 0 ist, dann ist A Tier 0.

Daraus folgen zwei Konsequenzen. Erstens ist „geschäftskritisch“ irrelevant: Ihr ERP-System ist wichtig, aber in der Regel Tier 1. Zweitens ist Tier 0 größer als die OU Domain Controllers. Ziel der Inventur ist es, alles darin zu finden und Tier 0 dann gezielt zu verkleinern, indem Sie nicht benötigte Kontrollpfade entfernen.

Messen: die Asset-Kategorien

Arbeiten Sie die folgenden Kategorien durch. Die meisten lassen sich direkt aus AD ermitteln.

Domänencontroller und ihre Plattform

Alle beschreibbaren DCs und RODCs sowie alles darunter: Hypervisor-Hosts, die Virtualisierungs-Management-Ebene (vCenter, SCVMM, Hyper-V-Clusteradministratoren), SAN- oder Speicher-Arrays mit DC-Festplatten, Out-of-Band-Management (iLO, iDRAC) auf physischen DCs und das DC-Backup-Repository.

# Alle DCs der Gesamtstruktur mit Betriebssystem und RODC-Kennzeichen
(Get-ADForest).Domains | ForEach-Object {
    Get-ADDomainController -Filter * -Server $_ |
        Select-Object Domain, HostName, OperatingSystem, IsReadOnly, Site
}

Identitätsinfrastruktur

• AD CS: jede Unternehmenszertifizierungsstelle sowie die Offline-Stamm-CA. Eine CA, die Clientauthentifizierungszertifikate ausstellt, kann eine Anmeldung für jedes beliebige Konto erzeugen.
• AD-FS-Server und alle, die deren Tokensignaturschlüssel lesen können.
• Microsoft Entra Connect / Cloud Sync-Server. Das Synchronisierungskonto besitzt Replikationsrechte (und die Kennworthashsynchronisierung liest jeden Hash).
• PAM- und Vault-Plattformen (CyberArk, Delinea und ähnliche), die Tier-0-Anmeldeinformationen speichern oder einspielen.

$config = (Get-ADRootDSE).configurationNamingContext

# In der Gesamtstruktur registrierte Unternehmens-CAs
Get-ADObject -SearchBase "CN=Enrollment Services,CN=Public Key Services,CN=Services,$config" `
    -Filter 'objectClass -eq "pKIEnrollmentService"' -Properties dNSHostName |
    Select-Object Name, dNSHostName

# Entra-Connect-Fußabdruck: Synchronisierungskonten und das Seamless-SSO-Computerobjekt
Get-ADUser -Filter 'SamAccountName -like "MSOL_*" -or SamAccountName -like "Sync_*"' -Properties Description |
    Select-Object SamAccountName, Description
Get-ADComputer -Filter 'Name -eq "AZUREADSSOACC"' -Properties PasswordLastSet

Die Description von MSOL_-Konten nennt normalerweise den Server, auf dem Entra Connect läuft. Dieser Server ist Tier 0.

Management-Ebenen, die Tier 0 erreichen

Alles, was Code auf einem Tier-0-Rechner ausführt, ist Tier 0: SCCM/MECM-Standortserver, deren Sammlungen DCs enthalten, Intune, wenn es PAWs verwaltet, EDR-Konsolen mit Remote-Shell oder Skriptausführung auf DCs, Patch-Werkzeuge, Monitoring-Agents, die als SYSTEM mit zentraler Skriptverteilung laufen, sowie die PAWs und Jump-Hosts zur Tier-0-Administration. Diese zu ermitteln ist überwiegend Interviewarbeit: Listen Sie jeden auf einem DC installierten Agent auf und fragen Sie, wer dessen Konsole kontrolliert.

# Dienste und ihre Ausführungskonten auf jedem DC, Ausgangspunkt für die Agent-Ermittlung
Get-ADDomainController -Filter * | ForEach-Object {
    Get-CimInstance Win32_Service -ComputerName $_.HostName |
        Where-Object { $_.PathName -notmatch '\\Windows\\' } |
        Select-Object PSComputerName, Name, StartName, PathName
}

Prüfen: Konten, Gruppen und indirekte Kontrolle

Integrierte privilegierte Gruppen

Gehen Sie von bekannten SIDs aus statt von Namen, die je nach Sprache variieren:

Ergänzen Sie DnsAdmins (kein fester RID) und alle Produktgruppen mit Rechten auf Domänenebene, etwa Exchange Windows Permissions von Exchange in älteren Bereitstellungen.

$domain = Get-ADDomain
$root   = Get-ADDomain -Identity (Get-ADForest).RootDomain
$d = $domain.DomainSID.Value
$r = $root.DomainSID.Value
$targets = @(
    'S-1-5-32-544','S-1-5-32-548','S-1-5-32-549','S-1-5-32-550','S-1-5-32-551',
    "$d-512","$d-516","$d-520","$d-526" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $domain.DNSRoot } }
) + @(
    # Schema Admins, Enterprise Admins und Enterprise Key Admins gibt es nur in der Stammdomäne der Gesamtstruktur
    "$r-518","$r-519","$r-527" |
        ForEach-Object { [pscustomobject]@{ Sid = $_; Server = $root.DNSRoot } }
)

foreach ($t in $targets) {
    $g = Get-ADGroup -Identity $t.Sid -Server $t.Server
    Get-ADGroupMember -Identity $g -Server $t.Server -Recursive |
        Select-Object @{n='Group';e={$g.Name}}, Name, objectClass, distinguishedName
}

Jedes zurückgegebene Mitglied ist ein Tier-0-Konto, einschließlich Dienstkonten und Mitgliedern verschachtelter Gruppen, mit denen Sie nicht gerechnet haben. -Recursive liefert nur die Endbenutzer und -computer; listen Sie die verschachtelten Gruppen selbst mit einer nicht rekursiven Abfrage auf, falls Sie sie benötigen.

Indirekte Kontrolle über ACLs und GPOs

Hier sind die meisten Inventuren unvollständig. Suchen Sie nach:

• Replikationsrechten auf dem Domänenkopf (DS-Replication-Get-Changes-All), behandelt in DCSync-Rechte finden.
• Schreibzugriff auf GPOs, die mit der OU Domain Controllers oder dem Domänenstamm verknüpft sind, sowie gPLink-Schreibrechten auf diesen Containern.
• Besitzern und Schreibrechten auf AdminSDHolder, Tier-0-OUs und Tier-0-Benutzerobjekten (Kennwort zurücksetzen, GenericAll, WriteDacl, WriteOwner).
• Lesern von Tier-0-Geheimnissen: Prinzipalen, die gMSA-Kennwörter abrufen dürfen, die auf Tier-0-Servern verwendet werden, und Prinzipalen, die LAPS-Kennwörter von Tier-0-Computern lesen können.

# Mit der OU Domain Controllers verknüpfte GPOs und wer sie bearbeiten darf
$dcOu = (Get-ADDomain).DomainControllersContainer
(Get-GPInheritance -Target $dcOu).GpoLinks | ForEach-Object {
    $gpoName = $_.DisplayName
    Get-GPPermission -Guid $_.GpoId -All |
        Where-Object { $_.Permission -in 'GpoEdit','GpoEditDeleteModifySecurity' } |
        Select-Object @{n='GPO';e={$gpoName}}, @{n='Trustee';e={$_.Trustee.Name}}, Permission
}

# Prinzipale, die gMSA-Kennwörter lesen dürfen (für gMSAs auf Tier-0-Servern)
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Eine manuelle ACL-Prüfung skaliert nicht über einige wenige Container hinaus. Setzen Sie BloodHound oder ein vergleichbares Graphwerkzeug ein, markieren Sie Ihre bekannten Tier-0-Objekte und listen Sie jeden Prinzipal mit einem Pfad dorthin auf. Der Ablauf ist in Attack Path Management beschrieben.

Häufig übersehen

Über viele Assessments hinweg fehlen immer wieder dieselben Assets in Tier 0. Prüfen Sie jedes davon explizit.

Cloud-Identitäten mit einem Pfad zurück nach On-Premises. Wenn Entra Connect mit Kennwortrückschreiben läuft oder Cloud-Administratoren den Entra-Connect-Server über Azure Arc, Intune oder eine Cloud-VM-Konsole verwalten können, erreichen manche Cloud-Rollen Tier 0. Ermitteln Sie, wer Global Administrator und Hybrid Identity Administrator ist und wem das Abonnement gehört, in dem ein DC oder Synchronisierungsserver läuft, und nehmen Sie diese Rollen in die Inventur auf.

DnsAdmins und DNS-Zonenrechte. Die Mitgliedschaft in DnsAdmins oder Schreibzugriff auf die DNS-Serverkonfiguration erlaubte in der Vergangenheit Codeausführung auf DCs über DNS-Plugin-Einstellungen auf Serverebene. Selbst wo gepatcht, erlaubt Schreibzugriff auf AD-integrierte Zonen das Umleiten von Datenverkehr für DC-Namen. Halten Sie die Gruppe leer oder ausschließlich mit Tier-0-Mitgliedern.

Zertifikatvorlagen und PKI-Objekte. Der CA-Server ist nicht das einzige AD-CS-Asset. Schreibzugriff auf Zertifikatvorlagen, das Objekt NTAuthCertificates oder den Container Public Key Services in der Konfigurationspartition kann eine Vorlage hervorbringen, die sich als Domain Admin authentifiziert. Diese Objekte liegen in der Konfigurationspartition und werden bei einer OU-basierten Prüfung leicht übersehen.

Backup- und Snapshot-Konsolen. Wer den Systemstatus eines DC wiederherstellen, einen Snapshot einbinden oder eine VM aus dem Backup exportieren kann, kann NTDS.dit lesen. Das betrifft die Backup-Operatoren im Backupprodukt, nicht nur die AD-Gruppe Backup Operators.

Dienstkonten auf DCs. Monitoring-, Backup- und EDR-Agents laufen oft unter einem Domänenkonto, dessen Kennwort auf Dutzenden Tier-1-Servern gespeichert ist. Das Konto ist Tier 0, weil es auf DCs läuft, also ist jeder Server, der sein Kennwort speichert, jetzt ebenfalls Tier 0. Ersetzen Sie solche Konten durch lokales SYSTEM, ein auf DCs beschränktes gMSA oder ein dediziertes Konto pro Tier.

Ehemalige Administratoren. Frühere Admins mit adminCount=1, vor Jahren namentlich vergebene veraltete ACEs und deaktivierte Konten, die weiterhin Tier-0-Objekte besitzen, halten Kontrollpfade am Leben. Insbesondere Besitz gewährt implizit WriteDacl; prüfen Sie daher den Owner von Tier-0-Objekten, nicht nur deren DACL.

Durchsetzen: Inventur festhalten und eingrenzen

Eine Inventur in einer Tabelle veraltet innerhalb weniger Wochen. Bilden Sie sie in AD ab, damit Richtlinien darauf zielen können:

1. Erstellen Sie eine dedizierte Tier-0-OU-Struktur (zum Beispiel OU=Tier0 mit den untergeordneten OUs Accounts, Groups, Servers, Devices) und verschieben Sie jedes Tier-0-Benutzer-, Gruppen- und Serverobjekt dorthin. Blockieren Sie die Vererbung nur, wenn Sie geprüft haben, was dadurch entfällt.
2. Erstellen Sie Gruppen wie Tier0-Servers und Tier0-Accounts mit den Computer- und Benutzerobjekten, damit Anmeldeverweigerungs-GPOs und Silos auf Gruppen statt auf Listen verweisen.
3. Beschränken Sie das Ändern dieses OU-Baums auf Tier-0-Admins. Entfernen Sie geerbte Delegierungen an Helpdesk- und Tier-1-Gruppen.
4. Entscheiden Sie für jeden gefundenen indirekten Pfad: entfernen (die übliche Antwort) oder akzeptieren und den kontrollierenden Prinzipal nach Tier 0 verschieben.

# Tier-0-Server für nachgelagerte Richtlinien kennzeichnen
$t0 = Get-ADGroup 'Tier0-Servers'
'DC01','DC02','PKI-ISSUING01','ENTRACONNECT01' | ForEach-Object {
    Add-ADGroupMember -Identity $t0 -Members (Get-ADComputer $_)
}

Überprüfen

Überprüfen bedeutet nachzuweisen, dass es keine unerklärten Kontrollpfade in die gekennzeichnete Menge gibt:

# Von SDProp geschützte Objekte: Alles, was hier nicht in Ihrer Tier-0-Liste steht, muss erklärt werden
Get-ADObject -LDAPFilter '(adminCount=1)' -Properties objectClass, whenChanged |
    Select-Object Name, objectClass, whenChanged, DistinguishedName

# Tier-0-OU: nicht geerbte ACEs für Prinzipale außerhalb von Tier 0
$ou = "OU=Tier0,$((Get-ADDomain).DistinguishedName)"
(Get-Acl "AD:$ou").Access | Where-Object { -not $_.IsInherited } |
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

Veraltete Konten mit adminCount=1 sind häufig, nachdem Personen privilegierte Gruppen verlassen haben. Leeren Sie adminCount und stellen Sie die Vererbung auf diesen Konten wieder her, sobald Sie bestätigt haben, dass sie keiner geschützten Gruppe mehr angehören. Im Graphwerkzeug ist die Prüfung einfach: Die Anzahl der Nicht-Tier-0-Prinzipale mit einem Pfad zu Domain Admins sollte gegen null tendieren, und für jeden verbleibenden Pfad sollte es ein Ticket geben.

Was dabei bricht

• Gemeinsam genutzte Managementwerkzeuge: Sobald DCs als Tier 0 deklariert sind, wird die unternehmensweite SCCM-, EDR- oder Monitoring-Konsole, die sie verwaltet, entweder (samt ihren Admins) auf Tier 0 angehoben oder muss aufhören, DCs zu verwalten. Beide Optionen verschieben die betriebliche Verantwortung und erfordern ein separates Werkzeug oder einen eigenen Geltungsbereich für Tier 0.
• Virtualisierungsbetrieb: VMware- oder Hyper-V-Admins, die DC-VMs verwalten können, werden zu Tier-0-Admins. Rechnen Sie mit Widerstand und planen Sie einen dedizierten Cluster oder einen eingeschränkten Berechtigungsumfang für die DC-VMs.
• Delegierte Helpdesk-Rechte: Das Verschieben von Tier-0-Konten in eine geschützte OU entfernt Delegierungen für Kennwortrücksetzung und Entsperrung, die bisher für sie galten. Admins, die ihr Tier-0-Konto sperren, brauchen nun einen Tier-0-Kollegen, nicht den Helpdesk.
• Backup-Wiederherstellungen: Die Beschränkung der Backupplattform auf Tier-0-Operatoren kann routinemäßige Dateiwiederherstellungen verlangsamen, wenn dieselbe Konsole beides bedient. Verlagern Sie den DC-Backupjob auf dedizierte Infrastruktur, wie in AD-Backups vor Ransomware schützen beschrieben.

Weiterführende Lektüre: der Überblick Tier 0 und privilegierter Zugriff für den gesamten Bereich, Privileged Access Workstations für die Geräte, mit denen diese Inventur verwaltet wird, und ACL- und Objektsicherheit für die detaillierte Prüfung indirekter Kontrollpfade.