Schutz vor versehentlichem Entfernen von AD-OUs: vor Bereinigung prüfen

Was der Schutz vor versehentlichem Entfernen von AD-OUs bewirkt

Der Schutz vor versehentlichem Entfernen von AD-OUs ist eine Sicherheitsmaßnahme, die vor einer Verzeichnisbereinigung geprüft werden sollte. Eine Organisationseinheit kann Identitäten enthalten und Teil einer administrativen Hierarchie sein, von der andere Teams abhängen. Bevor Sie diese Hierarchie entfernen oder neu ordnen, klären Sie, welche OUs bestehen bleiben sollen, wer die Entscheidung verantwortet und ob die tatsächlichen Verzeichnisberechtigungen den vorgesehenen Schutz bieten.

Microsoft beschreibt in der Referenz zu Set-ADOrganizationalUnit ProtectedFromAccidentalDeletion als boolesche Eigenschaft: Ist sie true, kann das Objekt erst gelöscht werden, nachdem die Eigenschaft geändert wurde. Es handelt sich um eine Absicherung durch Berechtigungen, nicht um eine unveränderliche Sperre. Auch Administratoren, die den Schutz entfernen können, benötigen eine geprüfte betriebliche Entscheidung.

Diese Anleitung wurde am 4. Oktober 2026 anhand von Microsoft Learn und dem unten angegebenen Collector-Quellcode geprüft. Alle Befehle sind dokumentarische Beispiele für Leser, keine in einer Kundendomäne ausgeführten Vorgänge. Hier wird weder eine Löschung noch eine Wiederherstellung oder eine erfolgreiche Schutzprüfung behauptet.

Funktionsweise: Berechtigungen, Standardwerte bei der Erstellung und Wiederherstellung

Der Schutz wird durch Deny-Berechtigungen dargestellt

Der Schutz verwendet zwei Deny-Berechtigungen für Everyone, identifiziert durch die SID S-1-1-0: Delete und Delete Subtree. Microsoft beschreibt in der Anleitung zur Vermeidung versehentlicher Löschungen Deny-ACEs für DELETE und DELETE TREE auf dem Objekt. Die Anleitung beschreibt außerdem eine ergänzende Verweigerung von DELETE CHILD auf dem übergeordneten Objekt. Prüfen Sie das Objekt und sein übergeordnetes Objekt, wenn das Berechtigungsverhalten unklar ist; setzen Sie eine einzelne passende ACE nicht mit einer vollständigen Bewertung der effektiven Berechtigungen gleich.

Aktivieren Sie in Active Directory Users and Computers die erweiterten Funktionen, um die Registerkarte „Objekt“ und das Kontrollkästchen für den Schutz sichtbar zu machen. Prüfen Sie bei einer Berechtigungsüberprüfung die erweiterten Einträge der Registerkarte „Sicherheit“, ihren Berechtigungsempfänger, die verweigerten Rechte und den Geltungsbereich. Die oben zitierte Präventionsanleitung dokumentiert das Kontrollkästchen und das zugrunde liegende Berechtigungsmodell. Halten Sie die relevanten Einträge fest, statt sich allein auf einen Screenshot eines aktivierten Kontrollkästchens zu verlassen.

Dieser Unterschied ist beim Vergleich von Werkzeugen relevant. Eine erweiterte Eigenschaft liefert eine administrative Sicht auf den Schutz, während ein Detektor möglicherweise nur einen Teil der Berechtigungsdarstellungen erkennt. Eine ACL-Prüfung muss auch das übergeordnete Objekt und den Geltungsbereich jedes Eintrags berücksichtigen. Stimmen diese Beobachtungen nicht überein, dokumentieren und untersuchen Sie die Abweichung, bevor Sie Berechtigungen ändern.

Ein geschützter Standardwert bei der Erstellung prüft keine bestehenden OUs

Beispiel 1 von New-ADOrganizationalUnit erstellt eine geschützte OU, ohne den Schutzparameter ausdrücklich zu setzen. Beispiel 2 erstellt mit $False ausdrücklich eine ungeschützte OU. Ein aktueller Standardwert bei der Erstellung belegt daher nicht den Zustand älterer, migrierter oder nachträglich geänderter OUs. Ihr Schutz kann abweichen und muss ausgelesen werden.

