Verwirrung um RODC / Clients etc....

[gizi 10]

Hi,

 

ich hab hier ein Problem und mir ist nicht so wirklich klar warum das so passiert wie es passiert.

 

Wir haben hier 3 DC´s einer von den 3 DC´s ist ein RODC. Die anderen beiden sind normale DC´s.

 

Ich war immer der Meinung das wenn man bei einem Client im TCP/IP einen der drei DC´s einträgt der client sich auch dort anmeldet und NICHT auf einem anderem DC was der Client aber macht?!

 

Beispiel:

 

Im Windows Client wird der DC1 eingetragen im TCP/IP als DNS, Client meldet sich auch dort an. Jetzt melde ich den Client wieder ab und melde ihn wieder an und dann kann es sein das der Client sich plötzlich am DC2 anmeldet was ich aber niemals eingetragen hab. Dann melde ich den Client wieder ab und er meldet sich plötzlich am RODC an.

 

Wie kommt das denn!?!? Wie kann ich das denn verhindern!?

Ich war immer der Meinung das der Client sich an dem DNS / DC anmeldet der auch eingetragen ist und sich nicht wild an irgendeinem DC anmeldet!?

Was kann ich dagegen tun?

[Dukel 436]

Was hast du denn vor? Ist der RODC in einem anderen Subnetz / Standort?

 

DNS heisst nicht anmeldeserver sondern DNS Server.

[NorbertFe 1.813]

Wieso will man das verhindern? Das eintragen eines DCs als DNS Server garantiert noch lange nicht, dass dieser DC auch zur Anmeldung verwendet wird.

 

Bye

Norbert

[gizi 10]

Und wie kann ich es "erzwingen" das der client sich als erstes z.B. am RODC anmeldet und wenn er dieser nicht da ist am DC1 oder DC2?

Ich möchte aber das der Client sich immer an einem bestimmten DC zuerst anmeldet.

 

@Dukel

 

Ja, der RODC ist an einem anderen Standort.

[NorbertFe 1.813]

Indem man sich mit AD-Sites auseinandersetzt. Ehrlich gesagt, bezweifle ich, dass es einen technisch vernünftigen Grund für deine Anforderung gibt. ;)

 

Bye

Norbert

[gizi 10]

doch gibt es, wenn ich nen RODC an einem anderen Standort habe und nicht die Anmeldung über die WAN Strecke machen möchte dann ist das für mich und meine Kollegen schon ein Grund dafür :)

 

Und was muss man bei den AD Sites machen!?

[Dukel 436]

Hast du AD Sites eingerichtet, Subnetze definiert und die AD Controller verteilt?

[gizi 10]

Ja, es gibt AD Sites, jeder DC hat eine AD Site.... Subnetze gibt es aber nicht.

[Dukel 436]

Hast du 3 Standorte?

 

AD-Sites ohne Subnetze gibt es nicht.

[gizi 10]

so, ich hab jetzt nochmal gefragte, so sieht es aus:

 

Standort 1

 

DC1 - Subnetz 1

DC2 - Subnetz 1

DC3 - Subnetz 3

DC4 - Subnetz 4

 

Standort 2

 

DC5 - Subnetz 5

[Dukel 436]

Stimmt das auch mit den IP Subnetzen so? Hast du verschiedene 3 Subnetze im 1. Standort?

 

Kannst du einen Screenshot vom aufgeklappten AD Sites and Services machen?

[Daim 12]

Servus,

 

das stimmt nicht! Ein Subnetz kann nur einem einzigen AD-Standort zugewiesen werden! Subnetz 1 ist in deinem Fall zwei AD-Standorten zugewiesen und das geht nicht. Vermutlich verwendet ihr Supernetting, also anstatt eines /24 ein /23 Subnetz.

 

 

Mal prinzipielkl wie ein Client "seinen" DC findet:

 

Bei der Authentifizierung eines Clients ist das DNS und das Design im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden Standorten nicht vergessen werden. Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden.

 

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

 

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

- 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>.<TLD>.

- Erst wenn der Client bei dieser Anfrage (von einem DC aus seinem Standort) keine Antwort erhält oder er noch keine Standortinformationen hat (z.B. nach einer Neuinstallation), fragt er nach einem DC diesmal aus seiner DOMÄNE nach. Die Abfrage lautet: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. 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 näher 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 "Standorte und Dienste", an welchem DC sich der Client authentifiziert. Er verwendet der einen Domänencontroller der am nächsten zu seinem Standort ist. Dabei ist z.B. die Einstellung der Verbindungskosten entscheidend.

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

 

 

LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

 

 

Was aber bei einem RODC sichergestellt werden muss, dass das Kennwort der Benutzer- UND -Computerkonten des RODC-Standorts zum RODC repliziert werden. Neben den Benutzerkennwörtern müssen auch die Computerkontokennwörter der Clients am RODC-Standort durch die Kennwortreplikationsrichtlinie (Password Replication Policy, kurz PRP) zum RODC repliziert werden, wenn der RODC eigenständig (wenn keine WAN-Verbindung zu einem beschreibbaren DC existiert) die Benutzer authentisieren soll. Denn auch Computerkonten müssen sich in der Domäne authentisieren.

 

 

LDAP://Yusufs.Directory.Blog/ - Die Installation eines RODC

[Daim 12]

Existieren in der Domäne neben dem RODC noch Windows Server 2003 DCs, dann muss auf den 2003er DCs noch das Compatibility Pack installiert werden.

 

LDAP://Yusufs.Directory.Blog/ - RODC Compatibility Pack

[gizi 10]

Sooooo ,also folgendes haben wir jetzt gemacht.

 

Wir haben den RODC in einen extra Standort gesteckt.

Der RODC ist im Subnetz 10.10.10.X und die Clients sind im Subnetz 192.168.42.X

Beide Subnetze haben wir mit dem Standort verknüpft.

Der client meldet sich aber leider trotzdem nicht zuerste auf dem RODC an.

 

Fehlt noch was!?

[Dukel 436]

Mach mal einen Screenshot vom AD Sites & Services (am besten alles aufgeklappt) und verlinke ihn hier.