Mit dem Read-Only Domänencontroller hat Microsoft ein weiteres Highlight in Windows Server 2008 eingeführt,
nämlich eine neue Art von Domänencontroller (DC). Einige werden sicherlich denken, dass Microsoft ganz nach dem Motto
„Back to the Roots“ sich nicht von dem zu NT-Zeiten existierenden, des BDCs (Backup Domain Controller) lösen konnte.
Das ist ein Irrtum, denn ein RODC stellt weitaus mehr zur Verfügung und ist keineswegs mit dem NT-BDC zu vergleichen.
Der primäre Gedanke bei Microsoft war an dieser Stelle, dass Domänencontroller in Außenstellen besser „geschützt“ werden müssen.
Die Gegebenheiten einer Außenstelle sind meistens gleich: Es existiert nur eine geringe bis keine physikalische Sicherheit, weiterhin existiert ein
geringes EDV-Wissen vor Ort, i.d.R. eine begrenzte Anzahl von Benutzern sowie eine geringe WAN-Anbindung. Oftmals ist es so, dass der
Domänencontroller der in einer Außenstelle steht, physikalisch nicht die gleiche sichere Umgebung genießt, wie ein Domänencontroller der in der Zentrale steht.
In den Außenstellen steht der DC meistens unter einem Tisch mitten im Raum (samt Backup), an den physikalisch jeder heran kann
(z.B. die Putzfrau) und somit diesen DC Schaden bzw. kompromittieren könnte. Was auch noch denkbar wäre, dass der DC Freitag Abends wenn
keiner im Büro ist von jemandem gestohlen wird, die Benutzer- und vor allem administrativen Konten verändert und den DC danach Sonntag Abends
erneut an seinen Platz stellt. Somit würden unbemerkt die kompromittierten Konten repliziert werden und geben dadurch dem Angreifer ganz
andere Möglichkeiten.
Daher war die Idee, wenn zumindest der Domänencontroller nicht physikalisch gesichert werden kann, dass zumindest die Domäne und somit die
Active Directory-Domänendienste (AD-DS) mehr Sicherheit bekommen. Früher (bis Windows Server 2003) würde man im Idealfall dazu übergehen,
vor Ort keinen Domänencontroller aufzustellen (ja, die Realität sieht anders aus). Der Nachteil wäre, dass erstens, die Benutzerauthentifizierung über
das WAN erfolgen müsste und zweitens, wenn die WAN-Verbindung gestört wäre, dass sich die Benutzer nicht mehr in der Domäne anmelden können
und der Benutzer sich mit seinen zwischengespeicherten Benutzerinformationen (cached credentials) nur lokal anmelden kann
(es würde keine Verbindung zu Domänen-Ressourcen bestehen).
Genau für diese Szenarien wurde der Read-Only Domänencontroller entwickelt. Denn mit einem RODC haben nun Unternehmen die Möglichkeit,
auch in Außenstellen die keine physikalische Sicherheit gewährleisten können, einen Domänencontroller aufzustellen.
Die Besonderheiten eines RODC
-
Der RODC besitzt ein vollständiges Replikat der Active Directory-Datenbank (samt allen Objekten und Attributen),
die sich auf einem normalen Domänencontroller befinden. Der einzige Unterschied, die Active Directory-Datenbank (NTDS.DIT) die sich auf
einem RODC befindet, erlaubt keine Änderungen und es besteht nur ein lesender Zugriff darauf. Änderungen müssen auf einem „beschreibbaren“
Domänencontroller vollzogen und auf den RODC repliziert werden.
-
Es ist möglich das DNS auf einem RODC zu installieren, dieser hat aber ebenfalls nur einen lesenden Zugriff auf das DNS
(Read-Only Domain Name System). Der RODC kann alle Anwendungsverzeichnispartitionen die vom DNS genutzt werden,
wie es die DomainDNSZones sowie ForestDNSZones Partitionen darstellen, enthalten. Wenn das DNS auf einem RODC installiert ist,
können Clients diesen für eine Namensauflösung anfragen und die Benutzer an den Standorten können sich ganz normal anmelden.
Dieser kann aber nicht die Namens-Aktualisierungen der Clients oder Name-Server (NS)-Einträge im DNS vornehmen.
-
Standardmäßig speichert ein RODC weder Computer- noch Benutzerinformationen, außer sein eigenes Computerkonto sowie ein
spezielles krbtgt Konto für den RODC. Der RODC trägt sich als Key Distribution Center (KDC) im Active Directory für den Standort ein.
Das krbtgt Konto das der RODC für zum Erstellen von verschlüsselten Ticket-Granting Tickets (TGT) verwendet, ist ein anderes,
als das auf einem beschreibbaren Windows Server 2008-Domänencontroller.
Auf einem RODC kann je nachdem explizit angegeben werden, welche Benutzer-, Computer- bzw. Dienstkonten für die
Zwischenspeicherung zugelassen oder verweigert werden sollen (credential caching). Diverse administrative Konten
(wie z.B. der Domänen-Administrator) werden standardmäßig nicht auf einem RODC zwischengespeichert. Es existieren zwei Domänenlokale
Sicherheitsgruppen: Abgelehnte RODC-Kennwortreplikationsgruppe und Zulässige RODC-Kennwortreplikationsgruppe die sich für die
Verwaltung der zu zwischenspeichernden Konten anbieten. Es lassen sich auch selbst definierte Gruppen verwenden.
Wenn ein Benutzerkonto in der abgelehnten- sowie zulässigen RODC-Kennwortreplikationsgruppe Mitglied ist, so hat die abgelehnte Gruppe Vorrang!
Sind die Konten einmal zwischengespeichert, können sich die Benutzer ohne eine bestehende WAN-Anbindung an dem RODC authentifizieren.
Wird nun ein RODC gestohlen, befinden sich „lediglich“ die zwischengespeicherten Konten auf der Maschine.
Wenn danach im Domain Controllers Container (im ADBuC) das Computerobjekt des RODCs entfernt werden würde,
bekommt man die Gelegenheit die Benutzer- sowie Computerkonten die auf dem RODC gespeichert waren, zurückzusetzen.
Weiterhin besteht die Möglichkeit, eine Liste der zwischengespeicherten Konten zu exportieren.
-
Es findet ausschließlich eine einseitige (unidirektionale) Replikation statt. Da keine Änderungen an einem RODC vollzogen werden können,
ist es somit auch nicht nötig, dass sich der Replikationspartner (ein beschreibbarer Domänencontroller) Änderungen von dem RODC zieht.
Es findet eine eingehende (Inbound) und keine ausgehende (Outbound) Replikation auf einem RODC statt.
Somit werden auch weniger Bridgeheadserver benötigt.
-
Dadurch, dass der RODC das gesamte Schema repliziert bekommt, ist dieses Verhalten evtl. in einigen Situationen nicht wünschenswert.
Wenn z.B. Applikationen eingesetzt werden, die sensible Informationen in den Active Directory-Domänendiensten speichern,
möchte man vielleicht diese Informationen nicht auf einem RODC haben. Daher bietet der RODC die Option
Read-Only Partial Attribute Set (ROPAS), auch bekannt als RODC Filtered Attribute Set (ROFAS).
Mit dieser Funktion lässt sich definieren, dass diverse Attribute nicht auf einen RODC repliziert werden.
Ist es angedacht das solche Applikationen zum Einsatz kommen, so sollte darauf geachtet werden,
dass sich aus Sicherheitsgründen die Gesamtstrukturfunktionsebene im Modus „Windows Server 2008“ befindet.
-
Einem Domänen-Benutzer bzw. einer Gruppe können administrative Rechte auf einem RODC delegiert werden.
Somit wird der Benutzer bzw. die Gruppe zum lokalen Administrator auf dem RODC, ohne das der Benutzer/die Gruppe weitere
Rechte auf die Domäne bzw. andere DCs erhält. Dadurch können die Personen die diese Rechte delegiert bekommen haben,
z.B. die Wartung des RODCs vornehmen sowie Treiber oder Updates von Applikationen einspielen.
-
Ein RODC kann an einem Standort mit folgenden Server-Versionen aufgestellt werden:
- Windows Server 2003 DCs aus der gleichen und/oder anderen Domäne
- Windows Server 2008 DCs aus der gleichen und/oder anderen Domäne
- Windows Server 2008 R2 DCs aus der gleichen und/oder anderen Domäne
- Windows Server 2008 RODCs aus der gleichen und/oder anderen Domäne
- Windows Server 2008 R2 RODCs aus der gleichen und/oder anderen Domäne
-
-
Die Installation eines RODCs kann in zwei Schritten vollzogen werden. Zuerst wird im Snap-In Active Directory-Benutzer und –Computer
mit einem Rechtsklick auf den Container Domain Controllers das Computer-Objekt erstellt.
Dazu werden Domänen-Administrator Rechte benötigt. Beim erstellen des Computer-Objekts wird z.B. der Computername und der
Standort festgelegt. Im zweiten Schritt ruft man den Active Directory-Assistenten DCPROMO auf und konfiguriert den Server zum RODC.
Das ausführen von DCPROMO kann von einem Benutzer in einer Außenstelle vollzogen werden,
der die entsprechenden Rechte delegiert bekommen hat.
Es reicht natürlich weiterhin aus, nur das DCPROMO direkt auszuführen.
Welche Voraussetzungen müssen erfüllt sein, um einen RODC einzusetzen?
-
Die Domänenpartition kann sich der RODC ausschließlich von einem beschreibbaren Windows Server 2008 bzw.
Windows Server 2008 R2 Domänencontroller replizieren. Demzufolge muss sich bereits ein
beschreibbarer Windows Server 2008/2008 R2/Core/Core R2 Domänencontroller in der Domäne befinden.
-
Der Gesamtstrukturfunktionsmodus muss sich mindestens in dem Modus Windows Server 2003
oder höher befinden, damit die Linked Value Replikation (LVR) zur Verfügung steht.
Das Active Directory Preparation Tool (ADPREP) muss mit dem Schalter /RODCPREP ausgeführt worden sein.
Dabei werden die Berechtigungen (Security Descriptor, SD) von allen DNS-Anwendungsverzeichnispartitionen (DomainDNSZones und ForestDNSZones) in der Gesamtstruktur aktualisiert. Der Befehl muss mit Organisations-Administrator Rechten durchgeführt werden und
kann auf irgendeinem DC ausgeführt werden. Dieser DC muss auch nicht der Träger der FSMO-Rollen sein. Beim Ausführen von ADPREP /Rodcprep werden die einzelnen Infrastrukturmaster der Domänen kontaktiert, um die Berechtigungen der Anwendungsverzeichnispartitionen DomainDNSZones und ForestDNSZones zu aktualisieren.
Welche Einschränkungen hat ein RODC?
-
Dadurch dass der RODC nur einen lesenden Zugriff auf die AD-Datenbank hat, kann er deshalb auch nicht der Träger der fünf
Flexible Single Master Operations (FSMO)-Rollen sein. Denn diese Rollen benötigen einen Schreibzugriff auf die AD-Datenbank,
damit z.B. der Schema-Master eine Schema-Änderung vollziehen kann usw.
-
Des Weiteren kann ein RODC auch kein Bridgehead-Server sein. Ein Bridgehead-Server ist für die Standort-zu-Standort Replikation zuständig.
Dieser sammelt die getätigten Änderungen im Active Directory an seinem Standort und repliziert diese zu einem anderen Bridgeheadserver an
einem entfernten Standort. Da der RODC nur eine einseitige In-Bound Replikation wahrnehmen kann, entfällt somit die Rolle des Bridgehead-Servers.
-
Da der RODC von einem beschreibbaren Domänencontroller abhängig ist, kann demzufolge der erste DC weder
in einer neuen Gesamtstruktur, noch in einer neuen Domäne ein RODC sein. Beim installieren eines RODCs muss
sich bereits ein beschreibbarer Windows Server 2008 DC in der Domäne befinden. Anderfalls ist das Heraufstufen zum RODC nicht möglich.
-
Eine weitere Einschränkung des RODCs wäre, dass sich die Domänenpartition in der sich z.B. die Benutzer- und Computerkonten befinden,
nicht von einem Windows Server 2003 DC replizieren lässt, sondern ausschließlich von einem beschreibbaren Windows Server 2008 bzw. Windows Server 2008 R2.
-
Es findet keine Replikation zwischen RODCs statt.
-
Ein Exchange Server wird auf einem RODC nicht unterstützt.
-
Wenn der einzige beschreibbare Domänencontroller einer Domäne crasht und an einem entfernten Standort „lediglich“ ein RODC existiert,
muss die Domäne neu erstellt werden. Denn im Gegensatz zum NT-BDC (dieser kann zum PDC gestuft werden) ist es nicht möglich,
einen RODC zu einem vollwertigen Domänencontroller zu stufen.
Das bedeutet, die allgemeine Empfehlung in jeder Domäne zwei Domänencontroller zu besitzen (neben dem RODC), gilt weiterhin.
Die Installation eines RODC
Mehr zum RODC gibt es hier:
Step-by-Step Guide for Read-Only Domain Controller in Windows Server 2008
Read-Only DCs and the Active Directory Schema
Einer der Neuerungen im Windows Server 2008, ist die Möglichkeit des stoppen und starten des Dienstes
Active Directory-Domänendienste (Active Directory Domain Services - AD-DS).
Dieser Dienst existiert standardmäßig auf jedem Windows Server 2008 Domänencontroller.
Der Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus spielt dabei keine Rolle.
Das Active Directory ist kein Dienst so wie es die anderen Dienste in der Dienstesteuerung (services.msc) darstellen.
Im Windows Server 2008 wurde lediglich die Funktion hinzugefügt, die AD-Domänendienste z.B. für Wartungszwecke oder
Aktualisierungen (Updates) zu beenden bzw. neu zu starten.
Der Administrator kann den Dienst AD-Domänendienste so wie die üblichen Dienste, entweder im Dienste Snap-In
oder über die Kommandozeile (CMD) beenden und neu starten.
In den Server-Versionen Windows 2000 Server oder Windows Server 2003 musste man z.B. für die Offlinedefragmentierung
der Active-Directory Datenbank (NTDS.DIT), den Domänencontroller (DC) im Modus Verzeichnisdienstwiederherstellung starten.
Nur in diesem Modus ist das Active Directory offline und kann manuell gewartet werden.
Insgesamt musste man am Ende zwei Neustarts durchführen.
Das geht nun ab dem Windows Server 2008 ohne Neustart des DCs. Dazu beendet man den AD-DS Dienst und dadurch auch die abhängigen Dienste.
Wenn der Dienst beendet und somit das Active Directory offline ist, können sich keine Benutzer an diesem DC authentifizieren.
Die abhängigen Dienste wären standardmäßig der Dateireplikationsdienst, Kerberos-Schlüsselverteilungsdienst,
Standortübergreifender Messagingdienst, DNS-Server und DFS-Replikation (der autorisierte DHCP-Server gehört nicht dazu).
Danach kann die Offline-Defragmentierung der AD-Datenbank oder anderweitige Wartungen (mit NTDSUTIL) durchgeführt werden.
Nach Abschluss der Defragmentierung bzw. Wartungsarbeiten, startet man den AD-DS Dienst wieder.
Die abhängigen Dienste werden dabei automatisch mit gestartet.
Achtung: Wenn der Dienst "Active Directory-Domänendienste" gestoppt ist, wird der Vorgang einer AD-Wiederherstellung,
sei es eine autoritative oder non-autoritative Wiederherstellung nicht supportet!
Dazu muss der DC weiterhin im Modus Verzeichnisdienstwiederherstellung gestartet werden,
damit sichergestellt ist, dass sich keine Informationen im RAM/Cache befinden.
Die Offline Defragmentierung ist notwendig, um die physikalische Größe der NTDS.DIT zu verkleinern (z.B. nach einer größeren Lösch-Aktion).
Die Online-Defragmentierung die standardmäßig alle 12 Stunden läuft, verkleinert dabei nicht die physikalische Größe.
Über die Kommandozeile lässt sich der AD-DS Dienst mit net stop NTDS stoppen bzw. mit net start NTDS starten.
Anschließend stellt das System die Nachfrage ob die abhängigen Dienste ebenfalls gestoppt werden sollen, was mit einem "J" zu bestätigen ist.
Besser ist es gleich diesen Befehl zu nutzen: net stop NTDS /y. Daraufhin werden automatisch auch alle abhängigen Dienste ohne Nachfrage gestoppt.
Mit net start NTDS werden die abhängigen Dienste ohne Nachfrage gestartet.
Wenn der AD-DS Dienst nicht laufen sollte, fungiert der Windows Server 2008 DC wie ein Mitgliedsserver (bei zusätzlich bestehenden DCs)
und ist über das Netzwerk erreichbar. Des Weiteren kann sich der Administrator für den Wiederherstellungsmodus standardmäßig nicht in
diesem Zustand anmelden. Damit das aber möglich ist, muss folgender Registry Eintrag erstellt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
REG_DWORD = DsrmAdminLogonBehavior
0 = Dieses ist die Standardeinstellung. Der Administrator für den Wiederherstellungsmodus kann
sich nur im Modus Verzeichnisdienstwiederherstellung anmelden.
1 = Bei diesem Wert, kann sich der Administrator für den Wiederherstellungsmodus im Modus
Verzeichnisdienstwiederherstellung und bei gestoppten NTDS-Dienst anmelden (unter Angabe von: <Computername>\administrator).
2 = Bei diesem Wert, kann sich der Administrator für den Wiederherstellungsmodus jederzeit anmelden (unter Angabe von: <Computername>\administrator).
Den Verzeichnisdienstwiederherstellungs-Modus wie er bereits unter Windows 2000 und Windows Server 2003 existierte,
gibt es weiterhin auch unter Windows Server 2008.
Weitere Informationen:
Performing Offline Defragmentation of the Active Directory Database
Bei einer standortinternen (Intra-Site) Replikation kündigen die Domänencontroller (DC) vor der eigentlichen Replikation durch eine Änderungsbenachrichtigung
(Change Notification) die anstehende Replikation an. Sobald eine Änderung im Active Directory durchgeführt wurde, bekommen die Replikationspartner die sich
am gleichen Standort befinden eine Benachrichtigung. Das geschieht ab dem Gesamtstrukturfunktionsmodus „Windows Server 2003“ nach 15 Sekunden
(Initial Notification Delay). Falls der Quell-DC mehrere Replikationspartner hat, wird jeder weitere DC nach weiteren 3 Sekunden benachrichtigt (Subsequent Notification Delay).
Befindet sich der Gesamtstrukturfunktionsmodus nicht mindestens auf „Windows Server 2003“, sind es 300 Sekunden für eine Replikationsankündigung
und weitere 30 Sekunden Wartezeit für die weiteren Replikationspartner.
Die standortübergreifende Replikation findet nach einem Zeitplan (Standardeinstellung alle 180 Minuten) statt. Das Intervall kann zwischen
min. 15 bis max. 10.080 Minuten betragen und lässt sich im Snap-In „Active Directory-Standorte und –Dienste“ konfigurieren.
Die standortinterne (Intra-Site) Replikation nutzt die Benachrichtigung sowie Pull Methode, die wie folgt aussieht:
-
Auf einem DC wird eine Änderung an einem Objekt vorgenommen oder es wurde eine Änderung von einem anderen DC repliziert.
-
Danach wartet der DC 15 Sekunden (ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 300 Sekunden in allen vorherigen Ebenen)
nach der ersten Änderung und sendet anschließend eine Änderungsbenachrichtigung an seine direkten Replikationspartner am gleichen Standort.
Um genau zu sein, werden die Änderungsbenachrichtigungen nur jenen Replikationspartnern zugesandt, die ebenfalls die Verzeichnispartition in der
die Änderung vollzogen wurde besitzen. Jeder weitere Replikationspartner des Quell-DCs wird im Abstand von 3 Sekunden
(ab der Gesamtstrukturfunktionsebene „Windows Server 2003“ bzw. 30 Sekunden in allen vorherigen Ebenen) benachrichtigt.
Wenn die Änderungsbenachrichtigung zeitgleich an alle Replikationspartner versandt werden würde (Initial Notification Delay),
könnte dies zu einer Überlastung auf dem Quell-DC führen.
Daher wird jeder Replikationspartner mit einem Abstand (Subsequent Notification Delay) benachrichtigt.
-
Der Ziel-DC fordert danach die Änderungen von dem Quell-DC der die Benachrichtigung versandt hat an.
Falls weitere Replikationsanforderungen anstehen, werden diese erst abgearbeitet, wenn die vorherige Replikation abgeschlossen wurde.
Dabei verwendet das Active Directory die Pull-Replikation, die effektiver als eine Push-Replikation ist.
Bei einer Push-Replikation ist es schwierig zu erkennen, welche Änderungen dem Ziel-DC noch fehlen. Daher würde unnötig Replikationslast erzeugt,
wenn sich bereits die Informationen evtl. auf dem Ziel-DC befinden.
Möchte man die Zeit der Replikationsankündigung sowie der Verzögerung verändern, so geht das auf folgenden beiden Wegen:
-
In der Registry gilt es im Pfad „HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters“
die beiden DWORD-Schlüssel „Replicator notify pause after modify (secs)“ und „Replicator notify pause between DSAs (secs)“ zu erstellen
(falls diese nicht existieren). Als Wert trägt man die Zeit in Sekunden ein.
Ein anderer Weg wäre die Zeit für die einzelnen Verzeichnispartitionen zu definieren. Das geht, in dem die beiden Attribute
ms-DS-Replication-Notify-First-DSA-Delay sowie ms-DS-Replication-Notify-Subsequent-DSA-Delay des jeweiligen Cross-Reference Objekts
der entsprechenden Verzeichnispartition bearbeitet werden. Bearbeiten lässt sich das ganze über ADSIEdit.msc das sich in den
Windows Support Tools befindet. Die Cross-Reference Objekte befinden sich im Container Partitions der Konfigurationspartition.
Falls an beiden Stellen (Registry sowie an dem Cross-Reference Objekt) Änderungen vorgenommen wurden, so hat die Registry-Einstellung Vorrang.
Die dringende AD-Replikation (Urgent Replication)
Die dringende AD-Replikation wird für bestimmte wichtige Ereignisse verwendet.
Wie bei der standortinternen (Intra-Site) AD-Replikation basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen. Außer dass beim Eintreten eines
wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, anstatt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten.
Standardmäßig werden bei der dringenden AD-Replikation (aufgrund des hohen Replikationsaufkommens) Standortgrenzen nicht überschritten.
Die dringende AD-Replikation kann aber für die standortübergreifende (Inter-Site) AD-Replikation ebenfalls genutzt werden,
sofern die Benachrichtigungsfunktion in der Standortverknüpfung (Site-Link) konfiguriert wurde.
Auslöser einer dringenden AD-Replikation sind:
- Das Benutzerkonto wurde gesperrt, durch mehrmalige falsche Kennwort-Eingabe
- Das Bearbeiten der Kontosperrungsrichtlinie.
- Wenn die Kennwortrichtlinie bearbeitet wird.
- Bei Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität),
wenn z.B. das Computerkontokennwort eines DCs oder das Kennwort für eine Vertrauensstellung geändert wird.
- Wenn die RID-Master FSMO-Rolle auf einen anderen DC verschoben wird.
Bei der Kennwort-Änderung gilt allerdings folgendes:
Findet z.B. eine Benutzer-Kennwortänderung auf einem DC statt, so repliziert der DC die Information (durch den sicheren Kanal) umgehend an den DC, der die Rolle des PDC-Emulators innehat. Wenn sich der Benutzer nun an einem anderen DC, der noch nicht die Benachrichtigung der Kennwort-Änderung erhalten hat anmelden möchte, erkennt dieser ein „anderes“ Kennwort und kontaktiert somit den PDC-Emulator um nachzufragen, ob zwischenzeitlich eine Kennwort-Änderung stattgefunden hat.
Siehe auch: Die dringende AD-Replikation
Die Änderungsbenachrichtigung für die standortübergreifende (Inter-Site) AD-Replikation aktivieren
Seit Windows 2000 lässt sich die Replikationsankündigung (Change Notification) über Standortgrenzen hinweg konfigurieren. Dies geht auf folgende Weise:
Mit ADSIEdit gilt es das Attribut Options der entsprechenden Standortverknüpfung (Site-Link) zu bearbeiten.
Die Standortverknüpfungen befinden sich in der Konfigurationspartition. Der Pfad für die IP-Replikation wäre:
CN=<Site-Link-Objekt-Name>,CN=IP,CN=Inter-Site Transports,CN=Sites,CN=Configuration,DC=<Domäne>,DC=<TLD>
Dort wählt man die Eigenschaften der entsprechenden Standortverknüpfung aus und navigiert zum Attribut Options.
Als Standardwert ist <Not Set> eingestellt und dieses gilt es auf 1 zu ändern. Ist in dem Attribut bereits ein Wert enthalten,
gilt es diesen Wert lediglich um +1 zu erhöhen. Also wenn das Attribut Options den Wert 2 hat, muss als neuer Wert 3 eingetragen werden.
Hinweis: Für die SMTP-Replikation kann man die Änderungsbenachrichtigung nicht aktivieren!
Weitere Informationen:
Domänen- und Gesamtstrukturfunktionsmodus
Account Unlocks and Manual Password Expirations Are Not Replicated Urgently
Advanced Replication Management
How the Active Directory Replication Model Works
CrossRef-Referrals
Wenn ein Objekt im Active Directory gelöscht wird, verschwindet das Objekt nicht sofort aus dem Verzeichnis. Denn in größeren Gesamtstrukturen
mit einer komplexen Replikationstopologie könnte es durchaus vorkommen, dass ein Domänencontroller der von dieser Löschung noch nichts mitbekommen hat,
dass Objekt zurückrepliziert. Deshalb werden (weiter unten stehende) diverse Attribute eines Objekts behalten und als gelöscht markiert.
Anschließend wird dieser Datensatz auf alle anderen Domänencontroller repliziert. Auf diese Art ist sichergestellt, dass jeder Domänencontroller von dieser
Löschung informiert wird. Dieser Ansatz wird als Tombstone (Grabstein) bezeichnet, denn den Grabstein muss das gelöschte Objekt für einen bestimmten
Zeitraum, nämlich die Tombstone Lifetime (TSL), mit sich herumtragen. Die Tombstone Lifetime definiert, in welchem Zeitraum ein gelöschtes Objekt im
Active Directory wiederhergestellt werden kann.
Wenn ein Objekt gelöscht wird, werden folgende Änderungen an dem Objekt vorgenommen:
- Das Attribut des gelöschten Objekts Is-Deleted wird auf TRUE gesetzt,
wenn das löschen nicht durch das gesetzte Bit (0x80000000) im System-Flags Attribut des Objekts verhindert wird.
- When-Deleted ist eine interne Eigenschaft und besitzt keinen LDAP-Namen. Diese Eigenschaft bekommt den Wert (Timestamp) aus dem
Attribut Is-Deleted.
- Das Attribut NT-Security-Descriptor bekommt einen speziellen Wert.
- Der Common Name (CN) wird zu einem Wert geändert, der anderweitig von keinem LDAP Programm gesetzt werden kann.
Wenn z.B. das Benutzerobjekt „Yusuf Dikmenoglu“ gelöscht wird, bekommt es nach dem löschen einen bestimmten Wert und der
Distinguished Name (DN) würde wie folgt lauten:
„CN=Yusuf Dikmenoglu\0ADEL:ee3570c0-2664-4947-bde0-4dcbb55a8a23,CN=Deleted Objects,DC=<Domäne>,DC=<TLD>“
(CN=<alter RDN>\0ADEL:<Object-GUID>).
-
Das Objekt wird in den versteckten Container Deleted Objects (CN=Deleted Objects,DC=<Domäne>,DC=<TLD>) verschoben,
der in fast allen Verzeichnispartitionen enthalten ist, außer der Schemapartition. Natürlich nur dann, wenn im System-Flags Attribut des Objekts das verschieben
durch den Wert "67108864 (0x04000000)" nicht verhindert wurde.
-
Der Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem Domänencontroller läuft, entfernt alle nicht mehr benötigten
Attribute eines gelöschten Objekts. Das Intervall kann im Attribut garbageCollPeriod das sich im folgenden Pfad der Konfigurations-Partition befindet,
konfiguriert werden: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domäne>,DC=<TLD>.
Schließlich ist es auch der Garbage Collection Prozess, der das gelöschte Objekt nach Ablauf der Tombstone Lifetime dauerhaft aus dem
Verzeichnisdienst entfernt. Als Kriterium zur endgültigen Löschung des Objekts dient die Zeit, die in When-Deleted angegeben ist.
Weiterhin führt der Prozess eine online Defragmentierung der Active Directory-Datenbank NTDS.DIT durch. Das Löschen von Objekten
verkleinert die physikalische Dateigröße der Active Directory-Datenbank NTDS.DIT allerdings nicht. Dazu wäre eine Offline-Defragmentierung notwendig,
was aber i.d.R. nicht erforderlich ist. Die online Defragmentierung reicht völlig aus.
-
Diverse Attribute bleiben in einem gelöschten Objekt (Tombstone) erhalten. Diese wären:
Attribute-ID, Attribute-Syntax, Distinguished Name, DN-Reference-Update, DNS-Host-Name, Flat-Name, Governs-ID, Group-Type,
Is-Deleted, Instance-Type, Last-Known-Parent, LDAP-Display-Name, Legacy-Exchange-DN, MS-DS-Creator-SID, MSMQ-Owner-ID, NC-Name,
Object-Class, Object-GUID, Object-SID, OM-Syntax, Proxied-Object-Name, Repl-Property-Meta-Data, SAM-Account-Name, Security-Identifier,
SID-History (ab Windows Server 2003), Sub-Class-Of, System-Flags, Trust-Attributes, Trust-Partner,Trust-Direction, Trust-Type,
User-Account-Control, USN-Changed, USN-Created, When-Created.
Zusätzlich bleiben noch die Attribute erhalten, die einen gesetzten Wert im Attribut Search-Flags haben.
Das Active Directory speichert aber weder Forward- noch Backwardlink-Attribute im Tombstone, selbst dann nicht,
wenn es im Search-Flags Attribut des Objekts eingestellt wurde.
- Welche Attribute eines gelöschten Objekts erhalten bleiben, entscheidet das vierte Bit (in Dezimal 8) des Attributs Search-Flags.
- Es werden keine Forward- sowie Backwardlink-Attribute im Tombstone gespeichert, auch nicht, wenn dies im Search-Flag Attribut eingestellt wäre.
Neben den beiden Attributen objectCategory und samAccountType, wird auch das Attribut memberOf immer von einem gelöschten Objekt entfernt.
- Wenn das Objekt auf einem Windows Server 2003 (oder höher) Domänencontroller gelöscht wurde, so wird der Ursprungsort des Objekts im Attribut
Last-Known-Parent gespeichert.
Gelöschte Objekte werden in keinem Snap-In wie z.B. „Active Directory-Benutzer und -Computer“ oder ADSIEdit angezeigt,
stattdessen können diese mit LDP.exe aus den Windows Support Tools angezeigt werden.
Wie entstehen Lingering Objects (veraltete Objekte)?
Die Namensauflösung spielt wie so oft, bei der Replikation eine wichtige Rolle. Denn Windows 2000 sowie
Windows Server 2003 Domänencontroller führen vor der eigentlichen Replikation DNS-Lookups durch. Es wird versucht den GUID-Teil des
CNAME-Records das sich in der Zone _msdcs.<Root-Domäne> befindet, des Replikationspartners, in eine IP-Adresse aufzulösen.
Somit wird sichergestellt, dass der Replikationspartner erreicht und aufgelöst werden kann. Falls Lookups nicht durchgeführt werden können,
kann keine Replikation stattfinden und somit besteht die Gefahr, dass veraltete Objekte entstehen.
Folgende Fehlersituationen können dazu führen, dass ein DC länger keine Replikation durchführen kann:
Diese Fehlerquellen könnten dafür sorgen, dass sich ein Domänencontroller nicht ordnungsgemäß replizieren kann und dadurch von
den Löschungen die das Active Directory tätigt, nichts mitbekommt. Objekte die auf allen anderen Domänencontrollern gelöscht wurden,
bleiben auf dem Domänencontroller erhalten. Da der Domänencontroller während der Tombstone-Lebensdauer nicht erreichbar (offline) war,
bekommt dieser während diesem Zeitraum nicht die gelöschten Informationen (Tombstone) repliziert. Solche Objekte werden als
Lingering Objects (veraltete Objekte) bezeichnet.
Wenn nun aber der längerfristig vom Netzwerk getrennte Domänencontroller erneut ins Netzwerk integriert wird, könnte es vorkommen,
dass dieser eines der gelöschten Objekte erneut auf alle Domänencontroller der Domäne repliziert. Dieses tritt z.B. dann auf, wenn auf dem
„veralteten“ Domänencontroller eines der gelöschten Objekte bearbeitet wird. Nach der Änderung am entsprechenden Objekt, repliziert das
Active Directory die Änderung auf einen Domänencontroller, auf diesem das Objekt - verursacht durch die Löschung - nicht mehr vorhanden ist.
Daraufhin hat der Ziel-Domänencontroller der die Replikation empfängt, folgende Möglichkeiten:
-
Ein Domänencontroller zeichnet auf, wann die letzte Replikation stattgefunden hat. Wenn die Tombstone Lifetime verstrichen ist und danach ein veralteter Domänencontroller versucht sich mit einem „aktuellen“ Domänencontroller zu replizieren, wird folgende Fehlermeldung im Verzeichnisdienstprotokoll protokolliert:
Event-ID: 2042 Quelle: NTDS Replication
Es ist zu lange her, dass dieser Computer zuletzt mit dem genannten Quellcomputer repliziert hat. Die Zeit zwischen den Replikationen mit dieser
Quelle hat die Tombstone-Ablaufzeit überschritten. Die Replikation mit dieser Quelle wurde beendet. Der Grund dafür, dass das Fortsetzen der
Replikation nicht zugelassen wird, ist, dass die Sicht der beiden Computer in Bezug auf gelöschte Objekte sich nun ggf. unterscheidet.
Der Quellcomputer hat ggf. noch Kopien von Objekten, die auf diesem Computer gelöscht (und in die Sammlung veralteter Objekte aufgenommen)
wurden. Würde der Replikation zugelassen, könnte der Quellcomputer Objekte zurückgeben, die bereits gelöscht wurden. Zeitpunkt der letzten
erfolgreichen Replikation: 2006-08-09 08:36:24 Aufrufkennung der Quelle: 43b8e6bd-h4bf-16a8-571c-6f2346653c02 Name der Quelle:
432cb837-e36c-37h3-ge5b-63egf24a1478._msdcs.<Domäne>.<TLD>.
Tombstone-Ablaufzeit (Tage): 60 usw.
In der Beschreibung werden dann folgende Lösungswege vorgeschlagen:
1. Stufen Sie den/die Computer herunter, die getrennt wurden, oder installieren Sie ihn/sie neu.
Da sich der Domänencontroller nicht ordnungsgemäß repliziert, muss zum herunterstufen (wenn diese Lösung gewählt wird) das
DCPROMO Kommando mit dem Schalter /FORCEREMOVAL ausgeführt und anschließend das Active Directory bereinigt werden:
Das Active Directory gewaltsam vom DC entfernen
How to remove data in Active Directory after an unsuccessful domain controller demotion
2. Verwenden Sie das Tool „Repadmin /removelingeringobjects", um inkonsistent gelöschte Objekte zu entfernen
und setzen Sie dann die Replikation fort.
Mit dem angegebenen Befehl, werden die veralteten Objekte entfernt. Anschließend gilt es die Replikation zu forcieren.
Dieses ist mit folgendem Befehl möglich: REPADMIN /Repl <Ziel-DC> <Alt-DC> dc=<Domäne>,dc=<TLD> /Force.
Dadurch lässt sich das Problem für die angegebene Verzeichnispartition beheben. Wenn nun die Replikation erneut startet,
kann der gleiche Fehler, diesmal für eine andere Verzeichnispartition protokolliert werden. Deshalb muss der REPADMIN-Befehl für
alle einzeln angegebenen Verzeichnispartitionen (Schemapartition, Konfigurationspartition, DomainDNSZones, ForestDNSZones) und
für alle weiteren existierenden Anwendungsverzeichnispartitionen durchgeführt werden. Für den Fall, dass auf dem DC der GC aktiviert ist,
so gilt es dieses durchzuführen:
Lingering objects may remain after you bring an out-of-date global catalog server back online
3. Setzen Sie die Replikation fort. Möglicherweise werden inkonsistent gelöschte Objekte eingeführt. Sie können die Replikation fortsetzen,
indem Sie den folgenden Registrierungsschlüssel verwenden. Es wird empfohlen, zur Wiederherstellung des Schutzes den Schlüssel zu entfernen,
sobald das System ein Mal repliziert hat. Registrierungsschlüssel:
HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Allow Replication With Divergent and Corrupt Partner
Repliziert sich ein DC während der Tombstone Lifetime nicht mit anderen DCs, besteht die Gefahr,
dass auf diesem veraltete Objekte entstehen. Tritt dieser Fall ein, blockiert der Ziel-DC die eingehende (In-Bound) Replikation mit
dem „veralteten“ DC und protokolliert im Verzeichnisdienstprotokoll die Fehler-ID 2042 mit der Beschreibung wie sie hier aufgeführt ist.
Anschließend sollten die veralteten Objekte entfernt werden (weiter unten beschrieben). Für die erneute Replikation ist der folgende Wert
in der Registry zu setzen:
HKLM\System\CurrentControlSet\Services\Ntds\Parameters
Allow Replication With Divergent and Corrupt Partner
REG_DWORD
Value: 1
Der Wert in diesem Fall ist auf 1 zu setzen, damit die Replikation auf dem Ziel-Domänencontroller durchgeführt werden kann.
Wenn diese Einstellung vorgenommen wurde, ist kein Neustart des DCs notwendig.
Existiert dieser Registry-Schlüssel (der nur unter Windows Server 2003 DCs gültig ist) nicht, so gilt es diesen zu erstellen.
Diese Einstellung wäre z.B. für eine Testumgebung mit virtuellen Maschinen, die über einen längeren Zeitraum nicht in Nutzung waren das richtige.Event ID 2042: It has been too long since this machine replicated
Es sollte unbedingt darauf geachtet werden, wenn diese Einstellung in einer produktiven Umgebung eingesetzt wird,
dass nach der Replikation diese Einstellung auf 0 gesetzt wird, damit die Replikation vor veralteten Objekten geschützt werden kann!
Falls auf dem Ziel-Domänencontroller die strikte Replikationskonsistenz (Strict Replication Consistency) aktiviert ist und er eine Anfrage für die
Aktualisierung eines lokal nicht vorhandenen Objekts erhält, erkennt dieser, dass er das Objekt nicht aktualisieren kann (weil es nicht vorhanden ist)
und stoppt somit die eingehende (In-Bound) Replikation der Verzeichnispartition in dem sich das veraltete Objekt befindet.
Die Einstellung der Replikationskonsistenz (strikte oder nicht strikte) bestimmt das Verhalten eines Domänencontrollers bzgl. der Aktualisierung
von AD-Objekten die nicht mehr in seiner lokalen Datenbank vorhanden sind. Wenn also der Ziel-Domänencontroller (der DC, der das veraltete
Objekt empfangen soll) ein veraltetes Objekt vom Quell-Domänencontroller entdeckt, verschiebt der Ziel-DC die zu empfangende Verzeichnispartition
in der sich das veraltete Objekt befindet, in eine Art Quarantäne. Die Quarantäne wird erst dann aufgehoben, wenn entweder das veraltete Objekt
entfernt wird oder der Ziel-DC die Loose Replication Consistency aktiviert hat.
Standardmäßig ist die strikte Replikationskonsistenz bei einer Migration von NT 4.0 auf Windows Server 2003 oder wenn eine Gesamtstruktur
ab Windows Server 2003 erstellt wurde aktiviert. Die Funktion des Strict Replication Consistency steht ab Windows 2000 Server SP3
(sogar schon mit Post-SP2 Hotfix) zur Verfügung, diese ist aber unter Windows 2000 standardmäßig deaktiviert. Bei aktivierter Einstellung
wird die Ereignis-ID 1988 im Verzeichnisdienstprotokoll des Ziel-DCs protokolliert.
Die Lösung für diesen Fehler wäre, mit dem Befehl REPADMIN /removelingeringobjects die veralteten Objekte von dem Domänencontroller
der diese enthält zu entfernen. Dazu muss der Quell- sowie Ziel-Server ein Windows Server 2003 Domänencontroller sein.
Die Einstellung für die strikte Replikationskonsistenz, kann in der Registry im folgenden Pfad vorgenommen werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Strict Replication Consistency
Data type: REG_DWORD
Value: 1
Hinweis: Das Heraufstufen des Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus ändert nicht die „Strict Replication Consistency“ Einstellung!
Falls diese Funktion auf dem Ziel-Domänencontroller deaktiviert ist (Value: 0), fordert dieser eine vollständige Replik (Kopie) des
Objekts an und fügt es in seine Verzeichnis-Datenbank hinzu. Die Deaktivierung dieser Einstellung wird als Loose Replication Consistency bezeichnet.
Wenn ein Domänencontroller unter Windows 2000 SP3 (oder höher), ein Windows 2000 Server auf Windows Server 2003 aktualisiert wurde oder
das Active Directory (DCPROMO) auf einem Windows Server 2003 Mitgliedsserver, dass Mitglied in einer Windows 2000 Gesamtstruktur ist,
installiert wurde, ist diese Option standardmäßig deaktiviert. Dabei wird die Ereignis-ID 1388 im Verzeichnisdienstprotokoll des Ziel-Domänencontrollers
(also der DC, der das nicht mehr existierende Objekt erneut repliziert bekommen soll) protokolliert.
Wird auf einem Domänencontroller die Ereignis-ID 1388 im Verzeichnisdienstprotokoll protokolliert, ist eine eingehende Replikation (In-Bound) von
einem veralteten Objekt aufgetreten. Ein Domänencontroller der die Loose Replication Consistency Einstellung aktiviert hat, bekommt eine Anfrage
für die Aktualisierung eines lokal nicht mehr vorhandenen Objekts. Der Ziel-Domänencontroller fordert danach vom Replikationspartner das vollständige
Objekt an. Der Quell-Domänencontroller (der das veraltete Objekt besitzt) repliziert es auf den Ziel-Domänencontroller und dieser fügt es in seine
Verzeichnisdatenbank hinzu.
Event ID 1388 or 1988: A lingering object is detected
Outdated Active Directory objects generate event ID 1988 in Windows Server 2003
Enable strict replication consistency
Fixing Replication Lingering Object Problems (Event IDs 1388, 1988, 2042)
Auf Domänencontrollern die mindestens unter Windows Server 2003 mit Service Pack 1 laufen, ist es nicht zwingend notwendig die Einstellung direkt in der Registry vorzunehmen. Stattdessen kann der Wert auch mit REPADMIN gesetzt werden.
Der Befehl würde folgendermaßen lauten:
REPADMIN /Regkey <DC-DNS-Name> +strict = Dieser Befehl aktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <DC-DNS-Name> -strict = Dieser Befehl deaktiviert auf dem angegebenen DC das „Strict Replication Consistency“.
REPADMIN /Regkey <*> +strict = Dieser Befehl aktiviert auf allen DCs der Gesamtstruktur das „Strict Replication Consistency“.
Natürlich nur auf DCs, die unter Windows Server 2003 SP1 laufen.
Anstatt den DNS-Namen des Domänencontrollers anzugeben, kann man auch den Distinguished Name des Domänencontroller-Computerobjekts verwenden.
Falls die Loose Replication Consistency aktiviert und das Objekt repliziert wurde, sollte anschließend diese Einstellung rückgängig gemacht werden.
Zusammenfassend lässt sich ableiten, dass sich ein Domänencontroller vor “veralteten Objekten” auf zweierlei Art schützt.
Zum einen durch die Tombstone Lifetime und zum anderen durch die aktivierte Replikationskonsistenz (Strict Replication Consistency).
Damit erst keine veralteten Objekte entstehen, sollte regelmäßig die Replikation überprüft werden. Falls Replikationsprobleme bestehen,
werden diese durch Fehlermeldungen z.B. in einer Ausgabe von REPADMIN oder durch Ereignisse protokolliert.
Sollen lediglich Replikationsfehler angezeigt werden, so ist der Befehl REPADMIN /Showrepl /Errorsonly auszuführen.
Mit dem Befehl REPADMIN /SHOWREPL * /CSV > C:\Repadmin.csv kann die Ausgabe in eine Datei exportiert werden.
Mit der Eingabe REPADMIN /Experthelp bekommt man eine ausführlichere Hilfe des Befehls REPADMIN angezeigt, als mit REPADMIN /?.
Repadmin Syntax
Auch mit DCDIAG kann die Replikation überprüft werden:
DCDIAG /Test:Replications
Auf Windows Server 2003 mit SP1 kann folgender Befehl ausgeführt werden:
DCDIAG /Test:CheckSecurityError oder DCDIAG /Test:CheckSecurityError /s:<DC-Name>.
Eine weitere Möglichkeit wäre, das Attribut tombstoneLifetime mit ADSIEdit im Pfad:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Domain>,DC=<TLD> zu erweitern.
Wobei in produktiven Umgebungen der Standard nicht verändert werden sollte!
Lingering objects prevent Active Directory replication from occurring
Information about lingering objects in a Windows 2000-based forest or in a Windows Server 2003-based forest
Wie kann man Lingering Objects (veraltete Objekte) entdecken und entfernen?
Ab Windows Server 2003 steht dem Administrator das Tool REPADMIN, dass Bestandteil der Windows Support Tools ist, zur Verfügung.
Damit ist es möglich, veraltete Objekte aufzuspüren und aus dem Verzeichnisdienst zu entfernen.
Der Schalter der dazu benötigt wird lautet /removelingeringobjects. Dieser Schalter prüft die Objekte auf einem Referenz-Domänencontroller
und vergleicht diese mit den Objekten des „veralteten“ Domänencontrollers (dem DC, auf dem gegebenenfalls veraltete Objekte vorhanden sind).
Zuerst sollte man sich die veralteten Objekte anzeigen lassen. Dies geht z.B. mit folgendem Befehl (bei aktiviertem Strict Replication Consistency):
REPADMIN /removelingeringobjects <DNS-Name des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten
Objekte befinden> /Advisory_Mode.
Als Beispiel:
Repadmin /removelingeringobjects alterdcon.intra.dikmenoglu.de FB1E6374-47A3-23C8-DE2F-3685A2F79268 DC=intra,DC=dikmenoglu,DC=de /Advisory_Mode
Hinweis: Um die GUID eines DCs herauszufinden, kann man z.B. den Befehl REPADMIN /Showrepl <DC-Name> eingeben.
Der Parameter /Advisory_Mode protokolliert dabei im Verzeichnisdienstprotokoll die Ereignis-ID 1946 für jedes existierende veraltete Objekt.
Wenn nun der gleiche Befehl, aber diesmal ohne den Parameter /Advisory_Mode ausgeführt wird, werden alle aufgelisteten veralteten Objekte
vom veralteten Domänencontroller entfernt. Dabei wird die Ereignis-ID 1945 im Verzeichnisdienstprotokoll protokolliert.
Weiterhin kann man sich mit dieser Abfrage, Konflikt-Objekte anzeigen lassen:
dsquery * forestroot -gc -attr distinguishedname -scope subtree -filter „(name=*CNF:*)“
Das Verzeichnisdienstprotokoll liefert bei veralteten Objekten ebenfalls wichtige Informationen.
The Repadmin.exe tool does not report existing lingering objects in Windows Server 2003
Event ID 2108 and Event ID 1084 occur during inbound replication of Active Directory in Windows 2000 Server and in Windows Server 2003
Weitere Informationen:
Windows Server Tombstone-Wiederbelebung in Active Directory -- TechNet Magazine, September 2007
Creating and Deleting Objects in Active Directory Domain Services
Viewing deleted objects in Active Directory
Deleting Items from Active Directory
Phantoms, tombstones and the infrastructure master
How the Active Directory Replication Model Works
Replication Collisions in Windows 2000
Dem Administrator steht seit Windows Server 2003 in der Microsoft Management Console (MMC) Active Directory-Benutzer und –Computer (dsa.msc)
die Funktion Gespeicherte Abfragen zur Verfügung. In diesem Ordner hat man die Möglichkeit Abfragen zu erstellen, bearbeiten und zu speichern.
Dabei ist es auch möglich, eigene benutzerdefinierte Abfragen zu erstellen. Abfragen wurden früher aufwändig mit ADSI-Skripten erstellt.
Heute lässt es sich „recht einfach“ in dem Snap-In „Active Directory-Benutzer und –Computer“ definieren.
Somit hat der Administrator die Möglichkeit, wiederkehrende Abfragen nicht jedes Mal neu zu erstellen,
sondern die bereits getätigten Abfragen erneut zu nutzen.
Die durchgeführten Abfragen werden unter dem angemeldeten Benutzerkonto automatisch nur in der MMC gespeichert, in der sie durchgeführt wurden.
Auch wenn man sich mehrere MMCs mit dem Snap-In „Active Directory-Benutzer und –Computer“ erstellt, wird die Abfrage nur in der einen MMC gespeichert,
in der sie durchgeführt wurde. Man könnte aber eine MMC erstellen (Start-Ausführen-MMC), in dieser das Snap-In „Active Directory-Benutzer und –Computer“
hinzufügen, die gewünschten Abfragen tätigen und die MMC (als MSC-Datei) auf einem Netzlaufwerk speichern, damit andere Kollegen diese nutzen können.
Des Weiteren besteht die Möglichkeit, die Abfragen im XML-Format zu exportieren und in einer anderen MMC bzw. auf einem anderen Client, zu importieren.
Eine Abfrage erstellt man folgendermaßen:
- Zuerst gilt es das Snap-In Active Directory-Benutzer und –Computer zu starten.
- Mit einem Rechtsklick auf Gespeicherte Abfragen gilt es das Kontextmenü aufzurufen.
- Anschließend wählt man den Punkt Neu und bekommt die Auswahl zwischen Abfrage und Ordner.
Durch erstellen von Ordnern kann man sich eine eigene Abfrage-Struktur aufbauen und lässt sich dadurch, besser verwalten.
- Wurde der Punkt Abfrage ausgewählt, öffnet sich als nächstes ein Fenster das Neue Abfrage lautet.
Dort ist es möglich, der zu erstellenden Abfrage einen Namen und eine Beschreibung, die die eigentliche Abfrage evtl. etwas erläutert, einzugeben.
- Im Feld Abfragestamm gilt es den Container auszuwählen (mit Durchsuchen), im dem die Suche starten soll.
Möchte man alle untergeordneten Container des ausgewählten Containers in die Suche mit einbeziehen, so ist es notwendig das Kontrollkästchen
Untergeordnete Container miteinbeziehen zu aktivieren.
- Als nächstes gilt es mit einem Klick auf Festlegen… die gewünschte Abfrage zu definieren.
Der Vorteil an dieser Aufgabe ist, dass keinerlei administrative Rechte notwendig sind. Daher bietet es sich an, das Adminpak (von einem
Windows Server 2003 DC oder Mitgliedsserver aus dem Verzeichnis %windir%\system32\adminpak.msi) auf einer Admin-Workstation
zu installieren und die Abfrage mit Benutzerrechten auszuführen. Möchte man z.B. nur die Active Directory Snap-Ins installieren,
so lässt sich das auf folgende Art realisieren:
msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb
How to use Adminpak.msi to install a specific server administration tool in Windows
Beispiel LDAP-Abfragen
Möchte man z.B. eine eigene Abfrage definieren, so vergibt man der Abfrage einen Namen und wenn gewünscht eine Beschreibung,
wählt anschließend den Abfragestamm und klickt auf Festlegen… Im darauf erscheinenden Fenster gilt es im Feld Suchen:
die Benutzerdefinierte Suche auszuwählen. Anschließend muss im Reiter Erweitert der LDAP-Filter eingegeben werden.
Im folgenden sind einige LDAP-Filter aufgeführt.
Benutzer Filter
Alle Benutzer die eine E-Mail Adresse in den Benutzereigenschaften eingetragen haben, können mit diesem LDAP-Filter angezeigt werden:
(objectCategory=person)(mail=*)
Möchte man nur die Benutzer angezeigt bekommen, die keine E-Mail Adresse eingetragen haben, so wäre dieser Filter zu verwenden:
(objectCategory=person)(!mail=*)
Alle gesperrten Benutzer anzeigen (zu oft falsch eingegebenes Kennwort):
(&(objectCategory=Person)(objectClass=User)(lockoutTime>=1))
Benutzerkonten die ab dem 01.01.2010 erstellt wurden, kann man sich mit folgendem Filter anzeigen lassen:
(objectCategory=person)(whenCreated>=20100101000000.0Z)
Alle aktiven Benutzerkonten (also keine deaktivierten Benutzer) anzeigen, die ab dem 01.01.2010 erstellt wurden
(&(sAMAccountType=805306368)(whenCreated>=20100101000000.0Z)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Alle Benutzerkonten anzeigen, die nach dem 01.01.2010 geändert wurden:
(&(sAMAccountType=805306368)(whenChanged>=20100101000000.0Z))
Alle Benutzer anzeigen, die sich seit dem 10.01.2010 nicht mehr angemeldet haben:
(&(&(objectCategory=person)(objectClass=user)(LastLogonTimeStamp<=129076122047040000)))
Alle "aktivierten" (und keine deaktivierten) Benutzer anzeigen, die bei der nächsten Anmeldung ihr Kennwort ändern müssen:
(objectCategory=person)(objectClass=user)(pwdLastSet=0)(!useraccountcontrol:1.2.840.113556.1.4.803:=2)
Alle Benutzer die bei ihrer nächsten Anmeldung ihr Kennwort ändern müssen, lassen sich auf diese Art anzeigen:
(&(objectCategory=person)(pwdLastSet=0))
Der LDAP-Filter der alle deaktivierten Benutzerkonten anzeigt, wäre dieser:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
Der Filter zum anzeigen von nicht deaktivierten Benutzerkonten (also lediglich aktive Benutzerkonten), sieht wie folgt aus:
(&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
Die Abfrage würde mit Dsquery zusammen mit Dsget wie folgt aussehen:
Dsquery User <DN des Containers> | Dsget User -samid -disabled
Um sich alle Benutzer anzuzeigen, die Mitglied einer bestimmten Gruppe sind, wäre dieser LDAP-Filter anzuwenden:
(objectCategory=user)(memberOf=CN=Techniker,CN=Users,DC=intra,DC=dikmenoglu,DC=de)
In diesem Beispiel befindet sich die Gruppe Techniker im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.
Damit alle Benutzer angezeigt werden, die nicht in einer bestimmten Gruppe Mitglied sind, gilt es diesen Filter zu verwenden:
(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))
Mit Dsquery würde die Abfrage folgendermaßen aussehen:
dsquery * domainroot -filter "(&(objectCategory=person)(objectClass=user)(!memberof=CN=GRUPPE,CN=Users,DC=DOMÄNE,DC=TLD))" -limit 1000
Die Benutzerkonten bei denen in den Benutzereigenschaften das Kontrollkästchen Kennwort läuft nie ab (z.B. bei Dienstkonten) aktiviert sind, lassen sich auf diese Weise anzeigen:
(&(objectcategory=user)(userAccountControl:1.2.840.113556.1.4.803:=65536))
Alle Benutzer anzeigen, die nichts im Profilpfad eingetragen haben:
(&(objectCategory=person)(!profilepath=*))
Alle Benutzer anzeigen, die KEIN LoginSkript eingetragen haben:
(&(objectcategory=person)(!scriptPath=*))
Alle Benutzer anzeigen, die ein bestimmtes LoginSkript eingetragen haben:
(&(objectCategory=person)(scriptPath=Login.bat))
Alle Benutzer anzeigen, die sich noch NIE angemeldet haben:
(&(objectCategory=person)(objectClass=user))(|(lastLogon=0)(!(lastLogon=*)))
Alle Benutzer anzeigen, die KEINEN Vorgesetzten eingetragen haben:
(&(objectCategory=person)(!directreports=*))
Alle Objekte anzeigen, in im Feld Abteilung, Beschreibung oder Firma "AD" eingetragen haben:
(|(department=AD)(company=AD)(description=AD))
Alle Benutzerkonten anzeigen, die keine Beschreibung haben:
(&(objectCategory=person)(!description=*))
Alle Benutzerkonten anzeigen, die am 01.01.2010 abgelaufen sind:
(&(objectCategory=person)(accountExpires=129068604000000000))
Alle Benutzer die eine Handynummer beginnend mit 0151 oder 0171 anzeigen:
(&(objectCategory=person)(|(mobile=0151*)(mobile=0171*)))
Alle Benutzer mit dem Vornamen "Yusuf" anzeigen:
(&(objectCategory=person)(CN=Yusuf*))
Alle Benutzer mit dem Vornamen Yusuf oder Kaan anzeigen:
(objectCategory=person)(|(CN=Yusuf*)(CN=Kaan*))
Alle Benutzer anzeigen, die sich einwählen dürfen:
(&(objectCategory=person)(msNPAllowDialin=TRUE))
Alle Benutzer anzeigen die 2 Mal (oder mehr) ihr Kennwort falsch eingegeben haben:
(&(objectCategory=person)(badPwdCount>=2))
Alle Benutzer anzeigen, ausser Fritz:
(&(objectCategory=person)(!cn=Fritz*))
Gruppen Filter
Alle domänenlokale-, globale- und universelle Sicherheitsgruppen werden hiermit angezeigt:
(groupType:1.2.840.113556.1.4.803:=2147483648)
Alle domänenlokale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483644))
Alle globale Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483646))
Alle universellen Sicherheitsgruppen anzeigen:
(&(objectCategory=group)(groupType=-2147483640))
Alle domänenlokale Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=4))
Alle Verteilergruppen anzeigen:
(&(objectCategory=group)(!groupType:1.2.840.113556.1.4.803:=2147483648))
Alle globale Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=2))
Alle universelle Verteilergruppen anzeigen:
(&(objectCategory=group)(groupType=8))
Alle Gruppen anzeigen, die keine Mitglieder enthalten (also leere Gruppen):
(&(objectClass=group)(!member=*))
Möchte man sich alle Gruppen anzeigen, in denen ein bestimmter Benutzer (direkt, nicht verschachtelt) Mitglied ist, so würde der Filter wie folgt aussehen:
(&(objectCategory=group)(member=CN=Yusuf,CN=Users,DC=intra,DC=dikmenoglu,DC=de))
In diesem Beispiel befindet sich der Benutzer Yusuf im Standard-Container Users und die Domäne lautet intra.dikmenoglu.de.
Alle Gruppenkonten anzeigen, die keine Beschreibung eingetragen haben:
(&(objectCategory=group)(!description=*))
Alle Gruppen anzeigen die mit "AD" oder "LDAP" anfangen:
(objectCategory=group)(|(CN=AD*)(CN=LDAP*))
Computer Filter
Alle NT4 Computer anzeigen:
(&(objectCategory=computer)(operatingSystemVersion=4*))
Alle Windows 2000 Computer in der Domäne anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 2000*))
Alle Windows Server 2003 mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2003)(OperatingSystemServicePack=Service Pack 1))
Alle Windows Server 2008 (aber kein 2008 R2) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server* 2008*)(!OperatingSystem=Windows Server 2008 R2*))
Alle Windows Server 2008 R2 (alle Editionen) anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Server 2008 R2*))
Alle deaktivierten Computer-Konten in der Domäne, lassen sich mit diesem Filter anzeigen:
(&(objectclass=computer)(userAccountControl:1.2.840.113556.1.4.803:=2))
Die Benutzer- sowie Computerkonten die eine Beschreibung enthalten, können mit diesem Filter aufgelistet werden:
(&(description=*)(|(objectCategory=computer)(objectCategory=user)))
Alle Domänencontroller anzeigen:
(&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))
Nur Windows Server 2003 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server 2003*))
Nur Windows Server 2003 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server 2003*))
Nur Windows Server 2008 DCs anzeigen:
(&(primaryGroupId=516)(objectCategory=computer)(operatingSystem=Windows Server* 2008*))
Nur Windows Server 2008 Mitgliedsserver anzeigen, aber KEINE DCs:
(&(samAccountType=805306369)(!(primaryGroupId=516))(objectCategory=computer)(operatingSystem=Windows Server* 2008*))
Alle Windows XP Clients mit Service Pack 2 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows XP*)(OperatingSystemServicePack=Service Pack 2))
Alle Windows Vista Clients mit Service Pack 1 anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows Vista*)(OperatingSystemServicePack=Service Pack 1))
Alle Windows 7 Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7*))
Alle Windows 7 "Ultimate" Clients anzeigen:
(&(objectcategory=computer)(OperatingSystem=Windows 7 Ultimate))
Alle globalen Kataloge (GCs) in der Gesamtstruktur anzeigen:
(&(objectCategory=nTDSDSA)(options:1.2.840.113556.1.4.803:=1))
Exchange Abfragen
Alle Kontakte einer Domäne die keiner Gruppe zugeordnet sind, werden mit dem folgenden Filter angezeigt:
(objectclass=contact)(!(memberof=*))
Alle Benutzer anzeigen, die nicht den Standardwert für ihre Exchange-Postfachgröße verwenden:
(&(objectCategory=user)(mDBUseDefaults=FALSE))
Alle Konten anzeigen die eine bestimmte Exchange Mailadresse eingetragen haben:
(&(objectClass=user)(proxyAddresses=SMTP:mail@blog.dikmenoglu.de))
Benutzer, Kontakte und Verteilergruppen die nicht in der GAL auftauchen (ausgenommen Public Folder):
(&(msExchHideFromAddressLists=TRUE)(!objectClass=publicFolder))
Alle Benutzer anzeigen, die keine Exchange Mailadresse (proxyAddresses) haben:
(&(objectCategory=person)(objectClass=user)(!proxyAddresses=*))
Weitere Informationen:
Gespeicherte Abfragen für dsa.msc
Search Filter Syntax
How to use the PrimaryGroupID attribute to find the primary group for a user
How to query Active Directory by using a bitwise filter
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|