Microsoft AZ-801: Sicherheit von Active Directory Domain Services — Lernleitfaden

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Teil des Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Active Directory Domain Services (AD DS) ist die Grundlage für Identität und Zugriff in Windows-Netzwerken. Die Absicherung von AD DS bedeutet, zu kontrollieren, wie Anmeldeinformationen erstellt, gespeichert und verwendet werden, einzuschränken, wo sich privilegierte Identitäten authentifizieren können, Authentifizierungsprotokolle zu härten, hochwertige Aktionen zu überwachen und eine zuverlässige Wiederherstellung zu gewährleisten. Dieser Abschnitt behandelt differenzierte Kennwort- und Kontorichtlinien, den Schutz privilegierter Identitäten, die Härtung und Delegierung der Authentifizierung, die Überwachung und SACLs, den Papierkorb, LDAP-Signierung und Channel-Binding, das Verhalten von AdminSDHolder, Backups und autoritative Wiederherstellungen einschließlich der SYSVOL-Wiederherstellung sowie das AD-Tiering-Modell.

Richtlinien für Anmeldeinformationen und Kontrollen für privilegierte Identitäten

Differenzierte Kennwortrichtlinien (Fine-Grained Password Policies, PSOs) ermöglichen mehrere Kennwort- und Sperrungsrichtlinien in einer einzigen Domäne, ohne dass zusätzliche Domänen erforderlich sind. PSOs sind msDS-PasswordSettings-Objekte, die in CN=Password Settings Container,CN=System,<domain DN> (dem msDS-PasswordSettingsContainer) gespeichert sind. Eine PSO wird über msDS-PSOAppliesTo auf Benutzer und globale Sicherheitsgruppen angewendet. Wenn für einen Benutzer mehrere PSOs gelten (direkt oder über Gruppen), ist die resultierende PSO diejenige mit dem niedrigsten msDS-PasswordSettingsPrecedence-Wert; bei einem Gleichstand gewinnt die PSO mit der niedrigsten GUID. Die für den Benutzer wirksame PSO wird in msDS-ResultantPSO eingetragen. Entwerfen Sie PSOs so, dass niedrigere Rangfolgenummern den restriktivsten Richtlinien entsprechen, die sich durchsetzen sollen, und überprüfen Sie die wirksamen Richtlinien durch Auslesen von msDS-ResultantPSO.

Die Sicherheitsgruppe Protected Users härtet hochwertige Konten, indem sie veraltete und riskante Authentifizierungsverhalten entfernt. Mitglieder:

• Können NTLM, Digest oder CredSSP nicht verwenden
• Wird die Verwendung von RC4 und DES für Kerberos verweigert
• Können nicht über Kerberos delegiert werden (weder unconstrained noch constrained)
• Erhalten nicht verlängerbare TGTs mit einer festen, kurzen Lebensdauer (Standard: 4 Stunden)
• Speichern keine Klartext-Anmeldeinformationen oder Langzeitgeheimnisse auf der Workstation zwischen (verhindert WDigest-Fallback und das Verbleiben von Anmeldeinformationsmaterial in LSASS) Verwenden Sie diese Gruppe für von Menschen bediente privilegierte Identitäten und Besitzer von Hochrisikodiensten, nachdem Sie die Anwendungskompatibilität überprüft haben. Domänencontroller müssen mindestens Windows Server 2012 R2 ausführen, um diese Schutzmaßnahmen durchzusetzen.

Authentifizierungsrichtlinien und Authentifizierungsrichtliniensilos schränken ein, wo und wie sich Konten authentifizieren können. Eine Authentifizierungsrichtlinie kann pro Konto Kerberos-Einschränkungen festlegen, wie z. B. die TGT-Lebensdauer und erlaubte Geräte (anhand von SPN/Host-FQDN). Ein Authentifizierungsrichtliniensilo gruppiert Benutzer, Computer und Dienstkonten, sodass sich nur erlaubte Kombinationen mittels des durch diese Richtlinie eingeschränkten Kerberos authentifizieren können. Dies erzwingt „Station-to-Admin“-Kontrollen: Beispielsweise können sich Tier-0-Administratoren nur an Domänencontrollern und designierten Privileged Access Workstations (PAWs) anmelden, nicht aber an Mitgliedsservern oder Workstations. Kombinieren Sie dies mit „Protected Users“, um maximale Wirkung zu erzielen. Diese Funktionen erfordern Windows Server 2012 R2 DCs und KDC-Armoring.

