Endlich wird es in Zukunft auch einen Best Practice Analyzer (BPA) für die Active Directory Domain Services (kurz AD DS-BPA) geben. Der BPA der bereits seit längerem für verschiedene Microsoft Produkte existiert (Siehe Abschnitt „Weitere BPAs“), ist für viele Administratoren ein unverzichtbares Werkzeug. Denn mit dem BPA lassen sich Konfigurationsprobleme schnell und einfach aufspüren.
Der BPA für die AD DS-Rolle wird erstmals im Windows Server 2008 R2 eingeführt und hilft dem Administrator dabei, Best Practices bei der Konfiguration der AD DS-Umgebung zu implementieren. Ein oder mehrere DCs lassen sich gegen eine Reihe von vordefinierten Best Practices überprüfen. Der AD DS-BPA erstattet nach der Durchführung Bericht, ob der DC mit den Best Practices kompatibel oder nicht konform ist.
Wenn die AD DS-Umgebung installiert und alles Notwendige konfiguriert wurde, ist es empfehlenswert die durchgeführten Konfigurationen anschließend auf Fehler zu überprüfen. Doch dies ohne den AD DS-BPA zu verifizieren ist gar nicht so einfach und dauert unter Umständen viele Stunden. Aber mit dem neuen AD DS-BPA lassen sich schnell und einfach Konfigurationsfehler und Schwachstellen in der AD DS-Umgebung auf Knopfdruck aufspüren.
Der AD DS-BPA lässt sich zum einen über die grafische Oberfläche und zum anderen, über die Powershell-Kommandozeile ausführen. In der grafischen Oberfläche befindet sich der AD DS-BPA ausschließlich im Server Manager des Windows Server 2008 R2. Der Server Manager ist erstmals auch in den RSAT für den Windows 7 Client enthalten.
Der BPA scannt die AD DS-Rolle so wie sie auf dem Windows Server 2008 R2 DC konfiguriert ist. Nach der Durchführung werden im Server Manager in den Reitern „Nicht Kompatibel“ und „Kompatibel“ die Ergebnisse angezeigt. Ein Ergebnis kann dabei als „Schweregrad“ Fehler, Warnung oder Kompatibel enthalten.
Bei Fehlern die im Reiter „Nicht Kompatibel“ angezeigt werden und somit gegen die „Best Practices“ verstoßen (wenn z.B. kein DNS-Server für die Domäne erreichbar ist), werden in der Beschreibung die Punkte „Problem“, „Auswirkung“ und „Lösung“ angezeigt. Durch die genauen Angaben erfährt man, welche Auswirkung das gefundene Problem hat und vor allem, wie es sich lösen lässt.
Die Ergebnisse können gefiltert werden, indem einzelne Berichte für die zukünftigen Durchführungen des BPA vorübergehend ausgeschlossen und zu einem späteren Zeitpunkt erneut einbezogen werden.
Im AD DS-Umfeld steht der BPA unter Windows Server 2008 R2 vorerst für die folgenden Rollen zur Verfügung:
- Active Directory Certificate Services
- Active Directory Domain Services
- DNS Server
Der BPA wird über die “Windows Updates” stetig verbessert und erweitert.
Was ist möglich?
- Der AD DS-BPA lässt sich über den Server Manager oder über die Powershell, nur auf Windows Server 2008 R2 DCs ausführen.
- Der AD DS-BPA kann über den Server Manager oder über die Powershell lokal und remote auf einem Windows Server 2008 R2 Vollinstallation, Windows Server 2008 R2 RODC und Windows Server 2008 R2 Core ausgeführt werden.
- Auf einem Windows Server 2008 R2 Core kann lokal der AD DS-BPA ausschließlich über die Powershell ausgeführt werden, da der Server Manager in der grafischen Oberfläche auf einem Windows Server 2008 R2 Core nicht existiert.
- Von einem Windows 7 Client worauf das RSAT (Remote Server Administration Tools) installiert ist, kann der AD DS-BPA über den Server Manager oder über die Powershell remote auf einem Windows Server 2008 R2 Vollinstallation oder Windows Server 2008 R2 Core ausgeführt werden.
- Nur über die Powershell können mehrere Rollen zur gleichen Zeit überprüft werden (z.B. die AD DS- und DNS-Rolle).
Was ist nicht möglich?
- Der Server Manager vom Windows Server 2008 R2, worin sich der AD DS-BPA befindet, lässt sich nicht auf Windows 2000, Windows Server 2003/2003 R2 oder Windows Server 2008 installieren.
- Der AD DS-BPA lässt sich nicht über den Server Manager remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
- Der AD DS-BPA lässt sich nicht über die Powershell remote auf einen Windows 2000 DC, Windows Server 2003/2003 R2 DC und Windows Server 2008 DC ausführen.
Wie wird der AD DS-BPA im Server Manager installiert?
Sobald auf einem Windows Server 2008 R2 Vollinstallation die AD DS-Rolle installiert und dieser zum Domänencontroller gestuft wird, steht der AD DS-BPA automatisch im Server Manager zur Verfügung. Es ist auch nicht notwendig weitere Komponenten zu installieren um den AD DS-BPA zu nutzen.
Auf einem Windows Server 2008 R2 Core kann der AD DS-BPA lokal ausschließlich über die Powershell ausgeführt werden.
Die Bestandteile des AD DS-BPA
Der Server-Manager im Windows Server 2008 R2 beinhaltet eine Engine mit dem der AD DS-BPA ausgeführt wird. Dabei besteht der AD DS-BPA aus den folgenden Komponenten:
- AD DS-BPA PowerShell Skript: Das Skript sammelt AD DS-Konfigurationsdaten und speichert sie in ein XML-Dokument.
- XML-Schema: Das Schema definiert das Format des XML-Dokuments, das vom AD DS-BPA PowerShell Skript erzeugt wurde.
- AD DS-BPA Regeln: Die Regeln definieren die Best Practice-Konfiguration einer AD DS Umgebung.
- AD DS-BPA Leitfaden: Diese Informationen helfen dem Administrator ihre AD DS-Umgebung entsprechend den Best Practices zu konfigurieren.
Die Funktionsweise des AD DS-BPA
Wenn der AD DS-BPA auf einem DC ausgeführt wird, werden die folgenden Schritte durchgeführt:
- Die BPA Engine sammelt in der bestehenden AD DS-Umgebung mit dem „AD DS-BPA Powershell Skript“ Informationen über die AD DS-Konfiguration und speichert sie in ein XML-Dokument.
- Danach wird das XML-Dokument gegen das „XML-Schema“ validiert.
- Nach dem Anwenden der „AD DS-BPA Regeln“ auf das XML-Dokument wird anschließend ein Bericht anhand des „AD DS-BPA Leitfaden“ erstellt.
Den AD DS-BPA lokal in der grafischen Oberfläche ausführen
Der AD DS-BPA lässt sich mit der Maus im Server Manager eines Windows Server 2008 R2 DCs Vollinstallation ausführen. Dort findet man ihn nach Auswahl der Rolle Active Directoy-Domänendienste in der Zusammenfassung.
Das Ausführen des AD DS-BPA lokal auf einem Windows Server 2008 R2 DC Vollinstallation, in der AD-Powershell
In der Powershell-Kommandozeile lässt sich der AD DS-BPA ebenfalls ausführen.
- Als erstes gilt es das Server Manager-Modul mit dem folgenden Befehl in die Powershell-Sitzung zu importieren.
Import-Module ServerManager
- Im zweiten Schritt muss das BPA-Modul mit diesem Befehl importiert werden.
Import-Module BestPractices
- Mit diesem Befehl werden alle verfügbaren BPAs aufgelistet.
Get-BPAModel
- Nach der Durchführung des AD DS-BPA werden die Ergebnisse mit diesem Befehl angezeigt.
Get-BPAResult Microsoft/Windows/DirectoryServices
- Die AD DS-Rolle wird mit diesem Befehl überprüft.
Invoke-BPAModel Microsoft/Windows/DirectoryServices
- Einzelne Ergebnisse werden mit diesem Befehl ausgeschlossen bzw. erneut einbezogen.
Set-BPAResult
Den AD DS-BPA remote im Server Manager ausführen
Mit dem Server Manager lässt sich nun auch unter Windows Server 2008 R2 wie es bei MMCs üblich ist, remote eine Verbindung zu anderen Servern aufbauen. Das war vor Windows Server 2008 R2 nicht möglich. Der Server Manager steht unter Windows Server 2008 R2 sowie auf dem Windows 7 Client nach dem Installieren der RSAT zur Verfügung.
Doch bevor man sich mit dem Server Manager zu einem anderen DC verbinden kann, muss der zu verwaltende DC dies vorher zulassen. Das Zulassen für die Remoteverwaltung kann ebenfalls im Server Manager erfolgen. Die notwendigen Einstellungen werden bei aktivierter Windows-Firewall automatisch vorgenommen.
Über die Powershell muss auf dem zu verwaltenden DC zuerst der Befehl set-executionPolicy -executionPolicy remotesigned ausgeführt werden. Alle dazu benötigten Windows-Firewalleinstellungen werden durch diesen Befehl Configure-SMRemoting.ps1 -force -enable vorgenommen.
Anschließend lässt sich die AD DS-Rolle auf einem beschreibbaren Windows Server 2008 R2 DC, Windows Server 2008 R2 RODC oder Windows Server 2008 R2 Core DC von der Ferne aus überprüfen.
Den AD DS-BPA lokal auf einem Windows Server 2008 R2 Core DC ausführen
Ein lokales Ausführen des AD DS-BPA auf einem Windows Server 2008 R2 Core DC ist nur über die Powershell möglich. Die Powershell ist jedoch standardmäßig nicht installiert. Dazu müssen die folgenden Features installiert werden:
-
start /w ocsetup NetFx3-ServerCore
-
start /w ocsetup ServerCore-WOW64
-
start /w ocsetup MicrosoftWindowsPowerShell
-
start /w ocsetup MicrosoftWindowsPowerShell-WOW64
-
start /w ocsetup ActiveDirectory-PowerShell
Achtung: Die Featurenamen sind case sensitive!
Nach der Installation der Features, lässt sich die Powershell aus dem Verzeichnis %windir%\system32\windowspowershell\v1.0 mit dem Befehl powershell aufrufen. Anschließend gilt es die folgenden Powershell-Module zu laden:
- import-module activedirectory
- import-module servermanager
- import-module bestpractices
Überprüfen lässt sich danach die AD DS-Rolle mit diesem Befehl:
Get-WindowsFeature AD-Domain-Services | invoke-bpamodel
Die Ergebnisse nach der Durchführung des AD DS-BPAs lassen sich mit diesem Befehl anzeigen:
Get-WindowsFeature AD-Domain-Services | get-bparesult
Den AD DS-BPA remote auf einem Windows Server 2008 R2 Core DC ausführen
Bevor man den AD DS-BPA von der Ferne aus über den Server Manager oder über die AD-Powershell auf einem Windows Server 2008 R2 Core ausführen kann, muss zuerst auf dem Server Core die Fernadministration erlaubt werden. Mit dem folgenden Befehl werden die entsprechenden Konfigurationen in der Windows-Firewall vorgenommen: winrm quickconfig.
Anschließend kann man mit dem Server Manager oder über die Powershell von einem Windows Server 2008 R2 oder von einem Windows 7 Client (mit installierten RSAT) remote den AD DS-BPA auf einem Windows Server 2008 R2 Core DC ausführen.
Weitere BPAs für verschiedene Microsoft Produkte
Für Gruppenrichtlinien, Exchange, ISA, SQL und einige mehr gibt es den BPA schon seit längerer Zeit.
Immer wieder haben Administratoren Probleme mit dem Kennwort für den Verzeichnisdienstwiederherstellungsmodus. Sie gehen zu leichtfertig und unbedacht mit diesem hochsensiblen Kennwort um und wissen oftmals nicht, für was dieses Kennwort benötigt wird. Sie schreiben sich das Kennwort bei der Vergabe nicht auf und wissen es im Ernstfall nicht mehr. Das man das Kennwort seit Windows 2000 im laufenden Betrieb eines DCs ändern kann, ist ebenfalls vielen unbewusst. Um diesen Zustand bis zu einem gewissen Grad zu mildern sowie zu garantieren, dass das Kennwort konsistent bleibt, hat sich Redmond etwas einfallen lassen.
Microsoft hat ein neues Feature unter Windows Server 2008 veröffentlicht, mit dem das synchronisieren des Kennworts für den Modus „Verzeichnisdienste wiederherstellen" (im englischen „Directory Services Restore Mode“, kurz DSRM) und einem Domänen-Benutzerkonto möglich ist. Diese neue Funktion vermindert oder erhöht keineswegs die Sicherheit des Kennworts. Es dient einzig und alleine dazu, die Verwaltung des Kennworts zu vereinfachen.
Diese Funktion steht aber erst ab Windows Server 2008 und dort erst nach der Installation eines Hotfix zur Verfügung, der vorher von Microsoft von dieser Seite angefordert werden muss. Wurde der Hotfix auf einem Windows Server 2008 DC installiert, ist zwingend ein Neustart erforderlich. Der Hotfix steht ausschließlich für Windows Server 2008 zur Verfügung! Ab dem Service Pack 2 für Windows Server 2008 ist der Hotfix integriert und das installieren des Hotfix' ist nicht notwendig! Ab Windows Server 2008 R2 ist es ohnehin integriert.
Die Synchronisierung des Kennworts für den Verzeichnisdienstwiederherstellungsmodus mit dem Kennwort eines Domänen-Benutzerkontos erfolgt über das Kommandozeilentool NTDSUTIL. Dabei hat jeder DC sein „eigenes“ Kennwort für den Verzeichnisdienstwiederherstellungsmodus, das lokal gespeichert ist.
Nach der Eingabe des folgenden Befehls findet eine einseitige Synchronisation statt. Das Konto für den Verzeichnisdienstwiederherstellungsmodus erhält das Kennwort vom angegebenen Benutzerkonto. Die Vorgehensweise ist wie folgt:
- Unter „Start-Ausführen“ oder in einer Kommandozeile gilt es zuerst das NTDSUTIL aufzurufen.
- Danach ist dieser Befehl einzugeben: set dsrm password
- Anschließend wird die Synchronisierung des Kennworts mit diesem Befehl durchgeführt: sync from domain account <sAMAccountName>
- Mit der zweimaligen Eingabe von q verlässt man das NTDSUTIL.
- Man kann die Synchronisation auch mit dem folgenden Einzeiler erreichen: NTDSUTIL “set dsrm password" "sync from domain account <Benutzer>" q q
Der Befehl kann im laufenden Betrieb ausgeführt werden und das Kennwort wird dann einmalig synchronisiert! Es findet keine permanente Synchronisation statt. Daher muss der Befehl erneut ausgeführt werden, wenn sich das Kennwort vom angegebenen Benutzerkonto geändert hat.
Über die "Group Policy Preferences" und einem "geplanten Task" lässt sich die Synchronisierung des Kenworts auch automatisieren:
DS Restore Mode Password Maintenance
Weitere Informationen:
How to Change the Recovery Console Administrator Password on a Domain Controller
How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003
Active Directory-Domänendienste (AD-DS)
Die Active Directory-Umgebungen in einigen Unternehmen sind bereits auf Windows Server 2008 aktualisiert worden und somit halten auch die ersten Windows Server 2008 RODCs mehr und mehr Einzug in die Domänen.
Bei einer Domänenaktualisierung auf Windows Server 2008 werden bekanntlich alle Infrastrukturdienste automatisch übernommen. Findet jedoch eine Migration in eine neue Domäne statt, müssen alle nötigen Infrastrukturdienste in der Ziel-Domäne installiert werden damit ein reibungsloser Netzwerkbetrieb weiterhin gewährleistet ist. Wird der erste DHCP Server in einer neuen Active Directory Umgebung (bspw. Nach einer Migration) auf einem RODC installiert, werden im Systemprotokoll die Fehlermeldungen 1035 und 1036 protokolliert. Die beiden EventIDs deuten daraufhin, dass die zwei domänenlokalen Sicherheitsgruppen DHCP-Benutzer und DHCP-Administratoren fehlen.
Man hat zwei Möglichkeiten diese beiden Gruppen zu erstellen:
Wenn die DHCP-Rolle allerdings auf einem Mitgliedsserver installiert wird, werden beide Gruppen lokal auf dem Server erstellt und nicht im AD.
Falls die beiden Gruppen händisch im AD erstellt wurden, verursacht das nachträgliche Installieren der DHCP-Rolle auf einem beschreibbaren DC keinen Konflikt.
Anschließend lässt sich der DHCP-Server Dienst ohne Probleme starten.
Weitere Informationen:
DHCP Users Group Configuration
Im Windows Server 2008 R2 ist erstmals die Active Directory-Powershell in der Version 2.0 Out-of-the-Box für AD DS sowie AD LDS (ehemals ADAM) im Betriebssystem integriert. Es stehen die AD-Powershell Kommandozeile sowie das Snap-In Windows PowerShell Integrated Scripting Environment (ISE) zur Verfügung. Die Powershell-Entwicklungsumgebung ISE muss im Server Manager unter den Features installiert werden, ehe diese unter Start - Alle Programme - Zubehör - Windows Powershell genutzt werden kann. Hinter der AD-Powershell verbirgt sich nichts anderes als ein Powershell-Modul Namens „ActiveDirectory“, worin bereits die AD-Cmdlets zur Verfügung stehen. Denn unter der Windows Powershell V2 sowie ISE müssen zuerst die AD-Cmdlets mit dem Befehl import-module activedirectory importiert werden. Die Bestandteile der AD-Powershell ist der AD-Powershell Provider und die insgesamt 76 AD-Powershell Commandlets (kurz Cmdlets).
Vor Windows Server 2008 R2 mussten AD-Administratoren mehrere Kommandozeilentools und AD Snap-Ins verwenden, um ihre Active Directory-Umgebung sowie die AD LDS „configuration sets“ (eine Gruppe von Replikationspartnern) zu administrieren und zu konfigurieren. Diese Vielfalt an Werkzeugen können sie zwar auch unter Windows Server 2008 R2 weiterhin nutzen, doch wer seine AD DS/AD LDS-Umgebung zentralisiert aus nur einem Werkzeug heraus administrieren bzw. konfigurieren möchte, der kann dies mit der Active Directory-Powershell realisieren.
Dadurch lassen sich viele AD-Administrations- und -Konfigurationsaufgaben nun auch über die AD-Powershell ausführen. Doch bevor die AD-Powershell genutzt werden kann, muss diese zuerst installiert werden. Die Installation der AD-Powershell kann ausschließlich auf den Betriebssystemen Windows Server 2008 R2 Vollinstallation, Server Core R2 und Windows 7 Client durchgeführt werden.
Dabei kann die Installation der AD-Powershell auf verschiedene Weise erfolgen. Diese wären:
- Die Installation der Serverrolle AD DS oder AD LDS unter Windows Server 2008 R2.
- Das Heraufstufen eines Windows Server 2008 R2 zu einem Domänencontroller (DC) mit dem Dcpromo-Assistenten.
- Bei der Installation der Remote Server Administration Tools (kurz RSAT) auf einem Windows Server 2008 R2 Servers.
- Mit der Installation der RSAT auf Windows 7 Clients.
Mit der Installation der AD-Powershell werden standardmäßig die Komponenten „Windows Powershell“ und „.NET Framework 3.5.1“ mit installiert. Diese beiden Komponenten sind die Voraussetzung ehe die AD-Powershell installiert und genutzt werden kann.
Wenn die AD-Powershell auf einem Windows 7 Client genutzt werden soll, um eine AD DS-Domäne oder AD LDS-Umgebung zu administrieren, dann ist das erst möglich wenn sich mindestens ein Windows Server 2008 R2 DC oder mindestens eine Instanz in einem AD LDS „configuration set“ auf einem Windows Server 2008 R2 läuft. Das ist notwendig, da die AD-Powershell von dem Dienst Active Directory-Webdienste abhängig ist und nicht von der RPC- bzw. LDAP-Schnittstelle. Nur wenn dieser Dienst in der Umgebung zur Verfügung steht, kann die AD-Powershell eingesetzt werden.
Damit eine Windows Server 2003 oder Windows Server 2008 Umgebung oder AD LDS-Instanzen die auf Windows Server 2008 laufen von einem Windows 7 Client oder Windows Server 2008 R2 Mitgliedsserver bzw. DC administrert werden können, muss vorher das Active Directory Management Gateway Service installiert werden:
Die AD Management Gateway Services für Windows Server 2003 und Windows Server 2008
Nach der Installation der AD-Powershell stehen alle 76 verfügbaren AD-Cmdlets zur Verfügung und man kann sich mit dem Befehl Get-Command *-ad* die Cmdlets anzeigen lassen. Mit den folgenden Powershell-Befehlen lässt sich zu dem jeweils angegebenen AD-Cmdlet eine detailierte und ausführliche Hilfe anzeigen:
- Get-Help <Cmdlet Name> -Detailed (z.B. Get-Help Disable-ADAccount -Detailed)
- Get-Help <Cmdlet Name> -Examples
- Get-Help <Cmdlet Name> -Full
Die Cmdlets lassen sich auch durch das Pipelining miteinander verbinden. Dadurch können die Daten von einem Cmdlet zum anderen weitergegeben werden. Z.B.: Search-ADAccount <Parameter/alle deaktivierten Benutzer> | Enable-ADAccount
Die AD-Cmdlets die zur Verfügung stehen sind:
ADAccount (4 Cmdlets)
-
Disable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Deaktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
-
Enable-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Aktiviert das angegebene Benutzer-, Dienst- oder Computerkonto.
-
Search-ADAccount
Die Suche zeigt Benutzer- oder Computerkonten anhand der angegebenen Parameter an.
-
Unlock-ADAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Entsperrt ein Domänen-Benutzerkonto.
ADAccountAuthorizationGroup
(1 Cmdlet)
- Get-ADAccountAuthorizationGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Zeigt die Sicherheitsgruppen mit detailierten Informationen im AD an, in denen das angegebene Benutzer-, Dienst- oder Computerkonto Mitglied ist. Mit diesem Cmdlet wird auch die „primäre Gruppe“ eines Benutzers angezeigt!
ADAccountControl (1 Cmdlet)
- Set-ADAccountControl (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kontooptionen eines Benutzer- oder Computerkontos bearbeiten. Das Attribut „userAccountControl“ das sich aus einer Bitmaske zusammensetzt, lässt sich somit auch in der AD-Powershell bearbeiten.
ADAccountExpiration (2 Cmdlet)
- Clear-ADAccountExpiration (Dieses Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich in den Eigenschaften eines Benutzerkontos, im Reiter Konto die Option “Konto läuft ab” auf „Nie“ einstellen.
-
Set-ADAccountExpiration (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Ablaufdatum eines Benutzerkontos lässt sich mit diesem Cmdlet konfigurieren.
ADAccountPassword (1 Cmdlet)
- Set-ADAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das Kennwort eines Benutzer- oder Dienstkonto kann mit diesem Cmdlet bearbeitet bzw. ein neues vergeben werden.
ADAccountResultantPasswordReplicationPolicy (1 Cmdlet)
-
Get-ADAccountResultantPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet kann man sich die Kennwortreplikationsrichtlinie eines Benutzer-, Dienst- oder Computerkontos, an dem angegebenen RODC anzeigen lassen.
ADComputer (4 Cmdlet)
- Get-ADComputer (Das Cmdlet funktioniert nicht bei den AD LDS)
Eine Abfrage über Computerkonten anhand bestimmter Kriterien lässt sich mir diesem Cmdlet durchführen.
-
New-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Hiermit können Computerkonten im AD erstellt werden. Darunter fällt auch die neue Funktion „Offline Domain Join“ oder ein RODC-Computerkonto.
-
Remove-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt Computerkonten aus dem AD.
-
Set-ADComputer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die Eigenschaften eines Computerkontos lassen sich mit diesem Cmdlet bearbeiten.
ADComputerServiceAccount (3 Cmdlets)
-
Add-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Computer-Dienstkonten werden mit diesem Cmdlet auf einem Server hinzugefügt.
-
Get-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die auf einem Server verfügbaren Computer-Dienstkonten zeigt dieses Cmdlet an.
-
Remove-ADComputerServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lassen sich ein oder mehrere Computer-Dienstkonten mit diesem Cmdlet.
ADDefaultDomainPasswordPolicy (2 Cmdlets)
- Get-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die Domänen-Kennwortrichtlinie an und nicht die “Password Settings Objects (PSO)”.
- Set-ADDefaultDomainPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lassen sich die Kennwortvorgaben (minimales und maximales Kennwortalter usw.) in der Domänen-Kennwortrichtlinie konfigurieren.
ADDirectoryServer (1 Cmdlet)
-
Move-ADDirectoryServer (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Domänencontroller kann mit diesem Cmdlet an einen anderen AD-Standort verschoben werden.
ADDirectoryServerOperationMasterRole (1 Cmdlet)
ADDomain (2 Cmdlets)
-
Get-ADDomain (Das Cmdlet funktioniert nicht bei den AD LDS)
Mit diesem Cmdlet und den entsprechenden Parametern lassen sich Domäneninformationen ausgeben.
-
Set-ADDomain (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Bearbeiten diverser Domäneninformationen verwenden.
ADDomainController (1 Cmdlet)
-
Get-ADDomainController (Das Cmdlet funktioniert nicht bei den AD LDS)
Ausführliche Informationen über einen Domänencontroller erhält man mit diesem Cmdlet.
ADDomainControllerPasswordReplicationPolicy (3 Cmdlets)
-
Add-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Computer können mit diesem Cmdlet in die Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe” hinzugefügt werden.
-
Get-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die Mitglieder (Benutzer, Gruppen oder Computer) der Sicherheitsgruppe „Zulässige RODC-Kennwortreplikationsgruppe” oder „Abgelehnte RODC-Kennwortreplikationsgruppe” werden mit diesem Cmdlet angezeigt.
-
Remove-ADDomainControllerPasswordReplicationPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet entfernt einzelne oder mehrere Benutzer, Gruppen oder Computer von der Sicherheitsgruppe „Abgelehnte RODC-Kennwortreplikationsgruppe” oder „Zulässige RODC-Kennwortreplikationsgruppe”.
ADDomainControllerPasswordReplicationPolicyUsage (1 Cmdlet)
-
Get-ADDomainControllerPasswordReplicationPolicyUsage (Das Cmdlet funktioniert nicht bei den AD LDS)
In welcher RODC-Kennwortreplikationsgruppe (zulässige oder abgelehnte) der angegebene Benutzer auf dem angegebenen RODC Mitglied ist, zeigt dieses Cmdlet.
ADDomainMode (1 Cmdlet)
ADFineGrainedPasswordPolicy (4 Cmdlets)
-
Get-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Dieses Cmdlet zeigt die konfigurierten Optionen einer oder mehrerer “Password Settings Objects (PSO)” an.
-
New-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Neue PSOs können mit diesem Cmdlet erstellt werden.
-
Remove-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen lässt sich ein PSO mit diesem Cmdlet.
-
Set-ADFineGrainedPasswordPolicy (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Die konfigurierten Optionen einer PSO können mit diesem Cmdlet überarbeitet werden.
ADFineGrainedPasswordPolicySubject (3 Cmdlets)
-
Add-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet wird eine bereits bestehende PSO mit einem oder mehreren Benutzern bzw. einer Gruppe verknüpft.
-
Get-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei den AD LDS)
Welche Benutzer oder Gruppen mit einem bestimmten PSO verknüpft sind, zeigt dieses Cmdlet.
-
Remove-ADFineGrainedPasswordPolicySubject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Eine oder mehre Benutzer bzw. Gruppen werden mit diesem Cmdlet von einer PSO entfernt.
ADForest (2 Cmdlets)
-
Get-ADForest (Das Cmdlet funktioniert nicht bei den AD LDS)
Weiterreichende Informationen über die Gesamtstruktur erhält man durch dieses Cmdlet.
-
Set-ADForest (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet lässt sich zum Hochstufen des Gesamtstrukturfunktionsmodus oder zum Bearbeiten gesamtstrukturweiter Informationen (z.B. Hinzufügen oder Bearbeiten des UPNSuffix) verwenden.
ADForestMode (1 Cmdlet)
-
Set-ADForestMode (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Der Gesamtstrukturfunktionsmodus lässt sich mit diesem Cmdlet Hochstufen.
ADGroup (4 Cmdlets)
-
Get-ADGroup
Sollen die Benutzer einer speziellen Gruppe ermittelt werden, eine Gruppe mit detailierten Informationen angezeigt oder alle Gruppen anhand bestimmter Kriterien ermittelt werden, so kann man dieses Cmdlet dafür verwenden.
-
New-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Sicherheit- oder Verteilergruppen können in der AD-Powershell mit diesem Cmdlet erstellen werden.
-
Remove-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Gruppentypen der Kategorie „Sicherheit“ oder „Verteilung“ werden mit diesem Cmdlet entfernt.
-
Set-ADGroup (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bestehende Gruppen lassen sich mit diesem Cmdlet bearbeiten.
ADGroupMember (3 Cmdlets)
-
Add-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer-, Gruppen-, Dienst- oder Computerkonten können mit diesem Cmdlet einer bestimmten Gruppe hinzugefügt werden.
-
Get-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Die Mitglieder (Benutzer, Gruppen, Clients) einer bestimmten Gruppe werden mit diesem Cmdlet angezeigt.
-
Remove-ADGroupMember (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Mit diesem Cmdlet ist es möglich, ein oder mehrere Benutzer, Gruppen oder Clients aus einer bestimmten Gruppe zu entfernen.
ADObject (7 Cmdlets)
-
Get-ADObject
Jegliche Active Directory-Abfrage kann anhand der angegebenen Parameter mit diesem Cmdlet durchgeführt werden.
-
Move-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Active Directory-Objekte oder OUs können entweder innerhalb oder zwischen Domänen mit diesem Cmdlet verschieben werden.
-
New-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Neue Active Directory-Objekte jeder Art, sei es z.B. neue Benutzer, OUs oder Subnetze werden mit diesem Cmdlet erstellt.
-
Remove-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jede Art von Active Directory-Objekten, wie z.B. Benutzer oder OUs, können mit diesem Cmdlet entfernt werden.
-
Rename-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Das umbenennen von AD-Objekten kann mit diesem Cmdlet durchgeführt werden.
-
Restore-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet stellt ein gelöschtes ADObjekt aus dem Container „Deleted Objects“ wieder her.
-
Set-ADObject (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Jegliche Art von AD-Objekten lassen sich mit diesem Cmdlet bearbeiten.
ADOptionalFeature (3 Cmdlets)
-
Disable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Active Directory „Optional Feature“ lässt sich mit diesem Cmdlet deaktivieren.
-
Enable-ADOptionalFeature (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Aktivieren lässt sich ein „Optional Feature“, wie z.B. der AD-Papierkorb, mit diesem Cmdlet.
-
Get-ADOptionalFeature
Die optionalen Features innerhalb einer Gesamtstruktur werden mit diesem Cmdlet angezeigt.
ADOrganizationalUnit (4 Cmdlets)
-
Get-ADOrganizationalUnit
Eine oder mehrere Organisationseinheiten (OU) können anhand der angegebenen Parameter, mit diesem Cmdlet ermittelt werden.
-
New-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Erstellen lässt sich eine neue OU mit diesem Cmdlet.
-
Remove-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Soll eine OU (ohne oder mit Objekten) entfernt werden, so lässt sich das Löschen mit dieser Cmdlet durchführen. Ist allerdings die OU vor dem „versehentlichen“ löschen geschützt, so erscheint eine Fehlermeldung.
-
Set-ADOrganizationalUnit (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Die Eigenschaften einer OU (Adressinformationen oder die Einstellung „Objekt vor zufälligem Löschen schützen“ etc.) lassen sich mit diesem Cmdlet bearbeiten.
ADPrincipalGroupMembership (3 Cmdlets)
- Add-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet fügt einen oder mehrere Benutzer, Gruppen oder Computer zu einer oder mehreren Gruppen hinzu.
-
Get-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot)
Alle Gruppenmitgliedschaften eines Benutzers, einer Gruppe oder eines Clients werden mit diesem Cmdlet angezeigt.
-
Remove-ADPrincipalGroupMembership (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein oder mehrere Benutzer, Gruppen oder Clients werden mit diesem Cmdlet aus einer oder mehreren Gruppen entfernt.
ADRootDSE (1 Cmdlet)
-
Get-ADRootDSE
Die Informationen des Einstiegpunkts eines Active Directory (RootDSE) zeigt dieses Cmdlet an.
ADServiceAccount (6 Cmdlets)
-
Get-ADServiceAccount (Das Cmdlet funktioniert nicht bei den AD LDS)
Die im Windows Server 2008 R2 eingeführten AD-Dienstkonten („Managed Service Account“) lassen sich anhand der angegeben Parameter, mit diesem Cmdlet anzeigen.
-
Install-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Ein neues AD-Dienstkonto lässt sich mit diesem Cmdlet installieren.
-
New-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Dieses Cmdlet erstellt ein neues AD-Dienstkonto.
-
Remove-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Entfernen kann man ein AD-Dienstkonto mit diesem Cmdlet.
-
Set-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Mit diesem Cmdlet lässt sich ein bestehendes AD-Dienstkonto bearbeiten.
-
Uninstall-ADServiceAccount (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Deinstallieren lässt sich ein AD-Dienstkonto mit diesem Cmdlet.
ADServiceAccountPassword (1 Cmdlet)
- Reset-ADServiceAccountPassword (Das Cmdlet funktioniert nicht bei einem AD-Snapshot, AD LDS und auch nicht bei einem RODC)
Das Kennwort eines AD-Dienstkontos kann mit diesem Cmdlet zurückgesetzt werden.
ADUser (4 Cmdlets)
- Get-ADUser
Ist man auf der Suche nach einem bestimmten oder nach mehreren Benutzern die alle ein bestimmtes Kriterium erfüllen, so lässt sich die Abfrage mit diesem Cmdlet durchführen.
-
New-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Ein Benutzerkonto (samt Kennwort) lässt sich mit diesem Cmdlet erstellen.
-
Remove-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Dieses Cmdlet entfernt ein oder mehrere Benutzerkonten.
-
Set-ADUser (Das Cmdlet funktioniert nicht bei einem AD-Snapshot und auch nicht bei einem RODC)
Bearbeiten kann man ein Benutzerkonto mit diesem Cmdlet.
ADUserResultantPasswordPolicy (1 Cmdlet)
-
Get-ADUserResultantPasswordPolicy (Das Cmdlet funktioniert nicht bei den AD LDS)
Die mit einem Benutzer- oder Gruppenkonto verknüpften “Password Settings Objects“ (PSO) werden mit diesem Cmdlet angezeigt.
Weitere Informationen:
AD-PowerShell Befehle
Active Directory Powershell Overview
Active Directory Module for Windows PowerShell Cookbook
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
Der Active Directory-Papierkorb im Windows Server 2008 R2
Das versehentliche Löschen von Active Directory-Objekten ist in Active Directory (AD) bzw. Active Directory Domain Services (AD DS), als auch in Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) Umgebungen mehr als ärgerlich. Denn schnell sind mit zwei Mausklicks ein oder mehrere Objekte gelöscht. Hoffentlich existiert in so einem Fall eine aktuelle und vor allem funktionierende Sicherung, mit dem das verlorene Objekt wiederhergestellt werden kann. Bis jedoch das passende Sicherungsband gefunden, eingelegt und das Objekt letztenendes wiederhergestellt ist, können diese Arbeiten sehr zeitintensiv und aufwändig sein.
Die Möglichkeiten die einem bei der Wiederherstellung zur Verfügung stehen, sind unter:
-
Windows 2000 = Autoritative Wiederherstellung
-
Windows Server 2003 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2003 R2 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2008 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2008 R2 = AD-Papierkorb, Autoritative Wiederherstellung, Tombstone reanimieren (bei deaktiviertem und aktiviertem AD-Papierkorb)
Die autoritative Wiederherstellung
Existiert eine aktuelle und funktionierende System State-Sicherung, kann mit einer autoritativen Wiederherstellung das Objekt mit all seinen Informationen die es zum Zeitpunkt der Sicherung hatte, wiederhergestellt werden. Dabei darf die Systemstatus-Sicherung (auf englisch: System State) nicht älter als die Tombstone-Lifetime (TSL) sein, denn ansonsten entstehen Lingering Objects. Die TSL einer Gesamtstruktur gibt das maximale Alter einer Systemstatus-Sicherung an, die für eine Rücksicherung verwendet werden darf.
Ein AD-Objekt wird in der Kommandozeile mit dem Befehl Ntdsutil-authoritative restore hergestellt. Dabei wird die Versionsnummer um 100.000 erhöht, damit das rückgesicherte Objekt nach der AD-Replikation auf die Replikationspartner erhalten bleibt und nicht von einem anderen DC direkt wieder gelöscht wird.
Problematisch ist allerdings die Wiederherstellung der Gruppenmitgliedschaften eines gelöschten Benutzers, die sogenannten Backlinks. Zur Wiederherstellung von Gruppenmitgliedschaften sind weitere aufwändige Schritte notwendig. Das hat sich zwar mit Windows Server 2003 SP1 etwas entschärft, jedoch ist weiterhin der Aufwand zum Rücksichern dieser Backlinks recht hoch.
Der Nachteil einer autoritativen Wiederherstellung wäre, dass der Domänencontroller (DC) im Modus Verzeichnisdienste wiederherstellen gestartet werden muss und dadurch zwei Neustarts notwendig sind. Somit würde der DC während der ganzen Zeit der Wiederherstellung nicht zur Verfügung stehen.
Diese Vorgehensweise ist seit der Einführung des Active Directory mit Windows 2000 gleich geblieben.
Weitere Details stehen in dem Artikel:
Active Directory Wiederherstellung
Ist eine Wiederherstellung in einer AD LDS-Umgebung notwendig, so ist es erforderlich die AD LDS-Instanz vorher zu stoppen. Allerdings muss für die Wiederherstellung der Server nicht im Modus Verzeichnisdienste wiederherstellen gestartet werden.
Wiederherstellen von AD LDS-Instanzdaten
Die Tombstone-Reanimierung
Eine andere Variante die seit Windows Server 2003 zur Verfügung steht, ist das reanimieren des Tombstones (zu Deutsch: Grabstein). Diese Art der Wiederherstellung hat den Vorteil, dass das Tombstone online ohne, dass der DC neu gestartet werden muss, jederzeit wiederhergestellt werden kann. Auch in einer AD LDS-Umgebung muss dazu die AD LDS-Instanz nicht offline genommen werden. Das gelöschte Objekt (das Tombstone) kann natürlich nur reanimiert werden, solange die Tombstone Lifetime nicht abgelaufen ist. Der Nachteil dieser Variante wiederum wäre, dass beim Wiederbeleben des Tombstones nicht alle Informationen eines Objekts automatisch wiederhergestellt werden.
Denn wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.dit). Das Objekt wird stattdessen vom Active Directory als gelöscht markiert, indem das Attribut Is-Deleted des Objekts auf den Wert True gesetzt wird. Aber es werden die meisten Attribute von dem Objekt für immer entfernt. Danach wird das Objekt in den versteckten Container Deleted Objects (der in jeder Verzeichnispartitionen existiert) verschoben und wird ab diesem Zeitpunkt als Tombstone bezeichnet. Wird also ein Benutzer gelöscht, so landet das Benutzerkonto mit wenigen Werten im Container „Deleted Objects“ der Domänenpartition und wird erst nach Ablauf der TSL vom Garbage Collection Prozess ein für allemal aus dem AD entfernt.
Landet das Tombstone im Container „Deleted Objects“, erhält es einen speziellen Relative Distinguished Name (RDN) der so aussieht: „CN=<Alter RDN>\0ADEL:<Object-GUID>“. Beim Wiederbeleben des Tombstone wird das Objekt dann nur noch mit einigen wenigen Werten (z.B. ObjectGUID oder ObjectSID) wiederhergestellt.
Der Container „Deleted Objects“ wird aber nicht in den AD Snap-Ins oder im ADSIEdit angezeigt. Stattdessen können die Tombstones mit ADRestore.Net, ADRestore oder LDP.exe angezeigt sowie wiederhergestellt werden.
ADRestore.NET
ADRestore
Die restlichen Werte die in einem wiederhergestellten Tombstone fehlen, könnten mit einem der folgenden Tools, von einem zuvor erstellten AD-Snapshot unter Windows Server 2008 bzw. Windows Server 2008 R2 wiederhergestellt werden.
Directory Service Comparison Tool 1.3.2.X
AD Explorer
Die Grabstein-Lebenszeit (Tombstone Lifetime)
Die Tombstone Lifetime wird mit dem Installieren des allerersten DCs für die komplette Gesamtstruktur festgelegt. Dabei ist es entscheidend welches Server-Betriebssystem mit welchem Service-Pack auf dem Server installiert ist, mit dem die Gesamtstruktur erstellt wird. Das Installieren eines Service-Packs auf bestehenden DCs, verändert niemals die Tombstone Lifetime. Es müsste schon die Gesamtstruktur neu installiert werden.
Wie und wo man die TSL überprüfen kann, steht neben weiteren Details in dem folgenden Artikel.
Die Tombstone Lifetime
Die Tombstone-Lifetime beträgt unter den Betriebssystemen:
-
Windows 2000 (mit allen SPs) = 60 Tage
-
Windows Server 2003 ohne SP = 60 Tage
-
Windows Server 2003 ab Service Pack 1 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
-
Windows Server 2003 R2 ab Service Pack 2 (installiert mit der ersten oder beiden R2-CDs) = 180 Tage
-
Windows Server 2008 (mit allen SPs) = 180 Tage
-
Windows Server 2008 R2 (mit allen SPs) = 180 Tage
Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung unter Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2, bei deaktiviertem AD-Papierkorb
Der Active Directory-Papierkorb unter Windows Server 2008 R2
Ein absolutes Highlight im Windows Server 2008 R2 ist der Papierkorb für gelöschte Active Directory-Objekte. Wird ein Active Directory-Objekt in den Active Directory Domain Services (AD DS) oder Active Directory Lightweight Directory Services (AD LDS) gelöscht, kann es Dank des AD-Papierkorbs schnell wiederhergestellt werden. Der AD-Papierkorb steht in AD DS und AD LDS-Umgebungen zur Verfügung. Der große Vorteil des AD-Papierkorbs ist, dass das Objekt mit all seinen Informationen die es zum Zeitpunkt der Löschung hatte wiederhergestellt wird. Das bedeutet, alle Attribute samt allen Backlinks und somit z.B. den Gruppenmitgliedschaften eines Benutzers, werden hergestellt. Nach der Wiederherstellung ist auch der Zugriff auf die bestehenden Objekte und Ressourcen wieder gegeben.
Dafür wird weder eine System-State Sicherung benötigt, noch muss der DC im Verzeichnisdienste wiederherstellen Modus gestartet werden. Die Wiederherstellung findet im laufenden Betrieb statt.
Diese neue Technik steht ausschließlich in den folgenden Server-Versionen zur Verfügung:
-
Windows Server 2008 R2 Standard
-
Windows Server 2008 R2 Enterprise
-
Windows Server 2008 R2 Datacenter
Der AD-Papierkorb steht in den folgenden Versionen nicht zur Verfügung:
- Windows Server 2008 R2 für Itanium basierte Systeme
- Windows Web Server 2008 R2
Jedoch ersetzt diese Funktion niemals eine regelmäßige System State-Sicherung von mindestens zwei DCs pro Domäne!
Die Voraussetzungen um den Active Directory-Papierkorb unter Windows Server 2008 R2 zu nutzen
Die Voraussetzungen um den AD-Papierkorb zu nutzen sind:
-
Der AD-Papierkorb steht in den AD DS und AD LDS-Umgebungen erst im Gesamtstrukturfunktionsmodus Windows Server 2008 R2 zur Verfügung. Es müssen also alle Domänencontroller aus allen Domänen der Gesamtstruktur oder alle Server auf denen eine AD LDS-Instanz konfiguriert ist, unter Windows Server 2008 R2 laufen!
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
-
Der AD-Papierkorb ist standardmäßig deaktiviert, sowohl bei einer Domänenaktualisierung oder dem neu Aufsetzen einer Windows Server 2008 R2 Gesamtstruktur im Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“. Der AD-Papierkorb muss explizit in der AD-Powershell aktiviert werden. Dieser Schritt ist ein irreversibler Vorgang und kann danach nicht mehr rückgängig gemacht werden!
Nach dem Aktivieren des AD-Papierkorbs lässt sich dieses Feature mit Bordmitteln über die AD-Powershell und LDP.exe nutzen. Es existiert keine grafische Oberfläche in der man mit der Maus die Funktion aktivieren kann. Jedoch lassen sich mit dem Tool LDP oder den beiden Tools ADRestore.Net und ADRestore, ebenfalls die gelöschten Objekte im AD-Papierkorb anzeigen sowie wiederherstellen.
Kann der AD-Papierkorb für eine einzige Domäne in der Gesamtstruktur aktiviert werden?
So wie bei der Tombstone Lifetime ist es nicht möglich, den AD-Papierkorb „pro Domäne“ zu aktivieren. Wenn die Voraussetzungen erfüllt sind, kann diese Funktion nur auf der Gesamtstrukturebene mit „Organisations-Admin“ Rechten für alle Domänen aktiviert werden. Anschließend steht jeder Domäne sein eigener AD-Papierkorb zur Verfügung. Der AD-Papierkorb existiert also "pro Domäne" und nicht "pro Gesamtstruktur"!
Die Funktionsweise des Active Directory-Papierkorbs unter Windows Server 2008 R2
Der AD-Papierkorb baut auf der Technik der Tombstone-Reanimierung auf. Jedoch werden vom gelöschten Objekt dafür keine Attribute vom System entfernt und es bleiben alle Attribute erhalten. Das Objekt wird logisch gelöscht bzw. inaktiv gesetzt, was ein neues Stadium eines gelöschten Objekts ist, das mit Windows Server 2008 R2 eingeführt wurde. In der AD-Datenbank wurde dazu das Speicherformat der Objektlinks geändert. Wird ein Objekt gelöscht, so erhält das Attribut isDeleted im Objekt den Wert TRUE. Das gelöschte Objekt wird nach wie vor in den versteckten Container Deleted Objects verschoben und sein Distinguished Name (DN) erhält dadurch einen neuen Wert. Das Objekt in „Deleted Objects“ behält seinen logischen Löschzustand solange bei, bis die Deleted Object Lifetime (DOL) abgelaufen ist. Nach Ablauf der DOL wandelt sich das gelöschte Objekt zu einem "recycled Objekt". Das recycled Objekt wird dann endgültig vom Garbage Collection Prozess nach Ablauf der Recycled Object Lifetime (ROL) aus der AD-Datenbank entfernt. Unter Windows Server 2008 R2 gibt es nun neben der Tombstone Lifetime zusätzlich die Deleted Object Lifetime (kurz DOL) und Recycled Object Lifetime (kurz ROL).
Die Deleted Object Lifetime wird durch den Wert im neuen Attribut msDS-DeletedObjectLifetime bestimmt. Denn bei einer Domänenaktualisierung auf Windows Server 2008 R2 ist eines der Schema-Aktualisierungen mit Adprep /Forestprep (von der Windows Server 2008 R2 DVD) das Hinzufügen des neuen Attributs msDS-DeletedObjectLifetime. Wenn jedoch eine Gesamtstruktur auf Basis von Windows Server 2008 R2 erstellt wird, befinden sich bereits alle benötigten Attribute im Schema und das Adprep muss in keinster Weise ausgeführt werden. Die Recycled Object Lifetime hingegen, erhält seinen Wert aus dem Attribut tombstoneLifetime.
Ist die Zeit des im Attribut msDS-DeletedObjectLifetime definierten Werts abgelaufen, wandelt sich das logisch gelöschte Objekt zum „recycled Objekt“. Zusätzlich erhält das Attribut isRecycled im Objekt den Wert TRUE. Dabei werden die gleichen Attribute vom Objekt entfernt, wie es seit Windows Server 2003 bei einem Tombstone der Fall ist. Oder anders ausgedrückt, im recycled Objekt bleiben standardmäßig die gleichen Attribute erhalten wie bei einem Tombstone unter Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 bei deaktiviertem AD-Papierkorb. Von der Begrifflichkeit her entspricht ein „recycled Objekt“ einem klassischen Tombstone.
Eine Besonderheit gibt es jedoch mit recycled Objects! Diese lassen sich nicht wie mit einem klassischen Tombstone reanimieren. Denn die API zum reanimieren eines recycled Objects ist bei aktiviertem AD-Papierkorb deaktiviert!
Das recycled Objekt bleibt weiterhin in dem Container Deleted Objects, bis die im Attribut tombstoneLifetime definierte Zeit abläuft. Anschließend wird das Objekt vom Garbage Collection Prozess unwiderruflich aus dem AD entfernt.
Das bedeutet im Klartext, bei aktiviertem AD-Papierkorb lässt sich ein gelöschtes Objekt nur während der DOL mit allen Werten wiederherstellen. Die Möglichkeiten zum Wiederherstellen sind dabei:
-
Das Wiederherstellen aus dem AD-Papierkorb mit der AD-Powershell, LDP, ADRestore.NET oder ADRestore.
-
Eine autoritative Wiederherstellung.
Achtung: Wird der AD-Papierkorb aktiviert, wandeln sich alle AD-Objekte die bis zum Aktivieren des AD-Papierkorbs gelöscht wurden (also alle Tombstones), zu recycled Objekten. Diese Objekte können in der AD-Powershell mit einem bestimmten Befehl angezeigt werden (siehe unten). Jedoch können diese Objekte nicht mit Hilfe des AD-Papierkorbs bzw. der Tombstone-Reanimierung wiederhergestellt werden. Die beiden Tools ADRestore.NET und ADRestore zeigen ebenfalls diese Tombstones nicht an. Das Tool LDP zeigt zwar ebenfalls die Objekte an, ist aber auch nicht in der Lage die Objekte wiederherzustellen. Der einzige Weg diese Objekte herzustellen, ist eine autoritative Wiederherstellung von einer Systemstatus-Sicherung, die vor dem aktivieren des AD-Papierkorbs durchgeführt wurde.
Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL)
Standardmäßig enthält das Attribut msDS-DeletedObjectLifetime keinen Wert. Es ist <Nicht festgelegt>. In diesem Fall wird der Wert aus der Recycled Object Lifetime festgelegt. Man kann aber natürlich auch jederzeit manuell einen Wert im Attribut msDS-DeletedObjectLifetime definieren.
Die ROL wiederum erhält seinen Wert aus dem Attribut tombstoneLifetime, denn die ROL hat kein eigenes Attribut wie die DOL. Das bedeutet, wenn ein Objekt gelöscht wird und im Attribut msDS-DeletedObjectLifetime ist kein Wert definiert, behält das Objekt für 60/180 Tage seinen logischen Löschzustand bei und wird anschließend zum recycled Objekt umgewandelt. Nach weiteren 60/180 Tagen (nach Ablauf der Tombstone Lifetime) wird es dann endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Das Objekt bleibt somit über den gesamten Zeitraum der DOL und ROL im AD erhalten, ehe es definitiv aus dem AD gelöscht wird.
Ist hingegen im Attribut msDS-DeletedObjectLifetime ein Wert definiert, so beträgt die DOL den eingetragenen Wert in Tagen und es wird nicht der Wert aus dem Attribut tombstoneLifetime angenommen. Wenn daher der Bedarf besteht, ein gelöschtes Objekt länger als die Zeit das im Attribut tombstoneLifetime eingetragen ist aus dem AD-Papierkorb wiederherzustellen, so gilt es einen eigenen Wert im Attribut msDS-DeletedObjectLifetime zu definieren.
Enthält z.B. das Attribut tombstoneLifetime als Wert 180 und ist im Attribut msDS-DeletedObjectLifetime kein Wert eingetragen, so wird ein gelöschtes Objekt erst nach 360 Tagen vom Garbage Collection Prozess für immer aus dem AD entfernt.
Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung, bei aktiviertem AD-Papierkorb unter Windows Server 2008 R2
Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL) überprüfen und bearbeiten
-
Das Attribut msDS-DeletedObjectLifetime befindet sich im gleichen Container wie das Attribut tombstoneLifetime, nämlich in den Eigenschaften des Containers:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
-
Kontrollieren kann man das Attribut msDS-DeletedObjectLifetime z.B. mit Dsquery.
Der Befehl lautet:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne" -attr msDS-DeletedObjectLifetime
Falls kein Wert angezeigt wird, gilt der Standardwert aus dem Attribut tombstoneLifetime von 60/180 Tagen (sofern nicht manuell geändert). Ansonsten gilt der angezeigte Wert in Tagen.
-
Das Attribut tombstoneLifetime lässt sich mit Dsquery folgendermaßen abfragen:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime
Falls kein Wert angezeigt wird, gilt als Wert 60 Tage. Ansonsten gilt auch hier der angezeigte Wert in Tagen.
-
Die DOL und das Attribut tombstoneLifetime lassen sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es zuerst zum folgenden Container zu navigieren:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Dort befindet sich in den Eigenschaften des Containers zum einen das Attribut msDS-DeletedObjectLifetime und zum anderen das Attribut tombstoneLifetime. Ist im Attribut msDS-DeletedObjectLifetime ein Wert gesetzt, beträgt die DOL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Nicht festgelegt>, so beträgt die DOL den Wert aus dem Attribut tombstoneLifetime. Wenn im Attribut tombstoneLifetime als Wert <Nicht festgelegt> ist, so gilt als Wert 60 Tage. Ansonsten beträgt die Zeit den eingetragenen Wert in Tagen.
-
Die DOL lässt sich auch über die AD-Powershell bearbeiten. Dazu ist die AD-Powershell explizit als Administrator aufzurufen und der folgende Befehl einzugeben:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“msDS-DeletedObjectLifetime” = Wert}
Das Attribut tombstoneLifetime lässt sich im Übrigen auch auf die gleiche Weise verändern: Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}
Aktivieren und nutzen des AD-Papierkorbs in der Active Directory-Powershell
Nach Ausführen von Dcpromo steht die Active Directore-Powershell mit 76 AD-Cmdlets auf dem DC zur Verfügung. Mit den beiden AD-Powershell Cmdlets Get-ADObject und Restore-ADObject ist es möglich, gelöschte AD-Objekte anzuzeigen sowie wiederherzustellen. Dabei ruft man mit Get-ADObject das gelöschte Objekt auf und übergibt es durch die Pipeline dem Restore-ADObject Cmdlet.
Zum Aktivieren des AD-Papierkorbs ist die folgende Vorgehensweise notwendig:
-
Im ersten Schritt muss mit „Organisations-Admin“ Rechten der AD-Papierkorb in der Root-Domäne und zwar für alle Domänen in der Gesamtstruktur aktiviert werden. Der Befehl dazu lautet:
Enable-ADOptionalFeature „Recycle Bin Feature“ -Scope ForestorConfigurationset -Target “Root-Domäne*” (*DNS- oder NetBIOS-Name der Root-Domäne)
Es folgt eine Warnung die besagt, dass bei Bestätigen der Meldung dieser Vorgang irreversibel ist. Nach dem Aktivieren des AD-Papierkorbs, lässt es sich nicht mehr deaktivieren!
-
Wenn der AD-Papierkorb aktiviert wurde, wird im Attribut msDS-EnabledFeature das sich in den Eigenschaften des Containers "CN=Partitions,CN=Configuration,DC=Root-Domäne" befindet, als Wert "CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" eingetragen.
-
Der folgende Befehl zeigt detaillierte Informationen über die zur Verfügung stehenden Optional Feature im Active Directory an:
Get-ADOptionalFeature -Filter * oder Get-ADOptionalFeature -Filter {Name -Like "*"}
-
Wurde ein Benutzerkonto aus Versehen gelöscht, so kann man sich das Konto wenn der sAMAccountName bekannt ist, auf diese Art anzeigen lassen:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} -Includedeletedobjects
Wiederherstellen lässt sich das Benutzerkonto dann mit diesem Befehl:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} –Includedeletedobjects | Restore-ADObject
-
Ist der „Anzeigename“ eines Benutzerkontos bekannt, so lautet die Abfrage wie folgt. Aber Vorsicht, der „Anzeigename“ ist nicht der Name, der in der MMC Active Directory-Benutzer und -Computer in der Spalte „Name“ angezeigt wird. Denn dieser Wert wiederum, wird im Attribut name gespeichert.
Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects
Wiederherstellen lässt sich das Benutzerkonto dann so:
Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects | Restore-ADObject
-
Ein bestimmtes Benutzerkonto wird auf diese Weise angezeigt:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects
Oder so:
Get-ADOject -Filter 'Name -Like "Yusuf*"' -Searchscope Subtree -Includedeletedobjects | ft -a
Wiederherstellen kann man dann das Benutzerkonto so:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects | Restore-ADObject
-
Dieser Befehl zeigt die gelöschten Objekte im Container "Deleted Objects" an:
Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=*)" -Includedeletedobjects
Wiederherstellen kann man ein Benutzerkonto auch wie folgt:
Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=<Benutzer>)" -Includedeletedobjects | Restore-ADObject
-
Der nachfolgende Befehl zeigt die gelöschten sowie recycelten Objekte mit detailierten Informationen an, die in einer bestimmten OU waren. Mit diesem Befehl können auch die recycelten Objekte angezeigt werden, die vor dem aktivieren des AD-Papierkorbs gelöscht wurden:
Get-ADObject -Filter {Lastknownparent -eq "OU=<OU>,DC=Domäne,DC=de"} -Searchbase "CN=Deleted Objects,DC=Domäne,DC=de" -includedeletedobjects -properties *
-
Mit dem folgenden Befehl kann man sich alle gelöschten Objekte, egal welcher Klasse, aus dem versteckten Container „Deleted Objects“ der Domänenpartition anzeigen lassen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects | Format-List
-
Oder wer die Objekte jeglicher Klassen im schnellen Überblick haben möchte, verwendet diesen Befehl:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects
-
Die gelöschten AD-Objekte der Klasse „User“ (z.B. Benutzerkonten) lassen sich wie folgt anzeigen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=User)“ –IncludedeletedObjects
-
Wurde ausversehen eine OU mit etlichen Benutzern gelöscht, so muss zuerst die OU wiederhergestellt werden, ehe dann die Benutzer wiederhergestellt werden können. Doch bevor die OU wiederhergestellt werden kann, wird die GUID der gelöschten OU benötigt. Diese erfährt man durch das Attribut lastknownparent eines Benutzers, das sich in der OU befand. Der Befehl würde so aussehen:
Get-ADOject -filter 'name -like "Yusuf*"' -searchscope subtree -Includedeletedobjects -properties lastknownparent
Dann kann mit diesem Befehl zuerst die OU wiederhergestellt werden:
Restore-ADObject -identity <GUID der OU>
Alle Objekte die sich in der OU befanden, können mit diesem Befehl wiederhergestellt werden:
Get-ADObject -ldapfilter "(lastknownparent=OU=<OU>,DC=Domäne,DC=TLD)" -Includedeletedobjects | Restore-ADObject
Die AD-Powershell im Windows Server 2008 R2
Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit ADRestore.NET und ADRestore
-
Das Tool ADRestore.NET muss zuerst installiert werden, lässt sich dann aber sehr simpel mit der Maus bedienen und ist vor allem selbsterklärend. Die gelöschten Objekte lassen sich mit einem Mausklick anzeigen und mit einem weiteren wiederherstellen.
ADRestore.NET
-
Das Kommandozeilentool ADRestore lässt sich nach dem Download ohne eine Installation in einer Kommandozeile ausführen. Auch dieses Tool ist selbsterklärend.
ADRestore
-
Ein weiteres kostenloses Tool ist das ADRecycleBin. Es zeigt die gelöschten Objekte an und stellt diese wieder her.
ADRecycleBin
Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit LDP
Die gelöschten Objekte im Container Deleted Objects lassen sich ebenfalls mit dem im Betriebssystem integrierten LDAP-Tool LDP anzeigen sowie wiederherstellen lassen.
Die Vorgehensweise wäre wie folgt:
-
Zuerst gilt es auf dem DC unter Start-Ausführen-LDP.exe das Tool aufzurufen.
-
Unter Optionen ist dann in den Steuerelementen im Feld Vordefiniert laden die Option Return deleted objects auszuwählen. Wählt man an dieser Stelle stattdessen die Option Return recycled objects aus, kann man sich bei gleicher Vorgehensweise die „recycelten Objekte“ anzeigen lassen.
-
Danach wählt man unter Remotedesktopverbindung den Punkt Gebunden... aus. Grandiose Bezeichnungen.
-
Anschließend gibt man unter Ansicht-Struktur den Distinguished Name (DN) der entsprechenden (meistens) Domänenpartition an, z.B. DC=blog,DC=dikmenoglu,DC=de
-
Nun erweitert man zuerst auf der linken Seite die entsprechende Verzeichnispartition und erweitert auch den Eintrag Deleted Objects mit einem Doppelklick. Jetzt erscheinen die gelöschten Objekte.
-
Mit einem Rechtsklick auf das wiederzuherstellende Objekt, wählt man den Punkt Ändern aus.
-
Unter Eingabe bearbeiten gibt man im Feld Attribut isDeleted ein.
-
Das Feld Werte bleibt leer.
-
Unter Vorgang wählt man Löschen und klickt auf Eingabe.
-
Jetzt müssen die gleichen Schritte mit dem Attribut distinguishedName durchgeführt werden.
-
Im Feld Werte ist nun der original DN des Objekts einzugeben. Daher ist es stets sinnvoll, eine Liste mit allen Objekten und deren DN zu besitzen.
-
Unter Vorgang wählt man Ersetzen und klickt auf Eingabe.
-
Nach dem aktivieren von Erweitert führt man die Wiederherstellung mit einem Klick auf Ausführen durch.
Fallbeispiele
-
Wenn z.B. ein Benutzer Mitglied der Gruppe1 ist, beide Objekte nacheinander gelöscht werden, aber nur das Benutzerkonto aus dem AD-Papierkorb wiederhergestellt wird, befindet sich anschließend das Benutzerkonto logischerweise nicht mehr in der Gruppe1. Wird jedoch die Gruppe1 ebenfalls aus dem AD-Papierkorb wiederhergestellt, werden automatisch Forward- und Back-Link wiederhergestellt. Das Benutzerkonto ist wieder Mitglied der Gruppe1.
-
Existiert eine Gruppenverschachtelung, so das also GG1 Mitglied von GG2, diese wiederum Mitglied in GG3 ist und GG2 gelöscht wird, verschwinden ebenfalls die Gruppenzugehörigkeiten. Auch hier werden beim wiederherstellen der GG2 aus dem AD-Papierkorb, die Gruppenzugehörigkeiten und somit das Forward- und Back-Link automatisch wiederhergestellt.
Weitere Informationen:
2.175 Attribute msDS-DeletedObjectLifetime
2.109 Attribute isDeleted
2.112 Attribute isRecycled
2.179 Attribute msDS-EnabledFeature
The Active Directory database garbage collection process
Useful shelf life of a system-state backup of Active Directory
Viewing deleted objects in Active Directory
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|