Unsere Anleitung zu Standardcontainern und Umleitung nutzt diesen impliziten Schutz beim Erstellen von Ziel-OUs für redircmp und redirusr. Sie behandelt die Platzierung und den Geltungsbereich von Gruppenrichtlinien. Die Prüfung der Löschabsicherung einer bestehenden OU ist eine separate Aufgabe; das Erstellungsbeispiel liefert weder eine Bestandsaufnahme noch eine Freigabe für eine Bereinigung.

Prävention und Wiederherstellung beantworten unterschiedliche Fragen

Der Schutz soll einen versehentlichen Vorgang verhindern. Sicherungen und Objektwiederherstellung behandeln dagegen die Folgen eines Datenverlusts. Microsoft erklärt in der Anleitung zu Recycle Bin, dass diese Funktion nur Objekte wiederherstellen kann, die nach ihrer Aktivierung gelöscht wurden. Prüfen Sie den tatsächlichen Funktionsstatus und die Wiederherstellungsvorbereitung gesondert.

Unsere Anleitung zur Wiederherstellung der Active Directory-Gesamtstruktur und zur Validierung von Sicherungen erklärt die Auswahl von Sicherungen, Wiederherstellungsnachweise und die Grenzen von Recycle Bin. Nutzen Sie sie für die ergänzende Prüfung der Wiederherstellung. Weder eine geschützte OU noch ein verfügbarer Recycle Bin beweist, dass eine Gesamtstrukturwiederherstellung validiert wurde. Ebenso rechtfertigt eine vorbereitete Wiederherstellung nicht, eine produktive OU ohne akzeptierte Ausnahme ungeschützt zu lassen.

Erkennung: Bestand unabhängig erfassen und DACL auslesen

1. Eine erfolgreiche Erfassung mit festgelegtem Umfang sicherstellen

Verwenden Sie einen autorisierten Administrationsrechner mit dem Active Directory PowerShell-Modul. Dokumentieren Sie Domäne, abgefragten Server, Erfassungszeit, Anmeldekontext und Suchumfang. Eine fehlgeschlagene oder unvollständige Abfrage gehört als ungelöstes Erfassungsproblem in den Nachweis. Klassifizieren Sie ein nicht lesbares Objekt nicht als ungeschützt und interpretieren Sie ein leeres Ergebnis nicht als abgeschlossene Bestandsaufnahme.

Das folgende Beispiel für Leser verwendet die dokumentierten Parameter Filter und Properties von Get-ADOrganizationalUnit. Es fordert die erweiterte Eigenschaft ausdrücklich an:

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Wählen Sie die vorgesehene Domäne und den Server, statt stillschweigend die Standardwerte eines Administrationsrechners zu übernehmen. Learn dokumentiert auch Server, SearchBase und SearchScope zur Festlegung dieses Kontexts. Der obige Befehl ist ein Ausgangspunkt für die Bestandsaufnahme, keine Garantie für die Vollständigkeit in der gesamten Gesamtstruktur und keine Aufforderung, jedes Ergebnis zu ändern.

Bewahren Sie für jede erfolgreich ausgelesene OU ihren Distinguished Name und ihre Objekt-GUID zusammen mit dem Eigenschaftswert auf. Ergänzen Sie das verantwortliche Fach- oder Infrastrukturteam, den vorgesehenen Zweck und jede vorgeschlagene Bereinigungsentscheidung. Das verantwortliche Team ist eine Grundlage für die Prüfung; nehmen Sie nicht an, dass ein Attribut oder ein OU-Name belegt, wer eine Löschung freigeben darf.

2. Die Berechtigungen unabhängig vom Collector auslesen

Für ein bestimmtes Objekt fordert das nächste Beispiel sowohl die Schutzeigenschaft als auch den Sicherheitsdeskriptor über denselben dokumentierten Mechanismus Properties an. Der Fabrikam-DN ist ein fiktiver Platzhalter, der durch das geprüfte Ziel zu ersetzen ist:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Prüfen Sie die DACL des zurückgegebenen Sicherheitsdeskriptors mit einem autorisierten Werkzeug zur Verzeichnisadministration oder verwenden Sie die erweiterte Sicherheitsansicht in Active Directory Users and Computers. Bestätigen Sie Everyone anhand seiner SID, statt sich auf einen lokalisierten Anzeigenamen zu verlassen. Untersuchen Sie die Verweigerungen für Delete und Delete Subtree, ob sie auf das Objekt angewendet werden, sowie relevante Berechtigungen des übergeordneten Objekts. Bewahren Sie die unveränderten oder exportierten Berechtigungsnachweise auf, sofern sie verfügbar sind.