AdminSDHolder und SDProp schützen die ACLs von privilegierten Identitäten. Mitglieder von integrierten Admin-Gruppen (z. B. Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Server Operators, Backup Operators, Print Operators und andere) sind „geschützt“. SDProp wird stündlich auf dem PDC-Emulator ausgeführt, kopiert die ACL von CN=AdminSDHolder,CN=System auf geschützte Objekte und deaktiviert die ACL-Vererbung für diese (AdminCount=1). Um dem Helpdesk Rechte für geschützte Objekte zu gewähren, ändern Sie die ACL auf dem AdminSDHolder – niemals direkt auf einzelnen geschützten Objekten –, da die Änderung sonst rückgängig gemacht wird. Wenn ein Konto aus allen geschützten Gruppen entfernt wird, aktivieren Sie die ACL-Vererbung wieder und setzen Sie AdminCount zurück, damit ACLs und GPOs auf OU-Ebene wieder angewendet werden.

Führen Sie ein AD-Tiering-Modell ein, um die Gefährdung von Anmeldeinformationen zu minimieren. Tier 0 enthält Domänencontroller, Identitätssysteme (PKI, Federation, PAM) und die Administratorkonten, die diese verwalten. Tier 1 enthält Server-Workloads und deren Administratoren. Tier 2 enthält Workstations und deren Administratoren. Verhindern Sie Anmeldungen über Tiers hinweg, verwenden Sie PAWs für die Tier-0/1-Administration und isolieren Sie Anmeldeinformationen mithilfe von Funktionen wie Protected Users, Authentifizierungssilos, Remote Credential Guard, Just-Enough Administration (JEA) und Windows LAPS für die Rotation lokaler Administratorkennwörter.

Härtung der Authentifizierung und Delegierung

LDAP-Signierung und Channel-Binding schützen vor Relay- und Man-in-the-Middle-Angriffen. Konfigurieren Sie Domänencontroller so, dass sie die Signierung über Gruppenrichtlinien erfordern: Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Sicherheitsoptionen\„Domänencontroller: LDAP-Server-Signierungsanforderungen“ = Signierung erforderlich. Erzwingen Sie die Client-Signierung, wo dies möglich ist: „Netzwerksicherheit: LDAP-Client-Signierungsanforderungen“ = Signierung erforderlich. Aktivieren Sie für LDAPS das Channel-Binding auf DCs, indem Sie LDAPEnforceChannelBinding unter HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters auf 1 (Aktiviert, empfohlen) oder 2 (Immer) setzen. Inventarisieren Sie veraltete Geräte und Anwendungen; die Aktivierung der Signierung oder des Channel-Bindings kann anonyme/einfache Bindungen oder alte LDAP-Stacks beeinträchtigen. Überwachen Sie das Ereignisprotokoll des Verzeichnisdiensts: 2886 (Signierung nicht erforderlich), 2887 (Zusammenfassung unsignierter einfacher Bindungen), 2888 (Signierung immer noch deaktiviert), 2889 (Client-IPs, die unsignierte einfache Bindungen durchführen, wenn die Diagnoseprotokollierung aktiviert ist). Führen Sie Änderungen schrittweise im Modus „Warnen“ (Channel-Binding=1) ein, bevor Sie „Immer“ (2) erzwingen.

Die Kerberos-Delegierung steuert, wie Dienste im Namen von Benutzern handeln:

• Uneingeschränkte Delegierung („Diesem Computer bei der Delegierung an einen beliebigen Dienst vertrauen (nur Kerberos)“) ermöglicht es einem Dienst, ein weiterleitbares TGT zu erhalten und Benutzer gegenüber jedem beliebigen Dienst zu imitieren. Dies ist mit hohem Risiko verbunden; vermeiden Sie es zugunsten von eingeschränkten Modellen.
• Eingeschränkte Delegierung (KCD) („Diesem Computer nur bei der Delegierung an angegebene Dienste vertrauen“) begrenzt, wohin ein Dienst delegieren kann (Liste der Ziel-SPNs). Mit „Beliebiges Authentifizierungsprotokoll verwenden“ kann der Dienst einen Protokollübergang (S4U2Self) und dann S4U2Proxy verwenden, um die angegebenen Backends zu erreichen.
• Ressourcenbasierte eingeschränkte Delegierung (RBCD) verlagert die Kontrolle auf die Ressource, indem msDS-AllowedToActOnBehalfOfOtherIdentity für das Zieldienstkonto festgelegt wird. Der Ressourcenbesitzer legt fest, welche Frontend-Prinzipale an ihn delegieren dürfen, was domänenübergreifende Szenarien vereinfacht und die Angriffsfläche minimiert. Bevorzugen Sie RBCD für moderne Designs; überwachen und überprüfen Sie SPNs und Delegierungseinstellungen regelmäßig.

