Finden von Domänencontrollern in Windows 2000/XP

[Patrick Cervicek]

Ich habe eine Verständnissfrge zu "Finden von Domänencontrollern in
Windows 2000/XP" [1]

Gegeben sei ein Firmennetz mit internationalen Standorten. Jeder
Standort hat eigene Domaincontroller (auch in AD über "Standorte"
eingetragen)

Normalerweise cacht ein Windows Client in "DynamicSiteName" an welchen
Standort er ist. Was passiert mit einem User der normalerweise mit
seinem Notebook in Deutschland arbeitet in die USA geht?

Der Client wird über seinen lokalen DNS _LDAP._TCP.dc._msdcs.domainname
auflösen lassen um die Default-Domaincontroller zu ermitteln (stehen in
Deutschland). Über einen LDAP-Ping an diese Domaincontroller wird er nun
seinen Standort festestellen wollen

Muss der LDAP-Ping nach Deutschland gehen (WAN,teuer/performance)? Oder
ist dieser LDAP-Ping-Traffic derart gering und daher zu vernachlässigen?
Würde bei einer Firewall-sperrung zwischen Client <-> Deutschen DCs
Site-Disvoery noch funktionieren? Ich habe "leider" keine Domäne und
kann es nicht ausprobieren. ;-)

[1]: http://support.microsoft.com/kb/247811/EN-US/

[Yusuf Dikmenoglu [MVP]]

Salve,

Post by Patrick Cervicek
Muss der LDAP-Ping nach Deutschland gehen (WAN,teuer/performance)?

nein, muss er nicht. Denn der Client sucht in seiner zweiten Abfrage
einen DC aus der Domäne und nicht gezielt aus seinem ursprünglichen
AD-Standort. Aber auch wenn der Client, der sich am USA AD-Standort
befindet, einen DC aus dem DE AD-Standort erreichen würde, würde der
DE DC dem Client ohnehin anhand seiner IP-Adresse und dem Design in
der MMC "Standorte und -Dienste" den Client seinen neuen AD-Standort
zurückliefern. Diesen trägt dann der Client in dem Registry-Key
"DynamicSiteName" ein.

Post by Patrick Cervicek
Oder ist dieser LDAP-Ping-Traffic derart gering und daher zu vernachlässigen?

Das auf jedenfall. Ich habe das zwar noch nicht ausgewertet, aber das ist
nicht der Rede Wert. Es wird also dadurch keine Last auf der VPN-Leitung
erzeugt.
Auch die Benutzerauthentisierung über das WAN beträgt i.d.R.
sehr wenige KBs.

Post by Patrick Cervicek
Würde bei einer Firewall-sperrung zwischen Client <-> Deutschen DCs
Site-Disvoery noch funktionieren?

Ja, da wie bereits geschrieben der Client in seiner zweiten Abfrage
nach einem DC diesmal in der Domäne sucht und nicht bloß in seinem
AD-Standort. Die Abfrage die der Client dabei stellt ist dieser:
_ldap._tcp.dc._msdcs.<Root-Domäne>.

Siehe dazu:

[LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort]
http://blog.dikmenoglu.de/Dom%c3%a4nencontroller+Am+Standort.aspx


Gruß, Yusuf

========================================
##### Microsoft MVP - Directory Services #####
Blog: http://blog.dikmenoglu.de
MVP-Profil: https://mvp.support.microsoft.com/profile/Yusuf
Twitter: http://twitter.com/YusufsDSBlog
========================================

[Patrick Cervicek]

Post by Yusuf Dikmenoglu [MVP]

Post by Patrick Cervicek
Oder ist dieser LDAP-Ping-Traffic derart gering und daher zu
vernachlässigen?

Das auf jedenfall. Ich habe das zwar noch nicht ausgewertet, aber das ist
nicht der Rede Wert. Es wird also dadurch keine Last auf der VPN-Leitung
erzeugt.
Auch die Benutzerauthentisierung über das WAN beträgt i.d.R.
sehr wenige KBs.

Ok. Hintergrund dieser Frage: Ich möchte Linuxclients mittels
MIT-Kerberos an der Domäne anmelden lassen. In der <rootdomain> sind
derzeit nur die Records von DE drin. Da MIT-Kerberos nicht auf
ActiveDirectory optimiert ist werden die Anfragen wohl immer in DE landen.

Post by Yusuf Dikmenoglu [MVP]

Post by Patrick Cervicek
Würde bei einer Firewall-sperrung zwischen Client <-> Deutschen DCs
Site-Disvoery noch funktionieren?

Ja, da wie bereits geschrieben der Client in seiner zweiten Abfrage
nach einem DC diesmal in der Domäne sucht und nicht bloß in seinem
_ldap._tcp.dc._msdcs.<Root-Domäne>.

Damit also Firewall- bzw. WAN-Probleme ausgeschlossen werden können
sollte in <rootdomain> also mindestens ein US DC drinstehen? Zumindest
bei den Linux-MIT-Kerberos Clients konnte ich sehen dass er wirklich
alle <rootdomain> DCs durchprobiert wenn ich alle DCs an der Firewall
blocke :-)