Standorte im Sinne des Active Directorys sind eine physikalische Komponente des Active Directorys.


Diese zu erstellen gehört zu einem sauberen Design einer Active Directory-Domäne dazu, falls Domänencontroller auch
in Aussenstellen platziert sind und z.B. die Notwendigkeit der Einflussnahme in Bezug auf die AD-Replikation besteht.


Ein AD-Standort kann dabei durchaus mehrere Domänen enthalten und eine einzige Domäne kann mehreren AD-Standorten angehören.


Durch das Erstellen von AD-Standorten wird die standortübergreifende (Inter-Site) Replikation planbar und der Verkehr auf den WAN-Verbindungen wird entlastet.


Mehr Informationen über Standorte, erhält man im folgenden Artikel:


Active Directory-Replikation


http://www.faq-o-matic.net/2006/04/26/active-directory-replikation/


 


 


 


Wie findet ein Client einen Domänencontroller an seinem Standort?


 


Wie so oft, spielt auch dabei die DNS-Namensauflösung eine große Rolle.


Die Voraussetzungen damit ein Client einen lokalen DC nutzt sind folgende:


 



  • Im Snap-In “Active Directory-Standorte und -Dienste” müssen entsprechende Standorte erstellt sein


  • Diesen Standorten muss das entsprechende IP-Subnetz bzw. Subnetze zugeordnet sein


  • Die Server-Icons der jeweiligen Domänencontroller müssen sich in ihrem Active Directory Standort befinden.
    Falls es nicht der Fall ist, müssen diese dort an ihren richtigen Standort verschoben werden.

    Hinweis: Wenn ein DC an einen anderen Standort verschoben wurde, ist zwingend das DNS zu bereinigen.
    Dazu sind die SRV-Einträge des DCs, aus dem Pfad _tcp.<Name des Standorts>._sites.dc._msdcs.Domäne
    vom alten Standort zu entfernen.


    Siehe auch:
    Einen Domänencontroller an einen anderen Standort verschieben

 



Die Vorgehensweise wie ein Client einen DC findet, ist wie folgt:



  • Der Client fragt im DNS nach, welche DCs es gibt.


  • Falls der Client noch keine Standortinformationen hat, erhält er bei dem ersten Kontakt mit einem Domänencontroller
    von diesem die richtigen Informationen übermittelt, zu welchem Standort der Client gehört. Wenn ein Client dann erneut startet,
    versucht er über das DNS immer zuerst einen DC zu finden, der sich an seinem Standort befindet.


  • Er erhält eine Liste aus der DNS-Antwort und geht diese durch, um einen DC zu finden der funktioniert und auch online ist.
    Dabei nimmt er bevorzugt einen DC aus seinem Standort. Die DNS-Abfrage die der Client in diesem Moment stellt, wäre: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.


  • Der Client setzt dann in seiner Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters 
    den Eintrag DynamicSiteName mit dem Standort, an dem er sich befindet.


  • Erst wenn der Client bei dieser Anfrage von einem DC aus seinem Standort keine Antwort erhält (wenn z.B. kein
    Domänencontroller an seinem Standort existiert)
    oder er noch keine Standortinformationen hat (z.B. nach einer Neuinstallation),
    fragt er mit einer zweiten Anfrage nach einem DC diesmal aus seiner Domäne nach. Die Abfrage lautet:
    _ldap._tcp.dc._msdcs.<Domäne>.

    Spätestens bei dieser Abfrage erhält der Client einen DC mitgeteilt.

 


 


Auf der Gegenseite geht der DC der die Anfrage eines Clients erhält wie folgt vor:




  • Der Domänencontroller reicht die Clientanfrage an seinen NETLOGON-Prozess durch, der dann die Client-IP in seiner
    Subnet to Site Mapping Table nachsieht und dann das treffende Standort-Objekt heraussucht.



  • Der Netlogon-Prozess des DCs übergibt an den DC die folgenden Infos:

    1. Den Namen des Standorts, in der sich der befragte Domänencontroller befindet.
    2. Den Standortnamen, in dem sich der Client befindet.
    3. Ein Flag das angezeigt wird, wenn sich der angefragte DC im gleichen Standort befindet (Bit gesetzt)
    oder ob der DC ausserhalb des Standortes ist (Bit nicht gesetzt).

 


 


Diese Informationen werden dann an den Client gesendet, der sich nun die Informationen wie folgt anschaut:




  • Wenn sich der Domänencontroller an dem gleichen (oder nächstgelegenen) Standort befindet (gesetztes Bit),
    nimmt der Client bevorzugt diesen DC.



  • Wenn sich kein DC an dem Standort des Clients befindet, entscheidet das Design in der
    MMC “Active Directory-Standorte und -Dienste”, an welchem DC sich der Client authentifiziert.
    Der Client verwendet einen Domänencontroller der am nächsten zu seinem Standort ist.
    Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend.



  • Nachdem der Client einen DC ermittelt hat, wird dieser Eintrag des DCs zwischengespeichert.
    Falls sich der DC nicht an dem Standort des Clients oder an einem nicht günstigen Standort befinden sollte (Verbindungskosten),
    leert der Client nach 15 Minuten den Zwischenspeicher und verwirft somit den zwischengespeicherten DC.
    Der Client versucht dann erneut einen nächstgelegenen DC, idealerweise an seinem eigenen Standort zu finden.

 


Prinzipiell könnte man den Client zwingen, sich an einem vorgegebenen Standort zu authentifizieren.


Dazu muss im Registry-Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters


der Eintrag SiteName erzeugt und als Wert der entsprechende Standort eingetragen werden.
Das wiederum hat aber den Nachteil, dass wenn der Client an einen anderen Standort verschoben werden sollte,


er sich versucht an seinem eingetragenen Standort zu authentifizieren.


Das führt dann zu einem langsamen Anmeldeverhalten.


 


Des Weiteren wird bei den Abfragen auch ein Auswahlverfahren angewendet.


Alle Domänencontroller sind, samt ihren SRV-Records, im DNS eingetragen und die jeweiligen Einträge enthalten eine Gewichtung sowie Priorität.


Der Domänencontroller, der mit seiner niedrigsten Zahl im Feld Priorität eingetragen ist (umso niedriger die Zahl, desto höher ist die Priorität),


wird vom Client als bevorzugter Domänencontroller genutzt. Existieren mehrere Domänencontroller mit der gleichen Priorität, entscheidet die Gewichtung.


Dabei gilt, je höher die Zahl (zwischen 1 und 65535), desto höher ist die Gewichtung und somit steht der Domänencontroller höher in


den Abfrageergebnissen die der Client geliefert bekommt.


 


 



 


 


 


Es können auch Standorte existieren, an denen kein Domänencontroller vor Ort besteht.


 


Hinweis: Standorte sollten auch dann erstellt werden, wenn kein Domänencontroller vor Ort existiert,


wenn z.B. mit standortabhängigen Richtlinien zu arbeiten ist.


 


Dann nimmt sich ein Domänencontroller aus einem anderen Standort, der dem Standort ohne Domänencontroller am nächsten ist


(anhand der Kosten der Standortverknüpfungen) dessen an und trägt sich im DNS als Domänencontroller für diesen Standort ein.


Dieses Verfahren nennt sich “Automatic Site Coverage” [1]. 


 


Es ist ebenso möglich einem bestimmten Domänencontroller mehrere Standorte zuzuweisen so dass dieser sich für mehrere Standorte im DNS einträgt.


Dazu fügt man unter Windows 2000 in der Registry des Domänencontrollers, unter dem folgenden Pfad:


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters


den Schlüssel “SiteCoverage” (REG_MULTI_SZ) hinzu und trägt als Wert dann den/die Standort(e) ein [2].


 


Unter Windows Server 2003 gibt es dafür eine Richtlinie:


Computerkonfiguration\Administrative Vorlagen\System\Netzwerkanmeldung\
Domänencontrollerlocator-DNS-Einträge\“Standorte, die durch DC-Locator-DNS-SRV-Einträge abgedeckt werden“


Die dort eingetragenen Standorte (jeweils getrennt durch ein Leerzeichen), werden vom NETLOGON-Dienst des Domänencontrollers im DNS registriert.


 



 


 


Neuerung ab Windows Vista und Windows Server 2008


 


Mit Vista und Windows Server 2008 wurde ein neues Feature (genauer eine Richtlinie) eingeführt, dass das Verhalten zum auffinden eines DCs verbessert.
Das Standardverhalten eines Clients und Mitgliedservers ist, dass zuerst im DNS nach einem DC am gleichen AD-Standort gesucht wird.
Schlägt dieser Versuch fehl, wird nach einem Zufallsprinzip ein DC aus der Domäne (von einem entfernten AD-Standort) ausgewählt,


der die Authentifizierung der Clients bzw. Mitgliedsserver durchführt.


 


Nun kann ab Vista und Windows Server 2008 die folgende Richtlinie aktiviert werden:
Computerkonfiguration\Administrative Vorlagen\System\Netzwerkanmeldung\Domänencontrollerlocator-DNS-Einträge\”Am nächstgelegenen Standort suchen”


 



Ist diese Richtlinie aktiviert, ändert sich das Verhalten ab Vista und Windows Server 2008 wie folgt:




  • Es wird weiterhin zuerst nach einem (beschreibbaren) DC am gleichen AD-Standort gesucht.



  • Wenn sich am gleichen AD-Standort kein DC befindet, wird durch die aktivierte Richtlinie ein DC am nächstgelegenen AD-Standort gesucht.
    Ein DC am nächstgelegenen AD-Standort wird durch die Kosten die in der MMC Active Directory-Standorte und -Dienste konfiguriert ist, bestimmt.
    Dabei werden AD-Standorte wo lediglich ein RODC existiert nicht beachtet.



  • Befindet sich am nächstgelegenen AD-Standort ebenfalls kein DC, wird nach einem Zufallsprinzip ein DC aus der Domäne ausgewählt.


Mit dieser Richtlinie lässt sich in größeren AD-Umgebungen mit mehreren AD-Standorten die zur Verfügung stehende Bandbreite effizienter nutzen.
Denn wenn an einem AD-Standort der DC ausfällt, können die Clients durch die aktivierte Richtlinie einen DC am nächstgelegenen AD-Standort

für ihre Authentifizierung verwenden, der am kostengünstigsten zu ihrem AD-Standort angebunden ist.


 


Enabling Clients to Locate the Next Closest Domain Controller


 




 


 


Weitere Informationen:
[1]
How DNS Support for Active Directory Works


[2] Configure a Domain Controller for Membership in Multiple Sites
Gründe für das Einrichten eines Einzelstandortes oder separater Standorte
Finding a Domain Controller in the Closest Site


Sites (Übersicht)
Sites and Subnets


How to optimize the location of a domain controller or global catalog that resides outside of a client’s site


How Domain Controllers Are Located in Windows


How Domain Controllers Are Located in Windows XP


Replikation: Standorte & Standortverknüpfungsbrücken


 


 

Comments are closed, but trackbacks and pingbacks are open.