Überwachung und Ausfallsicherheit

Die Überwachung von AD DS muss gezielt und spezifisch sein. Verwenden Sie die „Erweiterte Überwachungsrichtlinienkonfiguration“, um Unterkategorien anstelle der älteren Kategorien zu aktivieren, und setzen Sie „Überwachung: Außerkraftsetzung der Überwachungsrichtlinienkategorieeinstellungen durch Unterkategorieeinstellungen erzwingen“, um die Konsistenz zu gewährleisten. Empfohlene Unterkategorien sind Kontenverwaltung, Anmeldung/Abmeldung (Anmeldung, Abmeldung, Spezielle Anmeldung), Kontoanmeldung (Kerberos-Authentifizierungsdienst/Dienstticketvorgänge) und Verzeichnisdienständerungen/-zugriff. Wichtige Ereignis-IDs:

• 4720 (Ein Benutzerkonto wurde erstellt) aus der Kontenverwaltung
• 4740 (Ein Benutzerkonto wurde gesperrt) aus der Kontenverwaltung
• 4625 (Fehler bei der Kontenanmeldung) aus Anmeldung/Abmeldung
• 4648 (Es wurde versucht, eine Anmeldung mit expliziten Anmeldeinformationen durchzuführen) aus Anmeldung/Abmeldung Ergänzen Sie dies mit Verzeichnisdienständerungen, um die Wer/Was/alten/neuen Werte für kritische Attribute zu erfassen (Ereignisse 5136/5137/5139). Um spezifische Änderungen (z. B. Gruppenmitgliedschaften, SPNs, ACLs) zu überwachen, konfigurieren Sie SACLs für gezielte Objekte oder OUs (aktivieren Sie „Erweiterte Features“ in ADUC, öffnen Sie Objekt-Sicherheit > Erweitert > Überwachung). Fügen Sie Einträge hinzu, um „Alle Eigenschaften schreiben“ oder bestimmte Eigenschaften (member, servicePrincipalName) sowie bei Bedarf „Berechtigungen/Besitzer ändern“ zu überwachen. Stellen Sie sicher, dass die Protokolle ein zentrales SIEM erreichen und dass die Sicherheitsprotokolle der DCs eine ausreichende Aufbewahrungsdauer haben.

Der AD DS-Papierkorb schützt vor versehentlichen Löschungen, indem er alle Attribute und Backlinks für gelöschte Objekte beibehält. Aktivieren Sie ihn einmal pro Gesamtstruktur (unumkehrbar) über das ADAC oder PowerShell (Enable-ADOptionalFeature -Identity ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target <forest>). Nach der Aktivierung verbleibt ein gelöschtes Objekt für die Dauer von msDS-DeletedObjectLifetime (wenn nicht festgelegt, wird standardmäßig tombstoneLifetime verwendet) im Zustand eines „gelöschten Objekts“. Während dieser Zeit kann es vollständig mit intakten Attributen wiederhergestellt werden. Danach wird es zu einem recycelten Objekt und ist nicht mehr mit Attributen wiederherstellbar, und später wird es durch die Garbage Collection endgültig entfernt. In modernen Gesamtstrukturen beträgt die tombstoneLifetime standardmäßig 180 Tage; in älteren Gesamtstrukturen können es 60 sein. Stellen Sie Objekte mit dem ADAC, LDP oder PowerShell (Restore-ADObject) wieder her und bevorzugen Sie die autoritative Wiederherstellung von Gruppenmitgliedschaften über den Papierkorb anstelle des manuellen Hinzufügens, um eine Ausweitung von Berechtigungen (Privilege Drift) zu vermeiden.

