Wie kann man kontrollieren, ob ein Domänencontroller auf dem der globale Katalog aktiviert wurde, auch als solcher agiert?
Der globale Katalog lässt sich bekanntermaßen im Snap-In „Active Directory-Standorte und –Dienste“ aktivieren. Aktivieren lässt er sich auch
mit REPADMIN (aus den Windows Support Tools). Der Befehl dazu lautet: REPADMIN /OPTIONS <DC> +IS_GC. Wer gerne ein Skript dazu verwenden möchte,
kann dieses ebenfalls tun oder verwendet z.B. dieses:
Enable a Global Catalog Server
In den meisten Fällen aber, wird das Snap-In verwendet. Der erste Blick sollte also an dieser Stelle (dssite.msc) geschehen, ob dort der Haken gesetzt ist.
Was aber, wenn der Haken bei Globaler Katalog existiert und der Domänencontroller trotzdem nicht als GC fungiert bzw. reagiert?
Der Domänencontroller auf dem der GC aktiviert wurde, gibt sich als solcher erst im Active Directory bekannt, nachdem er die Replikation aller
Domänenpartitionen die es in der Gesamtstruktur gibt, von seinen Replikationspartnern erhalten hat. Der GC hält eine beschreibbare Domänenpartition
der Domäne, in der er selbst Mitglied ist. Sowie schreibgeschützte Domänenpartitionen aller Domänen, die sich in der gleichen Gesamtstruktur befinden.
Bekannt geben heißt an dieser Stelle, dass der Domänencontroller dynamisch seine SRV-Einträge im DNS registriert.
Wird der Haken „Globaler Katalog“ in den Eigenschaften von NTDS Setting`s des jeweiligen DCs gesetzt, wird im Verzeichnisdienstprotokoll die Information
mit der Event-ID 1110 protokolliert. Standardmäßig wird das Intervall von fünf Minuten abgewartet, bevor der DC sich selbst als GC bekannt gibt.
In dieser Zeit werden die Informationen für den GC repliziert. Das Verhalten der Verzögerung lässt sich mit dem Registry-Eintrag
„HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\Global Catalog Delay Advertisement (sec)“ beeinflussen.
Wenn der Vorgang erfolgreich abgeschlossen wurde, muss zwingend dieser Eventlog-Eintrag erscheinen:
Event-ID: 1119
Der Domänencontroller ist jetzt ein globaler Katalog.
Danach registriert der NETLOGON Dienst des DC seine SRV-Einträge im DNS und ab jetzt nimmt er seine Aufgabe als GC wahr.
Ab dann hört er auch den TCP Port 3268 und TCP Port 3269 (für SSL-Verbindungen) ab.
Ob das herauf stufen zum GC abgeschlossen wurde, kann folgendermaßen geprüft werden:
-
Der Registry-Eintrag Global Catalog Promotion Complete im Schlüssel
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters mit dem Wert 1 muss existieren.
-
In der Kommandozeile lässt sich diese Information mit dem Tool NLTEST, das sich in den Windows Support Tools befindet herausfinden.
Der Befehl dazu lautet:
Nltest /dsgetdc:<Domänenname> /server:<DC-Name>
-
Ein weiteres Kommandozeilen-Tool mit dem sich die Information herausfinden lässt, wäre REPADMIN (ebenfalls in den Windows Support Tools).
Nach Eingabe des Befehls REPADMIN /Showreps DC erscheint in der zweiten Zeile der Eintrag „IS_GC“.
-
Wenn der Befehl TELNET DC-NAME 3268 in der Kommandozeile eingegeben wird, sollte daraufhin ein leeres Kommandozeilenfenster mit einem
blinkenden Cursor erscheinen. Das bedeutet, dass der angegebene DC auf dem Port 3268 abhört.
-
Das RootDSE Objekt enthält ein Attribut isGlobalCatalogReady mit dem Wert TRUE. Das Attribut kann z.B. mit LDP.exe überprüft werden.
Die Hauptverdächtigen, die beim aktivieren des GCs Probleme verursachen, sind meistens Replikationsprobleme sowie das DNS.
Bei der Fehlersuche ist der Einsatz der beiden Tools DCDIAG sowie NetDIAG hilfreich. Ein Blick in die Ereignisanzeige sollte ebenfalls geworfen werden.
Weitere Informationen:
Globaler Katalog (Global Catalog - GC)
How the Global Catalog Works
Möchte man die Personalnummern der Mitarbeiter in die Benutzerverwaltung mit eingeben, so kommt man unter Umständen auf den Gedanken,
dass Schema erweitern zu müssen da kein entsprechendes Feld für die Eingabe existiert.
Dabei existieren im Schema des Active Directory`s bereits zwei Attribute, nämlich Employee-ID sowie Employee-Number.
Deshalb ist es nicht nötig das Schema zu erweitern. Diese tauchen lediglich nicht in Form eines Feldes in einer MMC auf und genau das ist das Problem.
Was sich recht kompliziert bei dem erstellen eines Eingabe-Feldes in den bestehenden MMCs (z.B. im Snap-In Active Directory-Benutzer und
-Computer) darstellt, lässt sich verhältnismäßig einfach über das Kontextmenü eines Benutzerobjekts durchführen.
In diesem Beispeil, wird das Skript von Sakari Kouti verwendet:
-
Zuerst gilt es mit ADSIEdit das user-Display Objekt das sich in der Konfigurationspartition befindet (CN=user-
Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=<Domäne>,DC=<TLD>) aufzurufen.
-
Dort muss im Attribut adminContextMenu ein neuer Eintrag hinzugefügt werden:
<2, Personalnummer, C:\Skripte\employeeid.vbs> allerdings ohne die Klammern.
Der Eintrag bedeutet:
2 = Standardmäßig existiert bereits ein Eintrag der mit „1“ anfängt. Falls mehrere Einträge existieren sollten,
gilt es die nächste freie Zahl zu wählen.
Personalnummer = Dieser Eintrag wird im Kontextmenü des Benutzerobjekts angezeigt.
C:\Skripte\employeeid.vbs = In diesem angegebenen Pfad muss sich das Skript befinden.
-
Anschließend gilt es das Skript im angegebenen Verzeichnis zu speichern (mit der Endung VBS).
' -------------------------------------------------------------------------
' Script by Sakari Kouti (see http://www.kouti.com)
' You have a royalty-free right to use, modify, reproduce and distribute
' this script (and/or any modified version) in any way you find useful,
' provided that you agree that Addison-Wesley or Sakari Kouti has no
' warranty, obligations or liability for the script. If you modify
' the script, you must retain this copyright notice.
' -------------------------------------------------------------------------
Option Explicit
Dim wshArguments, objUser, objSchemaEmployeeID, strCurrentID, strEmployeeID, intMaxLen
On Error Resume Next
Set wshArguments = WScript.Arguments
Set objUser = GetObject(wshArguments(0))
Set objSchemaEmployeeID = GetObject("LDAP://schema/employeeID")
intMaxLen = objSchemaEmployeeID.MaxRange
If objUser.employeeID <> "" Then
strCurrentID = objUser.employeeID
Else
strCurrentID = "empty"
End If
strEmployeeID = InputBox( _
"Die aktuelle Personalnummer lautet " & strCurrentID & vbCrLf & _
vbCrLf & _
"Tragen Sie bitte die neue Personalnummer ein (1 bis " & intMaxLen & " Zeichen)", _
Right(objUser.Name, Len(objUser.Name) - 3) & " Personalnummer", _
objUser.employeeID)
If strEmployeeID = "" Then WScript.Quit 'User clicked Cancel
If Len(strEmployeeID) > intMaxLen Then
MsgBox "Die neue Personalnummer ist zu lang und wird somit nicht gespeichert.", _
vbCritical, "Fehler"
Else
Err.Clear
objUser.employeeID = strEmployeeID
objUser.SetInfo
If Err Then MsgBox "Die neue Personalnummer wird nicht gespeichert.", _
vbCritical, "Fehler"
End If
-
Wenn man nun mit einem Rechtsklick auf einem Benutzerobjekt das Kontextmenü aufruft,
erscheint ein weiterer Eintrag der lautet: Personalnummer.
Als Alternative kann die Personalnummer auch als Spalte in der MMC Active Directory-Benutzer und -Computer angezeigt werden.
Wie das funktioniert, zeigt der folgende Artikel:
Eigene Spalten in ADBuC integrieren
An dieser Stelle sei erwähnt, man sollte das Active Directory nicht mit einer Human-Ressourcen Datenbank verwechseln.
Das Active Directory ist in erster Linie dafür da, IT-Informationen für die Netzwerkverwaltung bereitzustellen.
Weitere Informationen:
Extending the User Interface for Directory Objects
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
|
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|