Ein weit verbreitetes Missverständnis ist, das ein Ereignis, welches die dringende AD-Replikation auslöst, sofort an alle Domänencontroller (DC) repliziert wird. Genau genommen handelt es sich bei einer dringenden AD-Replikation (urgent replication) noch nicht einmal um eine echte sofortige Replikation. In Wirklichkeit wird lediglich die Benachrichtigung, dass Änderungen auf dem Quell-DC vorliegen, an erster Stelle der Replikationswarteschlange hinzugefügt.
Genau wie bei der standortinternen (Intra-Site) Replikation, basiert die dringende AD-Replikation auf Änderungsbenachrichtigungen (change notification). Außer das beim Eintreten eines wichtigen Ereignisses die Benachrichtigung unverzüglich versendet wird, statt 15 Sekunden (bzw. 300 Sekunden unter Windows 2000) abzuwarten. Diese Änderungsbenachrichtigung wird sofort an alle Replikationspartner versendet, noch bevor die in der Replikationswarteschlange anstehenden Änderungsbenachrichtigungen verschickt werden. Jeder DC, der eine dringende Aktualisierung erhält, leitet diese ebenfalls umgehend an seine Replikationspartner weiter. Durch diese Vorgehensweise ist sichergestellt, dass alle DCs am gleichen AD-Standort innerhalb von Sekunden aktualisiert werden.
Durch die dringende AD-Replikation erhalten die Replikationspartner in gewohnter Weise sofort eine Änderungsbenachrichtigung über das RPC over IP Protokoll. Aufgrund des hohen Replikationsaufkommens werden bei der dringenden AD-Replikation standardmäßig die AD-Standortgrenzen nicht überschritten. Das lässt sich jedoch konfigurieren.
Ereignisse, die eine dringende AD-Replikation auslösen
Die dringende AD-Replikation wird bei Eintreten bestimmter Ereignisse standardmäßig nur innerhalb eines AD-Standorts durchgeführt. Dabei ist es unabhängig, unter welchem Betriebssystem die DCs betrieben werden. Ist allerdings die standortübergreifende Änderungsbenachrichtigung in der Standortverknüpfung (Site-Link) aktiviert, werden diese Ereignisse auch unverzüglich zwischen den AD-Standorten repliziert.
Siehe dazu:
Die Inter-Site (standortübergreifende) Änderungsbenachrichtigung aktivieren
Zwischen den DCs, die sich innerhalb des gleichen AD-Standorts befinden, wird die dringende AD-Replikation durch folgende Änderungstypen ausgelöst:
- Benutzerkontosperrung (nachdem ein Benutzer sein Kennwort zu oft falsch eingegeben hat). Die Sperrung eines Benutzerkontos wird über die dringende AD-Replikation in erster Linie zu dem DC, der die FSMO-Rolle des PDC-Emulators innehat, repliziert. Das Entsperren eines Benutzerkontos hingegen löst keine dingende AD-Replikation aus!
- Bearbeitung der Kontosperrungsrichtlinie. Die Bearbeitung der gleichen Optionen in einem PSO (Password Setting Object) löst hingegen keine dringende AD-Replikation aus! Die Änderung eines PSO wird über die normale standortinterne (Intra-Site) und standortübergreifende (Inter-Site) AD-Replikation durchgeführt.
- Bearbeitung der domänenweiten Kennwortrichtlinie. Aber das Bearbeiten der Kennwortvorgaben in einem PSO löst ebenfalls keine dringende AD-Replikation aus! Die Änderung der Kennwortvorgaben innerhalb einer PSO wird ebenfalls über die normale standortinterne und standortübergreifende AD-Replikation durchgeführt.
- Verschiebung der RID-Master FSMO-Rolle auf einen anderen DC.
- Änderung eines LSA-Schlüssels (Local Security Authority, lokale Sicherheitsautorität). Wenn zum Beispiel das Kennwort des Computerkontos eines DCs oder für eine Vertrauensstellung geändert wird.
Die dringende AD-Replikation durch eine Benutzerkontosperrung
Gibt ein Benutzer sein Kennwort häufiger falsch ein, als es in der Kontosperrungsrichtlinie oder im PSO definiert ist, wird sein Benutzerkonto gesperrt. Die Benutzerkontosperrung wird dann über die dringende AD-Replikation zum PDC-Emulator repliziert. Unabhängig davon, an welchem AD-Standort dieser sich befindet.
Anschließend wird ebenfalls über die dringende AD-Replikation die Benutzerkontosperrung zu den folgenden DCs repliziert:
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die FSMO-Rolle des PDC-Emulators innehat.
- Zu allen DCs der gleichen Domäne, die sich am gleichen AD-Standort befinden wie der DC der die Benutzerkontosperrung durchgeführt hat.
- Zu allen DCs der gleichen Domäne, die sich an einem AD-Standort befinden zu der die standortübergreifende Änderungsbenachrichtigung (und demnach die dringende AD-Replikation) mit dem AD-Standort aktiviert wurde, in dem sich der PDC-Emulator oder der DC befindet, der die Benutzerkontosperrung durchgeführt hat.
Die Replikation einer Kennwortänderung
Oftmals wird auch fälschlicherweise angenommen, dass die Kennwortänderung eines Benutzers über die dringende AD-Replikation zu allen anderen DCs repliziert wird. Kennwortänderungen werden anders als die normale AD-Replikation und anders als die dringende AD-Replikation durchgeführt.
Bei der Kennwortänderung eines Domänen-Benutzers oder eines Computerkontos repliziert der DC, der die Kennwortänderung durchgeführt hat, umgehend das neue Kennwort durch den sicheren Kanal zum PDC-Emulator. Das neue Kennwort wird sogar dann zum PDC-Emulator repliziert, wenn dieser an einem anderen AD-Standort steht. Dabei greift der DC auch nicht auf die Bridgeheadserver an den AD-Standort zurück. Der DC, auf dem das Kennwort geändert wurde, nutzt stattdessen eine RPC over IP-Verbindung direkt zum PDC-Emulator, um das Kennwort zu aktualisieren.
Authentisiert sich der Benutzer danach an einem DC (z.B. aus einem anderen AD-Standort) der das neue Kennwort noch nicht kennt, fragt der DC beim PDC-Emulator nach, ob ihm ein neueres Kennwort vorliegt, bevor er dem Benutzer die Anmeldung verweigert. Falls ja, wird der Benutzer vom PDC-Emulator authentisiert und der Benutzer kann sich anmelden. Falls nicht, schlägt die Anmeldung fehl. Der PDC-Emulator hat also bei der Kennwortfrage immer das letzte Wort. Wenn die Kennwortnachfrage beim PDC-Emulator erfolgreich verlief, repliziert der PDC-Emulator das neue Kennwort unverzüglich zu dem DC, von dem die Anfrage kam. Dadurch ist sichergestellt, dass der DC nicht erneut wegen des geänderten Kennworts beim PDC-Emulator nachfrägt.
Die Kennwortaktualisierung wird sofort zum PDC-Emulator repliziert, ohne Rücksicht auf einen eventuell konfigurierten Zeitplan in der Standortverknüpfung. Anschließend wird sie innerhalb des AD-Standorts des PDC-Emulators und innerhalb des AD-Standorts des DC, der die Kennwortänderung durchgeführt hat, durch die standortinterne AD-Replikation zu den anderen DCs repliziert. Alle anderen DCs, die sich an entfernten AD-Standorten befinden, erhalten die Kennwortänderung ganz normal durch die standortübergreifende AD-Replikation.
Ist allerdings der PDC-Emulator nicht erreichbar (beispielsweise wegen Überlastung) oder schlägt die RPC over IP-Verbindung fehl, wird die Kennwortänderung über das normale Replikationsverfahren (standortintern und standortübergreifend) an alle DCs inklusive dem PDC-Emulator repliziert.
Wenn es nicht gewünscht wird, dass die Kennwortaktualisierung eines Benutzers oder eines Computers sofort zum PDC-Emulator an einem anderen AD-Standort repliziert wird, kann man dieses Verhalten unterbinden. Dazu muss folgender neuer Eintrag in die Registry erstellt werden:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
REG_DWORD
AvoidPdcOnWan
1 = Aktiviert (True)
Dieser Registryeintrag muss auf jedem DC erstellt werden, der eine Kennwortaktualisierung nicht sofort zu einem (an einem entfernten AD-Standort stehenden) PDC-Emulator replizieren soll. Der PDC-Emulator erhält die Kennwortaktualisierung dann ganz normal über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation. Befindet sich aber der PDC-Emulator am gleichen AD-Standort wie der DC, der die Kennwortaktualisierung durchgeführt hat, wird der Registryeintrag ignoriert und das neue Kennwort wird unverzüglich zum PDC-Emulator repliziert.
Komfortabler lässt sich diese Einstellung über die folgende GPO konfigurieren:
Computerkonfiguration\Richtlinien\Administrative Vorlagen\System\Netzwerkanmeldung\Verbindung mit PDC bei Anmeldungsfehler herstellen
Wird diese Richtlinie auf Deaktiviert konfiguriert, repliziert der DC, auf dem die Kennwortänderung stattgefunden hat, das neue Kennwort ebenfalls nicht sofort zum PDC-Emulator an einem anderen AD-Standort. Stattdessen wird das neue Kennwort dann über den konfigurierten Zeitplan für die standortübergreifende AD-Replikation repliziert. Wenn sich jedoch der PDC-Emulator am gleichen AD-Standort befindet wie der die Kennwortänderung durchführende DC, wird das neue Kennwort sofort zum PDC-Emulator repliziert.
Auf der anderen Seite hat man sowohl mit dem Registryeintrag als auch mit der GPO Einfluss darauf, wie sich ein DC Verhalten soll, wenn sich ein Benutzer oder Computer mit einem für den DC fremden Kennwort authentisieren möchte. Setzt man den Registryeintrag oder konfiguriert man die GPO, leitet der DC die Kennwortabfrage nicht an den PDC-Emulator weiter, wenn dieser sich an einem anderen AD-Standort befindet.
Der Registryeintrag oder die GPO kann zum Beispiel dann sinnvoll sein, wenn sich der PDC-Emulator an einem AD-Standort befindet, der mit einer geringen Bandbreite mit anderen Standorten angebunden ist (was in unserer Hemisphäre schon kaum mehr möglich ist). Oder um bei einer Brute Force Attacke nicht zusätzlich den PDC-Emulator und die VPN-Verbindung zu belasten. Dann muss man aber in Kauf nehmen, dass der Benutzer sich über einen längeren Zeitraum nicht an der Domäne anmelden kann.
Weitere Informationen:
Password Setting Objects erstellen und verwalten
Der RID-Master und sein RID-Pool
How the Active Directory Replication Model Works
New Password Change and Conflict Resolution Functionality in Windows
Comments are closed, but trackbacks and pingbacks are open.