Backups und die autoritative Wiederherstellung sind Schutzmaßnahmen der letzten Instanz. Erstellen Sie häufige Systemstatus-Backups von jedem Domänencontroller mit Windows Server-Sicherung oder wbadmin (wbadmin start systemstatebackup). Führen Sie für Rollbacks auf Objektebene, die über den Papierkorb hinausgehen, eine nicht autoritative Wiederherstellung des Systemstatus durch und verwenden Sie dann ntdsutil, um bestimmte Objekte oder OUs als autoritativ zu markieren (wodurch ihre Version erhöht wird, sodass die Replikation sie erneut anwendet). Verstehen Sie den Unterschied: Eine nicht autoritative Wiederherstellung bringt den DC zurück und wendet dann die aktuelle Replikation an; eine autoritative Wiederherstellung markiert ein Objekt, sodass die wiederhergestellte Version neuere Replikate überschreibt. Führen Sie für SYSVOL mit DFS-Replikation (DFSR) eine nicht autoritative oder autoritative Wiederherstellung durch:

• Nicht autoritativ: Beenden Sie den DFSR-Dienst, setzen Sie das SYSVOL-Abonnement des betroffenen Mitglieds auf nicht autoritativ (msDFSR-Options=0) und starten Sie DFSR, damit es sich von einem Upstream-Partner neu hydriert.
• Autoritativ: Setzen Sie auf dem ausgewählten, funktionierenden DC das SYSVOL-Abonnement auf msDFSR-Options=1 (autoritativ), starten Sie DFSR und erzwingen Sie dann eine Neusynchronisierung der Partner (DFSRDIAG PollAD). Überprüfen Sie den Zustand mit dfsrdiag backlog und den Ereignisprotokollen. Migrieren Sie bei Verwendung des veralteten FRS (nicht unterstützt) zu DFSR und vermeiden Sie BurFlags-Prozeduren.

Praktische Umsetzung: Betrieb, Prioritäten bei der Härtung und gestufter Zugriff

Priorisieren Sie zuerst Tier 0: Erzwingen Sie LDAP-Signierung/Channel-Binding, entfernen Sie die uneingeschränkte Delegierung, stellen Sie auf KCD/RBCD um, platzieren Sie privilegierte Identitäten in „Protected Users“ und fügen Sie Authentifizierungsrichtlinien/-silos an, um Anmeldeendpunkte einzuschränken, und schreiben Sie PAWs für Tier-0/1-Administratoren vor. Richten Sie PSOs für privilegierte Konten mit strenger Sperrung und Rotation ein. Aktivieren Sie die erweiterte Überwachung mit SACLs für Tier-0-Container. Stellen Sie tägliche DC System State-Backups und dokumentierte Runbooks für die autoritative Wiederherstellung und die SYSVOL-Wiederherstellung sicher. Blockieren Sie in Tier 1/2 die Administratoranmeldung bei niedrigeren Tiers, unterbinden Sie die Wiederverwendung lokaler Administratoren mit Windows LAPS und überwachen Sie Spitzen bei 4625/4740 sowie den Missbrauch von 4648 auf Versuche der lateralen Bewegung.

Praktisches Problemszenario

Adobe muss eine lokale AD DS-Gesamtstruktur schnell absichern, nachdem eine Tochtergesellschaft übernommen wurde, deren Line-of-Business-Anwendungen auf Legacy-Protokollen basieren. Die Ziele sind, den Erfolg von Password-Spraying-Angriffen zu reduzieren, Credential-Relay-Angriffe auf DCs zu unterbinden, privilegierte Anmeldungen auf PAWs zu beschränken, die Delegierung für einen Web-Tier zu modernisieren und eine schnelle Wiederherstellung nach versehentlichen Löschungen sicherzustellen.

1. PSOs definieren und privilegierten Gruppen zuweisen

• Erstellen Sie ein strenges PSO (niedriger Rangfolgenwert) im msDS-PasswordSettingsContainer mit kurzem Kennwortalter, hoher Komplexität und aggressiver Sperrung.
• Wenden Sie es über msDS-PSOAppliesTo auf die Gruppen „Domänen-Admins“, „Server-Admins“ und eine benutzerdefinierte Gruppe „Tier0-Privs“ an. Warum: Feingranulare PSOs zielen nur auf Hochrisikokonten ab, ohne die gesamte Domäne zu stören, und die Rangfolge garantiert, dass die strengere Richtlinie Vorrang hat.

2. Protected Users und Authentifizierungssilos erzwingen

