Tiering-Modell & Administrative Isolation
Das Administrative Tiering-Modell ist Microsofts offiziell empfohlene Architektur zur Absicherung von Active Directory — und wird dennoch in über 90 % der deutschen Unternehmen nicht implementiert. Das Prinzip: Tier 0 (Domain Controller, ADFS, PKI, SCCM) darf niemals von Workstations aus administriert werden. Tier 1 (Member Server) und Tier 2 (Workstations, Endgeräte) sind strikt getrennt. Ein Admin-Konto, das sich an einer Workstation anmeldet, darf niemals Zugriff auf Domain Controller haben — und umgekehrt.
- Authentication Policy Silos — Hardware-erzwungene Tier-Trennung: Seit Windows Server 2012 R2 existiert ein kaum genutztes Feature: Authentication Policy Silos. Diese erzwingen auf Kerberos-Ebene, dass bestimmte Konten sich nur an bestimmten Computern authentifizieren können — nicht über GPO (die umgangen werden kann), sondern über den KDC (Key Distribution Center) selbst. Einrichtung:
New-ADAuthenticationPolicy -Name "Tier0-Policy" -UserAllowedToAuthenticateFrom "O:SYG:SYD:(XA;OICI;CR;;;WD;(@USER.ad://ext/AuthenticationSilo == "Tier0-Silo"))". Dann:New-ADAuthenticationPolicySilo -Name "Tier0-Silo"und die Policy/Silo den Tier-0-Konten und -Computern zuweisen. Ergebnis: Selbst wenn ein Angreifer das Passwort eines Tier-0-Admins stiehlt, kann er sich nicht an einer Workstation damit anmelden — der KDC verweigert das TGT. - Protected Users Gruppe — die vergessene Sicherheitsgruppe: Die Gruppe Protected Users existiert seit Server 2012 R2, wird aber selten genutzt. Mitglieder dieser Gruppe erhalten automatisch: Kein NTLM — nur Kerberos-Authentifizierung (NTLM-Relay-Angriffe werden unmöglich). Kein DES/RC4 — nur AES-Verschlüsselung für Kerberos-Tickets. Keine Delegation — Kerberos-Delegation wird verweigert (verhindert Unconstrained Delegation-Angriffe). Kein Credential Caching — Anmeldeinformationen werden nicht im LSASS-Speicher zwischengespeichert. TGT-Lebensdauer: 4 Stunden statt 10 Stunden. Fügen Sie alle privilegierten Konten hinzu:
Add-ADGroupMember "Protected Users" -Members "Tier0-Admin","Tier1-Admin". Achtung: Service Accounts, die NTLM oder Delegation benötigen, dürfen nicht Mitglied sein. - gMSA (Group Managed Service Accounts) — nie wieder Service-Account-Passwörter: gMSA sind die Zukunft der Service-Account-Verwaltung — und werden in Deutschland fast nie eingesetzt. Ein gMSA hat ein 240-Zeichen-Passwort, das alle 30 Tage automatisch vom Domain Controller rotiert wird. Kein Mensch kennt oder verwaltet das Passwort. Einrichtung: Zuerst den KDS Root Key erstellen (einmalig pro Forest):
Add-KdsRootKey -EffectiveImmediately(Produktiv:-EffectiveTime ((Get-Date).AddHours(-10))). Dann:New-ADServiceAccount -Name "gMSA-SQL" -DNSHostName "gmsa-sql.domain.de" -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers". Auf dem Zielserver:Install-ADServiceAccount -Identity "gMSA-SQL". Den Dienst mitdomain\gMSA-SQL$konfigurieren, Passwortfeld leer lassen. Kerberoasting-Angriffe werden durch das 240-Zeichen-Passwort praktisch unmöglich. - Windows LAPS v2 — der Nachfolger mit Post-Authentication-Actions: Windows LAPS (nativ in Windows 11 22H2+ und Server 2025) ersetzt das alte Legacy-LAPS vollständig. Neue Features: Passwort-Verschlüsselung im AD (via DPAPI-NG — nur autorisierte Benutzer können entschlüsseln, nicht jeder mit AD-Lesezugriff). Passwort-History — die letzten N Passwörter werden gespeichert. Post-Authentication Actions — der revolutionäre Unterschied: Nach Verwendung des LAPS-Passworts wird automatisch das Passwort rotiert und optional ein Reboot erzwungen. Konfiguration per GPO:
Computer Configuration > Administrative Templates > System > LAPS. Kritisch:Post-authentication actionsauf „Reset password and logoff managed account“ oder „Reset password, logoff, and reboot“ setzen. Die Grace Period (Standard: 24h) auf 2-4 Stunden reduzieren.
PowerShell-Toolkit für AD-Härtung
Die folgenden PowerShell-Einzeiler und Skripte setzen wir bei jeder Active-Directory-Härtung ein. Sie decken die häufigsten Schwachstellen auf, die wir in deutschen Unternehmen finden — von vergessenen Service Accounts über SPN-Fehlkonfigurationen bis hin zu verwaisten Admin-Konten.
- Kerberoastable Accounts finden — bevor es der Angreifer tut:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, Enabled | Select Name, ServicePrincipalName, PasswordLastSet, Enabled | Sort PasswordLastSet. Dieser Befehl zeigt alle Konten mit SPNs — potenzielle Kerberoasting-Ziele. Kritisch sind Konten mit alten Passwörtern (PasswordLastSet vor > 1 Jahr) — diese haben schwache Passwörter, die offline geknackt werden können. Lösung: Alle Service Accounts auf gMSA migrieren, oder Passwörter auf 25+ Zeichen ändern und regelmäßig rotieren. Zusätzlich:Get-ADUser -Filter {AdminCount -eq 1} -Properties AdminCount, MemberOf— zeigt Konten, die jemals in einer privilegierten Gruppe waren (auch wenn sie bereits entfernt wurden — der AdminCount wird nicht automatisch zurückgesetzt). - Stale Computer & User Accounts — Angriffsoberfläche reduzieren:
$stale = Get-ADComputer -Filter {LastLogonTimestamp -lt $((Get-Date).AddDays(-90).ToFileTime())} -Properties LastLogonTimestamp | Select Name, @{N='LastLogon';E={[DateTime]::FromFileTime($_.LastLogonTimestamp)}}. Zeigt alle Computer, die sich seit 90 Tagen nicht angemeldet haben — diese sind oft vergessene Testserver oder ehemalige Mitarbeiter-Laptops mit veralteten Patches. Gleiches für Benutzer:Search-ADAccount -AccountInactive -TimeSpan 90 -UsersOnly | Select Name, LastLogonDate, Enabled. Automatische Bereinigung:Search-ADAccount -AccountInactive -TimeSpan 180 -ComputersOnly | Disable-ADAccount(erst deaktivieren, nach 30 Tagen löschen). Pro-Tipp:Get-ADUser -Filter {Enabled -eq $true -and PasswordNeverExpires -eq $true}— zeigt Konten mit „Passwort läuft nie ab“ — oft vergessene Service Accounts mit schwachen, jahrelang ungewänderten Passwörtern. - AD-Replikation & DC-Gesundheit überwachen:
repadmin /replsummary— zeigt den Replikationsstatus aller Domain Controller auf einen Blick.dcdiag /v /c /d /e /s:DC01— umfassender Health-Check aller DCs im Forest (DNS, FSMO, Replikation, Services, Sysvol). PowerShell-Alternative:Get-ADReplicationPartnerMetadata -Target * -Scope Server | Select Server, Partner, LastReplicationSuccess, LastReplicationResult | Where {$_.LastReplicationResult -ne 0}— zeigt nur fehlgeschlagene Replikationen. FSMO-Rollen prüfen:netdom query fsmo. Kritisch: Alle 5 FSMO-Rollen sollten auf demselben DC oder maximal auf 2 DCs verteilt sein. Tombstone Lifetime prüfen:(Get-ADForest).TombstoneLifetime— Standard ist 180 Tage, sollte nicht unterschritten werden. - Privilegierte Gruppen & Delegation überwachen:
@("Domain Admins","Enterprise Admins","Schema Admins","Administrators","Backup Operators","Server Operators","Account Operators") | ForEach { $g = $_; Get-ADGroupMember $g -Recursive | Select @{N='Group';E={$g}}, Name, SamAccountName }— zeigt alle Mitglieder aller privilegierten Gruppen inklusive verschachtelter Mitgliedschaften. Enterprise Admins und Schema Admins sollten im Normalbetrieb leer sein — Mitglieder nur temporär für Forest-Änderungen hinzufügen. Unconstrained Delegation finden:Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation | Select Name— jedes System mit Unconstrained Delegation ist ein potenzielles Tier-0-Kompromittierungsrisiko (Angreifer können TGTs aller authentifizierenden Benutzer abfangen). Stattdessen Constrained Delegation mit Protokollübergang oder besser Resource-Based Constrained Delegation (RBCD) verwenden.
IT-ZU AD-Härtungs-Checkliste
Diese Checkliste basiert auf unserer 10-jährigen Erfahrung als Systemadministratoren und Programmierer. Jeder Punkt wurde in realen Kundenprojekten validiert und deckt die häufigsten Schwachstellen ab, die wir in deutschen KMU-Umgebungen finden.
- Tier 0 — Domain Controller & Identität: ✓ Separate Admin-Konten pro Tier (niemals dasselbe Konto für DC und Workstation). ✓ Protected Users-Gruppe für alle Tier-0-Admins. ✓ Authentication Policy Silos für Tier-Trennung. ✓ LSASS als PPL konfiguriert (
RunAsPPL = 1). ✓ Credential Guard aktiviert (Windows 11 Enterprise). ✓ Domain Controller nur per PAW (Privileged Access Workstation) administrieren — niemals RDP von einer normalen Workstation. ✓ KRBTGT-Passwort alle 180 Tage rotieren:Invoke-Command -ScriptBlock { Reset-ComputerMachinePassword }oder via Microsoft-Skript. - Tier 1 — Server & Applikationen: ✓ Alle Service Accounts auf gMSA migriert. ✓ Windows LAPS v2 mit Post-Authentication Actions und 2h Grace Period. ✓ SMB Signing erzwungen (
RequireSecuritySignature = 1). ✓ RC4 für Kerberos deaktiviert (nur AES128/AES256). ✓ LDAP Signing und Channel Binding auf „Required“. ✓ Stale Accounts (90+ Tage inaktiv) automatisch deaktiviert. - Tier 2 — Endgeräte & Monitoring: ✓ Credential Caching auf 1 reduziert (Server: 0). ✓ SAM Remote Access eingeschränkt. ✓ NTLM Audit aktiviert, Ziel: NTLM komplett deaktivieren. ✓ NetLogon Secure Channel mit
FullSecureChannelProtection = 1. ✓ Sysmon auf allen Systemen mit AD-fokussierter Config (Event 1/3/10/22). ✓ Sigma-Regeln für DCSync, DCShadow, Kerberoasting, AS-REP Roasting. - Forest & Trust — die oft vergessene Ebene: ✓ SID Filtering für alle Forest Trusts aktiviert (
netdom trust /EnableSIDHistory:no). ✓ Selective Authentication für externe Trusts (statt Forest-Wide Authentication). ✓ AdminSDHolder-Berechtigungen geprüft — wird alle 60 Minuten auf alle Objekte mitAdminCount=1angewendet. Ein Angreifer, der AdminSDHolder manipuliert, erhält persistenten Zugriff auf alle privilegierten Konten. ✓ Schönes Forest Recovery Konzept: Mindestens 2 DCs pro Domain, regelmäßige SystemState-Backups, dokumentiertes Forest-Recovery-Verfahren mit Offline-DC. ✓Get-ADOptionalFeature -Filter *— prüfen, ob der AD-Papierkorb (Recycle Bin) aktiviert ist — in vielen Umgebungen immer noch nicht aktiv!
Reale AD-Angriffsszenarien & Erkennung
Active Directory ist das Primärziel Nr. 1 bei jedem gezielten Angriff auf Unternehmensnetzwerke. In über 80 % aller Ransomware-Vorfälle wird AD kompromittiert, bevor die Verschlüsselung beginnt. Die folgenden Angriffstechniken sehen wir regelmäßig bei Incident-Response-Einsätzen und Security-Audits.
- DCSync — der gefährlichste AD-Angriff: Ein Angreifer mit Replicating Directory Changes-Berechtigung (die standardmäßig nur Domain Admins haben) kann sich als Domain Controller ausgeben und alle Passwort-Hashes über das MS-DRSR-Protokoll replizieren — inklusive des
krbtgt-Hashes für Golden Tickets. Tool:mimikatz "lsadump::dcsync /domain:corp.de /user:krbtgt". Erkennung: Event-ID 4662 mit Object TypedomainDNSund Properties{1131f6aa-...}(DS-Replication-Get-Changes) von einem Nicht-DC-Computer. Sigma-Regel:win_ad_replication_non_machine_account.yml. Prävention: Die Berechtigung „Replicating Directory Changes All“ auf Least Privilege prüfen — nur Domain Controller und Azure AD Connect sollten diese haben. - Golden Ticket — unbegrenzter Zugriff: Mit dem
krbtgt-Hash kann ein Angreifer beliebige Kerberos-TGTs fälschen — für jeden Benutzer, jede Gruppe, mit beliebiger Lebensdauer. Ein Golden Ticket überlebt Passwortänderungen des Ziel-Benutzers, da es direkt vomkrbtgt-Schlüssel abgeleitet wird. Erkennung: Event-ID 4769 (TGS Request) ohne vorheriges 4768 (TGT Request) vom gleichen Client. Tickets mit ungewöhnlich langer Lebensdauer (Standard: 10h, Golden Ticket oft 10 Jahre). Gegenmassnahme:krbtgt-Passwort zweimal ändern (da der Vorgänger-Hash noch gültig ist) — aber mit 12h Abstand zwischen den Änderungen, da sonst Kerberos-Authentifizierung im gesamten Forest fehlschlägt. - AS-REP Roasting — Konten ohne Kerberos-Vorauthentifizierung: Konten mit deaktivierter Kerberos Pre-Authentication (
DONT_REQUIRE_PREAUTH) geben jedem im Netzwerk einen verschlüsselten Blob zurück, der offline geknackt werden kann. Finden:Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth. Angriff:Rubeus.exe asreproast /format:hashcat→hashcat -m 18200 hash.txt wordlist.txt. Gegenmassnahme: Pre-Authentication für alle Konten aktivieren:Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} | Set-ADAccountControl -DoesNotRequirePreAuth $false. Es gibt fast nie einen legitimen Grund, Pre-Auth zu deaktivieren. - DCShadow — der unsichtbare Domain Controller: DCShadow ist die Stealth-Variante von DCSync: Statt Daten zu lesen, schreibt der Angreifer direkt in AD — indem er seinen Computer temporär als Domain Controller registriert. Änderungen (z. B. SIDHistory hinzufügen, AdminCount setzen, SPNs ändern) werden über die normale AD-Replikation auf alle DCs verteilt und erscheinen als legitime Replikationsänderungen. Erkennung: Event-ID 4742 (Computer Account Modified) mit Attributänderung
ServicePrincipalName— ein normaler Computer sollte niemals SPN-Änderungen erhalten, die auf einen DC hindeuten (GC/,E3514235-...). Zusätzlich:Get-ADComputer -Filter {PrimaryGroupId -eq 516}— nur echte DCs sollten in der Gruppe „Domain Controllers“ (PrimaryGroupID 516) sein.
Hybrid Identity mit Entra ID
Die meisten deutschen Unternehmen betreiben Hybrid Identity — On-Premises Active Directory synchronisiert mit Entra ID (Azure AD) für Microsoft 365, Teams und Azure-Dienste. Die richtige Konfiguration entscheidet über Sicherheit und Benutzererfahrung. Wir implementieren die optimale Architektur für jede Umgebung.
- Authentifizierungsmethode — die richtige Wahl: Password Hash Sync (PHS) — die einfachste und von Microsoft empfohlene Methode: Passwort-Hashes werden in die Cloud synchronisiert. Vorteil: Funktioniert auch bei On-Premises-Ausfall, ermöglicht Leaked Credential Detection (Microsoft prüft Ihre Hashes gegen bekannte Breaches). Pass-Through Authentication (PTA) — Authentifizierung findet On-Premises statt, kein Passwort-Hash in der Cloud. Vorteil: Echtzeit-Kontosperrung und Passwort-Richtlinien greifen sofort. Nachteil: Benötigt mindestens 3 PTA-Agenten für Hochverfügbarkeit. Federation (ADFS) — nur noch für Spezialszenarien empfohlen (Smartcard-Auth, Third-Party-MFA). ADFS ist die komplexeste und anfälligste Variante — der Token-Signing-Zertifikat-Diebstahl ermöglicht Golden SAML-Angriffe.
- Seamless SSO & Kerberos — das perfekte Benutzererlebnis: Seamless Single Sign-On ermöglicht automatische Anmeldung an Microsoft 365 über Kerberos — ohne Passwort-Eingabe für Domain-verbundene Geräte. Funktionsweise: Azure AD Connect erstellt ein Computer-Konto
AZUREADSSOACC$in Ihrem AD. Dieses Konto hat einen Kerberos-Schlüssel, der für die Token-Ausstellung verwendet wird. Kritische Sicherheitsmassnahme: Den Kerberos-Schlüssel dieses Kontos alle 30 Tage rotieren:Update-AzureADSSOForest -OnPremCredentials $cred. Ohne Rotation kann ein Angreifer, der den Schlüssel stiehlt, jeden beliebigen Benutzer bei Azure AD authentifizieren — ähnlich einem Golden Ticket, aber für die Cloud. - Scoping & Filtering — was synchronisiert werden soll: Niemals alle Objekte synchronisieren. Best Practice: OU-basiertes Filtering — nur definierte OUs für die Cloud-Synchronisation freigeben. Privilegierte Konten ausschließen — Domain Admins, Enterprise Admins und Service Accounts sollten nicht nach Entra ID synchronisiert werden. Separate Cloud-Only-Admin-Konten verwenden. Attribut-Filtering — sensible Attribute (extensionAttributes mit internen Daten) von der Sync ausschließen.
Set-ADSyncScheduler -SyncCycleEnabled $false— Sync anhalten während Änderungen. Nach Konfiguration:Start-ADSyncSyncCycle -PolicyType Deltafür einen Delta-Sync. - Conditional Access & MFA — Cloud-seitige Absicherung: Conditional Access ist die wichtigste Sicherheitsebene in Entra ID. Unsere Standard-Policies: Policy 1: MFA für alle Benutzer bei jeder Anmeldung — Ausnahme: Trusted Locations (Büro-IP-Bereiche). Policy 2: MFA immer erforderlich für Admin-Rollen (Global Admin, Exchange Admin, Security Admin). Policy 3: Blockierung von Legacy-Authentifizierung (IMAP, POP3, SMTP AUTH) — diese Protokolle unterstützen kein MFA und sind das Haupteinfallstor für Password-Spray-Angriffe. Policy 4: Compliant Devices Only für sensible Applikationen (Intune-Compliance-Prüfung). Policy 5: Sign-in Risk Policy — bei „High Risk“ automatische Passwortänderung erzwingen (erfordert Azure AD P2). Pro-Tipp: Immer ein Break-Glass-Konto ohne Conditional Access erstellen (starkes Passwort, physisch gespeichert), für den Fall einer Fehlkonfiguration.
AD Disaster Recovery
Ein vollständiger AD-Forest-Verlust (durch Ransomware, fehlgeschlagene Schema-Änderung oder Replikationskatastrophe) ist das Worst-Case-Szenario für jede Windows-Infrastruktur. Ohne funktionierendes AD gibt es keine Authentifizierung, keinen DNS, keine GPO, keine Dateifreigaben — das gesamte Unternehmen steht still. Wir planen und testen das Recovery-Verfahren bevor der Ernstfall eintritt.
- DSRM (Directory Services Restore Mode) — der Notfallzugang: Jeder Domain Controller hat ein DSRM-Passwort, das beim
dcpromogesetzt wurde — und danach in den meisten Unternehmen vergessen wird. Dieses Passwort ermöglicht die Anmeldung am DC, wenn AD nicht verfügbar ist. Kritisch: DSRM-Passwort regelmäßig ändern und dokumentieren:ntdsutil "set dsrm password" "reset password on server null" q q. Seit Windows Server 2008 kann das DSRM-Konto auch für Netzwerk-Anmeldungen verwendet werden (Registry:DsrmAdminLogonBehavior = 2) — was Angreifer für DSRM Persistence missbrauchen können. Deshalb: Den Wert auf0(Standard) oder1belassen und das DSRM-Passwort wie ein Tier-0-Geheimnis behandeln. - Authoritative vs. Non-Authoritative Restore: Non-Authoritative Restore (Standard): Der DC wird aus dem Backup wiederhergestellt und repliziert dann die neuesten Änderungen von anderen DCs. Geeignet für: Einzelner DC-Ausfall bei funktionierendem Forest. Authoritative Restore: Der wiederhergestellte DC überschreibt die anderen DCs — die wiederhergestellten Daten „gewinnen“. Geeignet für: Versehentlich gelöschte OUs/Objekte, die bereits repliziert wurden. Befehl:
ntdsutil "authoritative restore" "restore subtree OU=Finance,DC=corp,DC=de" q q. Warnung: Bei Forest Recovery niemals einen Authoritative Restore des gesamten Forest durchführen — stattdessen dem Microsoft-Forest-Recovery-Verfahren folgen (einen DC pro Domain wiederherstellen, alle anderen DCs neu promoten). - Das IT-ZU Forest Recovery Runbook: Unser erprobtes 8-Schritte-Verfahren: 1. Alle Domain Controller herunterfahren (Netzwerk isolieren). 2. Den DC mit der aktuellsten Backup wählen (SystemState, nicht älter als Tombstone Lifetime). 3. DSRM-Boot, Non-Authoritative Restore. 4. FSMO-Rollen auf diesen DC seizen:
ntdsutil "roles" "connections" "connect to server DC01" q "seize schema master" "seize naming master" "seize rid master" "seize pdn emulator" "seize infrastructure master" q q. 5.krbtgt-Passwort zweimal ändern (mit 12h Abstand). 6. Alle Trust-Passwörter zurücksetzen. 7. Weitere DCs neu promoten (nicht aus Backup wiederherstellen). 8. DNS-Bereinigung und Replikation validieren. - Backup-Strategie für AD — was wirklich gesichert werden muss: SystemState-Backup enthält: AD-Datenbank (
ntds.dit), SYSVOL (GPOs, Skripte), Registry, Boot-Dateien, Zertifikatsdienste. Frequenz: Täglich, Aufbewahrung mindestens 60 Tage (idealerweise bis zur Tombstone Lifetime von 180 Tagen). Offline-Backup: Mindestens ein Backup auf einem Medium, das nicht über das Netzwerk erreichbar ist (Ransomware-Schutz). Windows Server Backup:wbadmin start systemstatebackup -backupTarget:E:. IFM (Install From Media): Regelmäßig ein IFM-Set erstellen für schnelle DC-Promotion:ntdsutil "activate instance ntds" "ifm" "create full C:\IFM" q q. Dieses IFM-Set ermöglicht die Promotion eines neuen DCs in Minuten statt Stunden (keine vollständige Replikation nötig). Azure AD-seitig: Azure AD Connect Health überwachen, Entra ID Conditional Access Policies dokumentieren und exportieren.
Häufig gestellte Fragen
Antworten auf die wichtigsten Fragen rund um Active Directory Migration & Härtung
Sie benötigen Unterstützung bei Active Directory?
Unsere Experten planen und implementieren Ihre AD-Infrastruktur — von der Migration auf Windows Server 2025 über Tiering-Modelle bis zur vollständigen Härtung gegen moderne Angriffstechniken.
Kostenlose Erstberatung →