Diese unabhängige Abfrage muss Deny-Einträge erhalten. Die Wiederverwendung der gefilterten ACL-Liste des Collectors reproduziert genau die untersuchte Einschränkung. Schlägt der Zugriff auf den Deskriptor fehl, dokumentieren Sie den Fehler und beschaffen Sie die erforderlichen Leserechte über den normalen Administrationsprozess. Ein Eigenschaftswert und eine fehlgeschlagene DACL-Abfrage müssen unterscheidbar bleiben.

3. Findings mit den Verzeichnisnachweisen abgleichen

Vergleichen Sie den Collector-Bestand mit dem erfolgreich ausgelesenen administrativen Bestand. Verwenden Sie Objektkennungen und tatsächliche DNs, um Abweichungen zu untersuchen. Ein Unterschied in Schreibweise oder Groß-/Kleinschreibung sollte einen Abgleich auslösen, statt zu der Entscheidung zu führen, dass zwei Datensätze zwangsläufig unterschiedliche Objekte beschreiben. Bewahren Sie die ursprünglichen Werte auf, damit die Suche des Collectors mit Beachtung der Groß-/Kleinschreibung erklärt werden kann.

Ein Finding liefert weder einen Angriffsverlauf noch einen Löschungsverlauf. Leiten Sie aus diesem Konfigurationssignal keine Kompromittierung, böswillige Absicht oder einen abgeschlossenen Vorfall ab. Hat tatsächlich eine Löschung stattgefunden, benötigen ihre Untersuchung und die Wiederherstellung separate Nachweise.

Abhilfe: Ausgewählte OUs schützen und Bereinigungsausnahmen begrenzen (Remediation)

1. Den Sollzustand mit dem Verantwortlichen festlegen

Beginnen Sie mit dem abgeglichenen Bestand. Identifizieren Sie produktive OUs, die erhalten bleiben sollen, Staging-Hierarchien, Migrationsausnahmen und zur Entfernung vorgeschlagene Objekte. Lassen Sie das verantwortliche Team Abhängigkeiten und die genauen Objekte bestätigen, die von der Änderung erfasst werden. Eine scheinbar leere OU ist für sich genommen kein freigegebener Bereinigungsauftrag.

Dokumentieren Sie die aktuellen Nachweise zu Eigenschaft und DACL, den Entscheidungsverantwortlichen, die Zielkennung, den Sollzustand und die Prüfmethode. Prüfen Sie, wer die relevanten Berechtigungen ändern kann. Der Schutz ersetzt weder diese administrative Prüfung noch eine nutzbare Sicherung oder einen Plan zur Objektwiederherstellung. Bleiben Erfassung oder Zuständigkeit unklar, halten Sie den Punkt offen, statt Unsicherheit in eine Massenänderung umzuwandeln.

2. Schutz für eine freigegebene OU aktivieren, die erhalten bleibt

Dieses Beispiel für Leser verwendet die dokumentierten Parameter Identity und ProtectedFromAccidentalDeletion von Set-ADOrganizationalUnit und setzt den booleschen Wert für ein fiktives Ziel auf true. Es ist ein Beispiel für eine gezielte Änderung, keine Empfehlung, den gesamten Bestand in eine Änderung weiterzuleiten:

Set-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -ProtectedFromAccidentalDeletion $True

Wenden Sie die Änderung über den autorisierten Administrationsablauf nur auf das geprüfte Objekt an. Speichern Sie jeden Fehler und das tatsächliche Ergebnis des Vorgangs. Die Anforderung, einen Wert zu setzen, ist ein anderer Nachweis als eine erfolgreiche Aktualisierung des Verzeichnisses. Schlägt eine Änderung fehl, untersuchen Sie Zugriff und Zielkontext, bevor Sie den Vorgang wiederholen oder Berechtigungen erweitern.

3. Das Objekt und seine relevanten Berechtigungen erneut auslesen

Rufen Sie das Ziel nach einer erfolgreichen Änderung erneut unabhängig ab:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Bestätigen Sie die Eigenschaft und prüfen Sie die DACL im dokumentierten Erfassungskontext. Bewahren Sie Vorher-/Nachher-Nachweise und verbleibende Abweichungen auf. Gehört ein anderer Server zum Prüfplan, dokumentieren Sie diese separate Abfrage, statt anzunehmen, dass alle Verzeichnisansichten bereits identisch sind. Schließen Sie die Änderung nur anhand der vorgesehenen Abnahmenachweise ab.

Versuchen Sie keine produktive Löschung, um die Wirksamkeit des Schutzes zu demonstrieren. Diese Anleitung verlangt ein erfolgreiches erneutes Auslesen und eine Berechtigungsprüfung; sie schreibt keinen destruktiven Test vor. Ein unveränderter Collector-Zähler reicht angesichts des unten beschriebenen Provider-Defekts ebenfalls nicht aus, um diese Änderung als erfolglos zu erklären.

4. Die Entfernung des Schutzes auf den freigegebenen Vorgang begrenzen

Microsofts Set-Referenz enthält ein Beispiel mit $false zum Entfernen des Schutzes. Eine solche Änderung gehört ausschließlich zu einer separat freigegebenen Bereinigungs- oder Migrationsentscheidung. Dokumentieren Sie das genaue Ziel, den Grund, die ausführende Person und den Zeitraum der Ausnahme. Entfernen Sie nicht die Schutzmaßnahmen einer ganzen Hierarchie, nur um einen einzelnen Vorgang zu vereinfachen.

Wenden Sie nach den freigegebenen Arbeiten den Schutz erneut auf erhaltene Objekte an, die vorübergehend ausgenommen waren, und wiederholen Sie die Prüfung von Eigenschaft und DACL. Wurde das Objekt absichtlich gelöscht, bewahren Sie die Freigabe und die Vorgangsnachweise auf; es gibt kein verbleibendes Objekt, das erneut geschützt werden könnte. Eine abgebrochene oder fehlgeschlagene Bereinigung darf erhaltene OUs nicht stillschweigend ohne den vorgesehenen Schutz zurücklassen.

Wie EtcSec dies erkennt

Die geprüfte Prüfung von etc-collector ist OU_UNPROTECTED in public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. Detektor und LDAP-Provider wurden am Commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c gelesen; dasselbe relevante Verhalten wurde auch am Collector-HEAD 42bfefbace3189588e76ff291c39e100c6a603a0 untersucht.

Der Detektor erstellt aus den bereitgestellten ACL-Einträgen eine Menge geschützter Objekt-DNs. Ein Eintrag qualifiziert sich nur, wenn sein Typ dem exakten Typnamen ACCESS_DENIED entspricht, sein Berechtigungsempfänger S-1-1-0 ist und seine Zugriffsmaske DELETE (0x10000) enthält. Der Typnamenvergleich verwendet strings.EqualFold, sodass die Groß-/Kleinschreibung für diesen Vergleich ignoriert wird; ACCESS_DENIED_OBJECT ist ein anderer Typ und qualifiziert sich nicht.

Anschließend sucht er jede erfasste ou.DN anhand des Zeichenfolgenschlüssels ObjectDN in dieser Menge. Dieser DN-Abgleich beachtet die Groß-/Kleinschreibung. Nicht gefundene OUs tragen zum Count eines einzelnen Findings mit Schweregrad Low bei. Das Finding wird auch bei Zählerstand null zurückgegeben; betroffene OU-Entitäten werden nur hinzugefügt, wenn Details angefordert werden und der Zähler positiv ist.

Trotz des weiter gefassten Kommentars zu Delete und Delete Subtree prüft das Prädikat DELETE_TREE (0x40) nicht. Es prüft auch weder DELETE CHILD auf dem übergeordneten Objekt noch ACE-Geltungsbereichsflags oder effektive Löschrechte. Eine qualifizierende Delete-Verweigerung reicht für seine Menge geschützter Objekte aus, sodass das Detektorprädikat allein den vollständigen Schutz nicht validieren kann.

Der Provider verhindert auf diesem geprüften Pfad eine zuverlässige Erkennung über die gesamte Verarbeitungskette. In public/internal/providers/ldap/acl_parser.go:276 behält parseACE nur Allow-ACEs. Die Zeilen 297–300 geben für andere Typen als ACCESS_ALLOWED und ACCESS_ALLOWED_OBJECT nil zurück und entfernen damit die Deny-ACEs, die dieser Detektor erwartet. Mit dieser gefilterten Eingabe kann seine Menge geschützter Objekte leer bleiben und der Zähler alle erfassten OUs einschließen, einschließlich tatsächlich geschützter OUs.

Dies ist eine Erfassungseinschränkung, die eine unabhängige Prüfung der Eigenschaft und der DACL erfordert, keine zuverlässige Messung fehlenden Schutzes. Die Korrektur des Providers liegt beim Collector-Team und außerhalb des Umfangs dieses Artikels. Weder eine erfolgreiche Erkennung über die gesamte Verarbeitungskette noch ein Kundenzählerstand wird behauptet.