• Fügen Sie menschliche Tier-0-Administratoren zur Gruppe „Protected Users“ hinzu.
• Erstellen Sie eine Authentifizierungsrichtlinie, die Kerberos-Anmeldungen nur von PAW-Host-SPNs und DCs erlaubt; verknüpfen Sie Konten und PAWs in einem Authentifizierungsrichtlinien-Silo. Warum: „Protected Users“ eliminiert NTLM/RC4 und verhindert Delegierung; Silos erzwingen „nur von PAWs“, was die Exposition von Tokens und die Pfade für den Diebstahl von Anmeldeinformationen reduziert.

3. LDAP härten und auf Ausfälle überwachen

• Setzen Sie „Domänencontroller: LDAP-Server-Signierungsanforderungen“ auf „Erforderlich“; konfigurieren Sie anfänglich LDAPEnforceChannelBinding=1.
• Überprüfen Sie die Verzeichnisdienst-Ereignisse 2886–2889, um Legacy-Bindungen zu identifizieren; korrigieren Sie die Apps und setzen Sie dann LDAPEnforceChannelBinding=2. Warum: Signierung und Channel-Binding unterbinden gängige Relay-Pfade zu DCs, während eine stufenweise Durchsetzung Ausfälle vermeidet.

4. Delegierung für den Web-Tier auf RBCD migrieren

• Stellen Sie Front-End-Webserver von uneingeschränkter Delegierung auf RBCD um, indem Sie ihre Computerkonten zum Attribut msDS-AllowedToActOnBehalfOfOtherIdentity des Back-End-API-Dienstkontos hinzufügen.
• Entfernen Sie die alten Flags „Diesen Computer für die Delegierung an einen beliebigen Dienst vertrauen“; definieren Sie Dienst-SPNs präzise. Warum: RBCD ermöglicht es der Ressource vorzugeben, wer an sie delegieren darf, und beschränkt die Identitätsübernahme auf die beabsichtigten Ziele, was die laterale Bewegung einschränkt.

5. Erweiterte Überwachung und SACLs aktivieren

• Konfigurieren Sie die erweiterte Überwachungsrichtlinie für Kontenverwaltung, An-/Abmeldung, Kontoanmeldung und Verzeichnisdienständerungen.
• Fügen Sie auf Tier-0-OUs und wichtigen Gruppen SACLs hinzu, die Schreibvorgänge auf „member“ und „servicePrincipalName“ sowie Änderungen von Berechtigungen/Besitzern überwachen.
• Leiten Sie Protokolle an ein SIEM weiter; alarmieren Sie bei Anomalien der Ereignisse 4720, 4740, 4625 und 4648. Warum: Man kann nicht verteidigen, was man nicht sieht; diese Ereignisse decken die Erstellung von Konten, Kontosperrungen, fehlgeschlagene Anmeldungen und Muster der expliziten Verwendung von Anmeldeinformationen auf.

6. AD DS-Papierkorb aktivieren und Wiederherstellungs-Runbooks finalisieren

• Aktivieren Sie den Papierkorb auf Gesamtstrukturebene und dokumentieren Sie die Workflows für Restore-ADObject.
• Standardisieren Sie tägliche DC System State-Backups mit Windows Server Backup und testen Sie die autoritative Wiederherstellung über ntdsutil in einer Laborumgebung.
• Dokumentieren und üben Sie die autoritative und nicht autoritative Wiederherstellung von DFSR SYSVOL. Warum: Eine schnelle, präzise Wiederherstellung schreckt Angreifer von destruktiven Aktionen ab und mildert administrative Fehler ohne eine Ausweitung von Berechtigungen (Privilege Drift).

7. Das AD-Tiering-Modell operativ implementieren

• Definieren Sie Tier-0/1/2-Assets; schränken Sie Administratoranmeldungen nach Tier mithilfe von Gruppenrichtlinien und Authentifizierungssilos ein.
• Stellen Sie PAWs für Tier 0/1 bereit, erzwingen Sie Remote Credential Guard und rotieren Sie lokale Administratorkennwörter mit Windows LAPS. Warum: Tiering stellt die Isolation von Anmeldeinformationen sicher, stoppt die Eskalation durch Angreifer über Ebenen hinweg und bringt den täglichen Betrieb mit den Sicherheitsgrenzen in Einklang.

← Microsoft Sentinel und Sicherheitsüberwachung · Alle Domänen · Azure Arc und hybrides Servermanagement →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →