Wenn ein Administrator ein Objekt im AD löscht, sollte er das bewusst tun und ein versehentliches löschen sollte nie vorkommen. Jedoch passieren die meisten Missgeschicke gerade im Alltag versehentlich, obwohl die Microsoft Werkzeuge (z.B. die MMCs Active Directory-Benutzer und -Computer sowie Active Directory-Standorte und -Dienste, dsrm, AD-PowerShell etc.) eine Sicherheitsabfrage stellen, ob man das Objekt auch wirklich löschen möchte. Handelt es sich bei dem zu löschenden Objekt um eine OU in dem weitere Objekte enthalten sind (Benutzer, Gruppen, OUs etc.), wird sogar noch eine weitere Sicherheitsabfrage gestellt.
Ein Objekt vor dem versehentlichen Löschen schützen
Damit ein Objekt nicht ausversehen gelöscht werden kann, sollte man ab Windows Server 2008 von der Option Objekt vor zufälligem Löschen schützen (auf Englisch: Protect object from accidental deletion) regen Gebrauch machen. Es ist empfehlenswert diesen Schutz mindestens auf OU-Ebene anzuwenden, sie vererbt sich aber nicht auf die untergeordneten Objekte wie z.B. auf untergeordnete OUs oder auf Benutzer-, Gruppen oder Computerobjekte die sich innerhalb der OU befinden. Einzelne Objekte wie Benutzerobjekte, Sicherheits- sowie Verteilergruppen- und Computerobjekte lassen sich ebenfalls vor dem versehentlichen Löschen schützen. Auch die Objekte in der MMC Active Directory-Standorte und -Dienste (AD-Standorte, Subnetze) lassen sich vor dem versehentlichen Löschen schützen.
Die Option Objekt vor zufälligem Löschen schützen lässt sich in den Eigenschaften eines Objekts im Reiter „Objekt“ aktivieren. Dieser Reiter kommt aber in der MMC „Active Directory-Benutzer und -Computer“ erst dann zum Vorschein, wenn unter „Ansicht“ die Option „Erweiterte Features“ aktiviert wurde.
Unter Windows 2000 und Windows Server 2003 existiert zwar die Möglichkeit zum aktivieren der Option „Objekt vor zufälligem Löschen schützen“ nicht, doch man kann natürlich auch unter Windows 2000 und Windows Server 2003 ein Objekt vor dem versehentlichen löschen schützen. Denn das aktivieren der Option „Objekt vor zufälligem Löschen schützen“ bewirkt nichts anderes, als das im Security-Descriptor des Objekts das “Verweigerungsrecht” zum “Löschen” für “Jeder” gesetzt wird. Genau das kann man auch unter Windows 2000 und Windows Server 2003 z.B. auf einer OU oder einem Benutzerobjekt konfigurieren.
Mit DSACLS, das sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools befindet und ab Windows Server 2008 „on Bord“ ist, lässt sich eine OU folgendermaßen vor dem versehentlichen Löschen schützen:
Dsacls „<DN der OU>“ /D Jeder:SDDT
In der Kommandozeile (CMD) lässt sich mit einer FOR-Schleife und den ds*-Tools die ab Windows Server 2003 “on Bord” sind, eine OU samt den untergeordneten OUs vor dem versehentlichen Löschen wie folgt schützen. Die Objekte wie z.B. Benutzer-, Gruppen- oder Computerobjekte die sich innerhalb dieser OUs befinden, werden dabei aber nicht vor dem versehentlichen Löschen geschützt:
FOR /F “tokens=*” %i in (‘Dsquery OU “<DN der OU>” -Limit 0′) do Dsacls %i /D “Jeder:SDDCDT”
Alle OUs innerhalb einer Domäne lassen sich in einer CMD mit dieser FOR-Schleife vor dem versehentlichen Löschen schützen:
FOR /F “tokens=*” %i in (‘Dsquery OU -Limit 0′) do Dsacls %i /D “Jeder:SDDCDT”
Über die AD-Powershell lässt sich diese Option auf einer OU wie folgt aktivieren:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion 1
bzw.
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $true
Auf allen bestehenden OUs lässt sich die Option wie folgt aktivieren:
Get-ADOrganizationalUnit -Filter * | Set-ADOrganizationalUnit –ProtectedFromAccidentalDeletion 1
Deaktivieren lässt sich die Option „Objekt vor zufälligem Löschen schützen“ in der AD-PowerShell wie folgt:
Set-ADOrganizationalUnit „<DN der OU>“ –ProtectedFromAccidentalDeletion 0
oder
Set-ADOrganizationalUnit „<DN der OU>“ -ProtectedFromAccidentalDeletion $false
Wird eine bestehende Domäne auf mindestens „Windows Server 2008“ aktualisiert, wird bei bestehenden Objekten diese Option nicht automatisch aktiviert. Auch nach dem installieren einer neuen Windows Server 2008 Domäne ist auf den bestehenden Objekten die Option „Objekt vor zufälligem Löschen schützen“ nicht aktiv. Der Schutz ist standardmäßig nur beim erstellen von neuen OUs ab Windows Server 2008 aktiviert, nicht jedoch beim erstellen von Benutzer-, Gruppen- oder Computerkonten bzw. AD-Standorten und Subnetzen.
Ist hingegen dieser Schutz auf einer OU aktiviert und man möchte diese OU verschieben, erhält man folgende Fehlermeldung. Denn zum Verschieben einer OU benötigt man das Löschrecht am Quell- und Schreibrecht am Zielort. Das Verschieben der OU ist erst dann möglich, wenn die Option deaktiviert wurde.
Das gilt natürlich auch beim löschen einer OU. Erst wenn die Option deaktiviert ist, kann die OU nach bestätigen der Sicherheitsabfrage gelöscht werden. Spätestens mit dieser Option gehört das versehentliche Löschen eines Objekts endlich der Vergangenheit an.
Wer hat den Benutzer gelöscht?
Wenn nun doch mal ausversehen z.B. das Benutzerobjekt des GFs gelöscht wurde, möchte man evtl. aufklären wer das Benutzerobjekt auf welchem DC gelöscht hat. Im Sicherheitsprotokoll des DCs auf dem das Objekt gelöscht wurde, wird unter Windows Server 2003 die EventID 630 und unter Windows Server 2008 sowie Windows Server 2008 R2 die EventID 4726 protokolliert. Denn standardmäßig wird unter Windows Server 2003 und Windows Server 2008 R2 beim Löschen eines Benutzerkontos ein Eventlogeintrag generiert, nicht jedoch unter Windows Server 2008.
Unter Windows Server 2008 muss zuerst die Unterkategorie Verzeichnisdienständerungen mit der Option Erfolgreich durch den folgenden Befehl aktiviert werden:
Auditpol /set /subcategory:Verzeichnisdienständerungen /success:enable
Erst danach wird das Löschen eines Objekts auch unter Windows Server 2008 protokolliert.
Active Directory Domain Services (AD DS) – Protokollierung
Achtung: Eine Protokollierung ist vom Betriebsrat bzw. Datenschutzbeauftragten zu genehmigen!
Die Information auf welchem DC das Objekt gelöscht wurde, wird aber nicht zwischen den DCs repliziert. Die Aufgabe besteht also darin, herauszufinden wann das Benutzerkonto auf welchem DC gelöscht wurde, um anschließend den Eventlogeintrag ausfindig zu machen. Sofern der Eventlogeintrag natürlich noch auf dem betroffenen DC existiert und nicht überschrieben wurde.
Auch das Löschen von Gruppen wird standardmäßig mit folgenden EventIDs protokolliert:
Unter Windows Server 2003
- Domänenlokale Sicherheitsgruppe = EventID 638
- Globale Sicherheitsgruppe = EventID 634
- Universelle Sicherheitsgruppe = EventID 662
- Domänenlokale Verteilergruppe = EventID 652
- Globale Verteilergruppe = EventID 657
- Universelle Verteilergruppe = EventID 667
Unter Windows Server 2008 und Windows Server 2008 R2
- Domänenlokale Sicherheitsgruppe = EventID 4734
- Globale Sicherheitsgruppe = EventID 4730
- Universelle Sicherheitsgruppe = EventID 4758
In kleineren AD-Umgebungen lassen sich die Eventlogs auf den DCs vielleicht noch schnell und vor allem manuell durchforsten, doch in großen bzw. weltweiten AD-Umgebungen ist das schier eine unmögliche Aufgabe. Zumindest nicht ohne Zusatzwerkzeuge wie z.B. SCOM, Log Parser oder EventComb.
Doch es gibt auch eine einfache Methode, um den Übeltäter ausfindig zu machen. Mit Hilfe von LDP und REPADMIN kann man in Erfahrung bringen, auf welchem DC das Objekt wann zu welcher Uhrzeit gelöscht wurde. Anschließend öffnet man das Sicherheitsprotokoll des betroffenen DCs und kann anschließend in der Beschreibung des Eventlogeintrags erkennen, wer das Objekt gelöscht hat. Es spielt auch keine Rolle ob unter Windows Server 2008 R2 der AD-Papierkorb aktiviert ist oder nicht.
Dazu sind die folgenden Schritte notwendig.
In LDP
Mit LDP gilt es zuerst herauszufinden, wie der Distinguished Name (DN) des gelöschten Objekts im Deleted Objects Container das sich in der Domänenpartition befindet lautet.
- Im ersten Schritt verbindet man sich mit einem DC aus der Domäne, in der das Objekt gelöscht wurde. Unter Windows 2000 und Windows Server 2003 wählt man im Menü „Connection – Connect…“ und unter Windows Server 2008 sowie Windows Sever 2008 R2 „Remotedesktopverbindung – Verbinden…“ und gibt den DC an, mit dem man sich verbinden möchte.
- Im zweiten Schritt binded man sich mit dem AD. Unter Windows 2000 und Windows Server 2003 wählt man dazu im Menü „Connection – Bind“ und unter Windows Server 2008 und Windows Server 2008 R2 „Remotedesktopverbindung – Gebunden…“.
- Danach wählt man im Menü unter Windows 2000 und Windows Server 2003 „Options – Controls“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Optionen – Steuerelemente“. Im darauf erscheinenden Fenster „Controls“ bzw. „Steuerelemente” fügt man das LDAP-Control „Return deleted objects“ mit der OID (Object Identifier) 1.2.840.113556.1.4.417 hinzu.
Als nächstes ruft man unter Windows 2000 und Windows Server 2003 im Menü „Browse – Search“ sowie unter Windows Server 2008 und Windows Server 2008 R2 „Durchsuchen – Suchen“ das Suchfenster auf. Dort gibt man als Basis-DN den „Deleted Objects“ Container in der Domänenpartition an. Dieser lautet: CN=Deleted Objects,DC=<Domäne>,DC=<de>
Im Feld Filter gibt man die Kriterien an, nach denen man die Suche im Container “Deleted Objects” durchführen möchte. Ist der Benutzeranmeldename (Prä-Windows 2000), also das Attribut sAMAccountName bekannt, trägt man in dem Feld sAMAccountName=<Benutzeranmeldename> ein. Es kann natürlich auch ein anderes Attribut angegeben werden, dass das gewünschte Benutzerobjekt identifiziert.
Als Scope/Bereich wählt man OneLevel/Eine Ebene aus. Wählt man als Suchbereich Subtree/Unterstruktur aus, funktioniert das ebenfalls.
Unter Windows Server 2008 und Windows Server 2008 R2 gibt man im Feld „Attribute“ die Attribute an, die in der rechten Hälfte von LDP, im Suchergebnis zusätzlich zum DN angezeigt werden sollen. Gibt man keine Attribute an, werden alle Attribute des gelöschten Objekts angezeigt.
- Anschließend ruft man mit einem Klick auf Optionen die Suchoptionen auf und konfiguriert die Einstellungen wie folgt. Mit einem Klick auf OK übernimmt man die vorgenommenen Einstellungen.
- Unter Windows 2000 und Windows Server 2003 muss man vorher auf Options klicken, um die gewünschten Attribute und die weiteren Einstellungen vornehmen zu können.
Führt man die Suche nun mit einem Klick auf Run/Ausführen aus, erscheint in der rechten Hälfte von LDP unter anderem der gesuchte DN des gelöschten Benutzerobjekts. Dieser sieht z.B. so aus:
Dn: CN=Yusuf Dikmenoglu\0ADEL:3e9e243e-8ba9-473a-a1ee-f1b001337923,CN=Deleted Objects,DC=ad2008R2,DC=dikmenoglu,DC=de
In REPADMIN
Da nun bekannt ist wie der DN des gelöschten Benutzerobjekts lautet, gilt es auf einem DC in der Domäne in der das Benutzerobjekt gelöscht wurde, den folgenden REPADMIN-Befehl in der Kommandozeile auszuführen. Die Ausgabe von REPADMIN wird zur besseren Übersicht in eine Textdatei exportiert.
Repadmin /showobjmeta <DC> “CN=Yusuf Dikmenoglu\0ADEL:2ffa7423-7b00-4962-96f6-69d052e08c51,CN=Deleted Objects,DC=ad2008r2,DC=dikmenoglu,DC=de” > C:\Repadmin.txt
Entscheidend in der Ausgabe ist das Attribut isDeleted.
Daraus kann man erkennen, dass das Benutzerobjekt am 14.11.2009 um 23:05:08 Uhr auf dem DC R2DCON01 gelöscht wurde. Nun kann man hoffen, dass auf dem DC der erwähnte Zeitpunkt im Sicherheitsprotokoll noch nicht überschrieben wurde. Wenn der Eintrag noch existiert, findet man in der Beschreibung des Eventlogeintrags den Übeltäter.
Weitere Informationen:
Der Container Deleted Objects
Repadmin /showobjmeta
Comments are closed, but trackbacks and pingbacks are open.