TCP / IP-Knotentypen und Clientanmeldung

Wenn Sie eine Domäne mit mehreren Standorten erstellen, die über mehrere Subnetze geleitet wird, können Sie davon ausgehen, dass durch die Einrichtung eines Backup-Domänencontrollers an einem Remotestandort sichergestellt wird, dass die Clients an diesem Standort lokal validiert werden. Der Zweck ist natürlich zweifach: den Datenverkehr zu reduzieren, der über eine teure Verbindung außerhalb des LANS stattfindet, und sicherzustellen, dass die Clientanmeldungen nicht durch die Geschwindigkeit (oder das Fehlen) der WAN-Verbindung verzögert werden. Die Installation eines lokalen Domänencontrollers kann zwar funktionieren, aber ist dieser Erfolg beabsichtigt oder zufällig?
Leider gibt es keine Möglichkeit, den Domänencontroller anzugeben, der einen bestimmten Client validiert, unabhängig davon, ob auf diesem Client Windows NT Server, Windows NT Workstation oder Windows 9x ausgeführt wird. Frühere Versionen von Windows funktionieren auf die gleiche Weise, vorausgesetzt, sie verwenden den 32-Bit-TCP / IP-Stack oder einen 16-Bit-WINS-fähigen TCP / IP-Stack.
In diesem täglichen Drilldown geben wir Ihnen einen Überblick über die beteiligten Prozesse. Wir erklären auch, warum ein Domänencontroller, der sich in einem anderen Land auf einer langsamen Modemverbindung befindet, möglicherweise von einem Clientcomputer ausgewählt wird, um seine Anmeldeanforderung zu bearbeiten.
Hintergrund
Für diejenigen unter Ihnen, die mit dem Konzept der Windows NT-Domänen nicht vertraut sind, hier eine kurze Auffrischung: Eine NT-Domäne ist eine Sammlung von netzwerkfähigen Servern und anderen Computern, die gemeinsame Sicherheits- und Kontoinformationen gemeinsam nutzen. Die Domäne ermöglicht eine zentralisierte Benutzer-, Computer- und Netzwerkverwaltung. Die Sicherheitsinformationen werden in einer zentralen Datenbank auf einem Server gespeichert, der als primärer Domänencontroller (PDC) festgelegt und konfiguriert ist, und auf andere spezielle Server repliziert, die als Backup-Domänencontroller (BDC) festgelegt und konfiguriert sind. Es kann immer nur ein Server gleichzeitig der PDC sein, aber diese spezielle Rolle kann bei Bedarf auf jeden BDC übertragen werden. Wenn ein Client, der TCP/IP ausführt, versucht, sich bei dieser NT-Domäne anzumelden, wird die Anmeldeanforderung von allen Domänencontrollern des Netzwerks verarbeitet, die derselben Domäne angehören.
WINS
WINS-Server führen eine Liste aller WINS-fähigen Clients im Netzwerk. WINS-Server führen auch eine Liste von Domänencontrollern, die als Typ <1C> identifiziert werden. Aus Gründen, die nur ihnen bekannt sind, haben die Designer von WINS entschieden, dass die Liste <1C> auf 25 Einträge begrenzt sein sollte, was bedeutet, dass nachfolgende Domänencontroller nicht in dieser Liste angezeigt werden. Clients erhalten diese Liste, wenn sie versuchen, einen Domänencontroller für ihre Anmeldeanforderung zu finden.

Die Reihenfolge, in der die Domänencontroller in der Liste angezeigt werden, folgt dieser Logik:

1. Beim WINS-Server registrierte Domänencontrollereinträge in der Reihenfolge von zuletzt aktualisiert bis zuletzt aktualisiert
2. Domänencontrollereinträge aus der Replikation mit anderen WINS-Servern
3. Der erste Eintrag ist immer der PDC

Knoten
Wenn Sie TCP / IP auf einem Client konfigurieren, wird eine der Optionen angezeigt, die Sie möglicherweise sehen (abhängig von auf der Installation) ist der Knotentyp. Der Knotentyp bezieht sich darauf, wie der Client einen Domänencontroller findet, um seine Anmeldeanforderungen zu bedienen.
Es gibt vier Knotentypen in TCP/ IP:

• B-Knoten (Broadcast-Knoten): Wenn ein Client einen Domänencontroller finden muss, führt er einen Broadcast aus. Der erste Domänencontroller, der antwortet, erhält die Aufgabe, die Anmeldeanforderung zu bearbeiten.
• P-node (Punkt-zu-Punkt-Knoten): In dieser Umgebung werden Namensabfragen direkt an den WINS-Server gesendet.
• M-node (Multi-homed node): Eine m-Node-Umgebung verwendet zuerst b—node und dann — falls erforderlich – p-node, um Namen aufzulösen.
• H-Knoten (Hybridknoten): Eine h-Knoten-Umgebung verwendet zuerst p-Knoten und dann b-Knoten, wenn der Namensdienst nicht verfügbar ist.

Lassen Sie uns jeden Knotentyp genauer untersuchen.
B-node
Der b-Node-Modus verwendet Broadcast-Nachrichten für die Namensregistrierung und -auflösung. Wenn beispielsweise ein Computer mit dem Namen NT_PC1 mit einem Computer mit dem Namen NT_PC2 kommunizieren möchte, sendet NT_PC1 eine Broadcast-Nachricht, dass nach NT_PC2 gesucht wird. Es wartet dann eine bestimmte Zeit, bis NT_PC2 antwortet.
B-node hat zwei große Probleme:

• In einer großen Umgebung lädt es das Netzwerk mit Broadcast-Nachrichten.
• Normalerweise leiten Router keine Broadcast-Nachrichten weiter, sodass Computer auf gegenüberliegenden Seiten eines Routers die Anforderungen nie hören.

Beispiele für Computer im Netzwerk, bei denen es sich möglicherweise um B-Node-Clients handelt, sind Computer mit MS-DOS, Windows 3.1 oder Windows für Arbeitsgruppen, auf denen keine WINS-Clientsoftware installiert ist. Mögliche Server sind Server Message Block (SMB)-basierte Netzwerkserver wie IBM LAN Server, DEC PATHWORKS, AT&T StarLAN und LAN Manager für OS/2- oder UNIX-Systeme.
P-node
Der p-Node-Modus adressiert die Probleme, die b-node nicht löst. In einer P-Node-Umgebung erstellen Computer weder Broadcast-Nachrichten, noch reagieren sie darauf. Alle Computer registrieren sich beim WINS-Server, der dafür verantwortlich ist, Computernamen und -adressen zu kennen und sicherzustellen, dass keine doppelten Namen im Netzwerk vorhanden sind.

Wenn NT_PC1 in dieser Umgebung mit NT_PC2 kommunizieren möchte, fragt es den WINS-Server nach der Adresse von NT_PC2 ab. Nach Erhalt der Adresse geht NT_PC1 direkt zu NT_PC2, ohne zu senden. Da die Namensabfragen direkt an den WINS-Server gehen, vermeidet p-node das Laden des Netzwerks mit Broadcast-Nachrichten. Da Broadcast-Nachrichten nicht verwendet werden und die Adresse direkt empfangen wird, können sich Computer auf gegenüberliegenden Seiten von Routern befinden.
Die wichtigsten Probleme mit p-Knoten sind:

• Alle Computer müssen so konfiguriert sein, dass sie die Adresse des WINS-Servers kennen.
• Wenn der WINS-Server ausgefallen ist, können Computer, die zum Auflösen von Adressen darauf angewiesen sind, keine anderen Systeme im Netzwerk erreichen.

M-node
Der m-Node-Modus wurde in erster Linie entwickelt, um die mit b-Node und p-node verbundenen Probleme zu lösen. In einer m-Node-Umgebung versucht ein Computer zunächst die Registrierung und Auflösung mit b-node. Wenn dies fehlschlägt, wechselt es zu p-node. Zu den Vorteilen gehören:

• M-node kann Router überqueren
• Da b-node immer zuerst ausprobiert wird, arbeiten Computer auf derselben Seite eines Routers weiterhin wie gewohnt, wenn der WINS-Server ausgefallen ist
• Theoretisch sollte die Verwendung von m-node die LAN-Leistung erhöhen

H-node
Der h-Node-Modus löst die wichtigsten Probleme im Zusammenhang mit Broadcast-Nachrichten und Operationen in gerouteten Umgebungen. Dieser Modus ist eine Kombination aus b-Knoten und p-Knoten, die Broadcast-Nachrichten als letzten Ausweg verwendet. Der h-Node-Modus ändert nicht nur die Reihenfolge für die Verwendung von b-Node und p-node: Wenn der WINS—Server ausgefallen ist — was Broadcast-Nachrichten erforderlich macht -, fragt der Computer den WINS-Server weiterhin ab. Wenn der WINS-Server wieder erreichbar ist, kehrt das System zum p-node zurück. H-node kann auch so konfiguriert werden, dass die LMHOSTS-Datei verwendet wird, nachdem die Broadcast-Namensauflösung fehlschlägt.
Da p-node zuerst verwendet wird, werden keine Broadcast-Nachrichten generiert, wenn der WINS-Server ausgeführt wird, und Computer können sich auf gegenüberliegenden Seiten von Routern befinden. Wenn der WINS-Server ausgefallen ist, wird b-node verwendet, sodass Computer auf derselben Seite eines Routers weiterhin wie gewohnt arbeiten.
Andere Kombinationen
Eine andere Variante, die als modifizierter b-Knoten bezeichnet wird, wird auch in Microsoft-Netzwerken verwendet, sodass Nachrichten über Router gesendet werden können. Der modifizierte b-Knoten verwendet weder den P-Knoten-Modus noch einen WINS-Server. In diesem Modus verwendet b-node eine Liste von Computern und Adressen, die in einer LMHOSTS-Datei gespeichert sind. Wenn ein b-Node-Versuch fehlschlägt, sucht das System in LMHOSTS nach einem Namen und verwendet dann die zugehörige Adresse, um den Router zu überqueren. Jeder Computer muss jedoch über diese Liste verfügen, was einen Verwaltungsaufwand verursacht, da die Liste verwaltet und verteilt werden muss. Sowohl Windows für Arbeitsgruppen 3.11 als auch LAN Manager 2.x verwendete ein solches modifiziertes b-Knotensystem. Windows NT verwendet diese Methode, wenn WINS-Server nicht im Netzwerk verwendet werden. In Windows NT wurden dieser Datei einige Erweiterungen hinzugefügt, um die Verwaltung zu vereinfachen, aber Modified b-node ist keine ideale Lösung.

Einige Sites erfordern möglicherweise sowohl den B-Knoten- als auch den p-Knoten-Modus. Obwohl diese Konfiguration funktionieren kann, müssen Administratoren äußerste Vorsicht walten lassen und sie nur für Übergangssituationen verwenden. Da p-Knoten-Hosts Broadcast-Nachrichten ignorieren und b-Knoten-Hosts sich bei der Namensauflösung auf Broadcast-Nachrichten verlassen, können die beiden Hosts möglicherweise mit demselben NetBIOS-Namen konfiguriert werden, was zu unvorhersehbaren Ergebnissen führt. Wenn ein für die Verwendung von b-node konfigurierter Computer über eine statische Zuordnung in der WINS-Datenbank verfügt, kann ein für die Verwendung von p-node konfigurierter Computer nicht denselben Computernamen verwenden.
Computer unter Windows NT können als WINS-Proxyagenten konfiguriert werden, um den Übergang zur Verwendung von WINS zu erleichtern. Windows-basierte Netzwerkclients (WINS-fähige Windows NT-, Windows 95- oder Windows for Workgroups 3.11-Computer) können WINS direkt verwenden. Nicht-WINS-Computer, die b-Node-kompatibel sind (wie in RFCs 1001 und 1002 beschrieben), können über Proxys auf WINS zugreifen. Ein WINS-Proxy ist ein WINS-fähiger Computer, der Broadcast-Nachrichten mit Namensabfragen abhört und dann auf Namen antwortet, die sich nicht im lokalen Subnetz befinden. Proxys sind P-Node-Computer.
Wenn Sie TCP konfigurieren, finden Sie keine Möglichkeit, den Knotentyp festzulegen. Der Knotentyp wird während der TCP-Konfiguration auf einen Standardwert festgelegt. Die standardmäßigen Windows 95 TCP/IP-Knotentypen sind:
Wenn DHCP=False und WINS deaktiviert ist, dann Knotentyp b-node (0x01)
Wenn DHCP=False und WINS manuell gesetzt ist, dann Knotentyp h-node (0x08)
Wenn DHCP=True und DHCP WINS setzt, dann Knotentyp h-node (0x08)
Wenn DHCP=True und WINS manuell gesetzt ist, dann Knotentyp h-node (0x08)
Wenn DHCP DHCP=True, und WINS ist deaktiviert, dann Knotentyp b-node (0x01)
Wenn WINS-Serveroptionen über DHCP bereitgestellt werden, sollte der Knotentyp mithilfe der DHCP-Option 46 festgelegt werden; wenn Sie jedoch lokal einen WINS-Server auf dem Client definieren, werden diese beiden Optionen überschrieben, da lokal definierte WINS-Server Ihren Knotentyp automatisch auf h-node setzen.
Der Knotentyp kann manuell durch Bearbeiten der Windows 95-Registrierung geändert werden. Der Speicherort ist unter dem Teilbaum HKEY_LOCAL_MACHINE unter dem Unterschlüssel
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type
nodeType kann als Zeichenfolgenwert unter MSTCP hinzugefügt werden, wenn er noch nicht vorhanden ist.

Die Anmeldeanforderung
Schauen wir uns nun an, was passiert, nachdem der Client den Benutzernamen, das Kennwort und die Domäneninformationen eingegeben und im Anmeldeaufforderungsfenster auf OK geklickt hat (bevor die Anmeldeanforderung bearbeitet wird). Windows 9x und Windows NT verhalten sich etwas anders, daher werde ich sie separat besprechen.
Windows 9x-Client
Der Client versucht, einen Domänencontroller auf eine Weise zu finden, die durch den Knotentyp definiert ist, mit dem er konfiguriert wurde. Unten ist eine sehr vereinfachte Abfolge von Ereignissen:

1. Ein b-Node-Client sendet eine Anfrage. Wenn ein Server nicht antwortet, schlägt die Anmeldung fehl.
2. Ein p-Node-Client fordert die <1C> -Liste vom WINS-Server an. Es sendet dann nacheinander eine Anfrage an jeden der Server in der <1C> -Liste, beginnend mit dem ersten (dem PDC).
3. Die Clients m-node und h-node führen beide Vorgänge in der oben beschriebenen Reihenfolge aus, mit der Ausnahme, dass die WINS-Suche nach Domänencontrollern im lokalen Subnetz übersprungen wird, wenn der Arbeitsgruppenname des Clients mit der Kontodomäne übereinstimmt, bei der die Anmeldung versucht wird. Sofern der WINS-Server aktiv und erreichbar ist, bedeutet dies, dass der erste Domänencontroller in der <1C> -Liste, der antwortet, die Anmeldeanforderung immer verarbeitet.

Um sicherzustellen, dass der Client vom lokalen Domänencontroller validiert wird, müssen Sie den Arbeitsgruppennamen mit der Domäne identisch machen, die von diesem Domänencontroller dargestellt wird. Wenn Sie jedoch Arbeitsgruppen in der Office-Umgebung verwenden möchten, ist diese Methode zum Sicherstellen der lokalen Validierung möglicherweise nicht akzeptabel. In diesem Fall sollte der Knotentyp auf m festgelegt werden, um sicherzustellen, dass der Client anfänglich im lokalen Subnetz sendet, sodass die Wahrscheinlichkeit größer ist, dass der lokale Domänencontroller zuerst antwortet. Beachten Sie, dass dies keine feste Regel ist. Der Domänencontroller muss nur ein wenig beschäftigt sein – was Remotestandortserver häufig sind, da Administratoren normalerweise einen einzelnen Domänencontroller an einem Remotestandort platzieren – und ein reaktionsschnellerer, nicht lokaler Domänencontroller könnte zuerst einsteigen.
Alternativ könnte WINS auf dem lokalen Domänencontroller installiert werden, und die Clients könnten es als primären WINS-Server verwenden. Diese Methode ist möglicherweise eine gute Idee, wenn Benutzer selten auf Ressourcen außerhalb des lokalen Zweigs zugreifen, stellt jedoch eine zusätzliche Belastung für den Server dar, der wahrscheinlich Datei- und Druckdienste, DHCP, SQL, Exchange und andere Aufgaben bereitstellt.

Wenn sich der Arbeitsgruppenname von der Kontodomäne unterscheidet, erhöht die Verwendung von m-node die Wahrscheinlichkeit, dass die Anmeldeanforderung lokal bearbeitet wird.
Windows NT-Client
Die Windows NT—Anmeldung unterscheidet sich etwas von der Windows 9x-Anmeldung – die NT-Workstation verfügt über eine Computer-ID in einer Domäne. Der Client durchläuft also vier Schritte zur Anmeldevalidierung. Zunächst überprüft der NT Workstation-Client seine Computer-ID mit den Domänencontrollern aus der Ressourcendomäne und sendet dann Benutzeranmeldeinformationen zur Pass-Through-Validierung. Der Domänencontroller aus der Ressourcendomäne übergibt die Anmeldeinformationen an einen Domänencontroller in der Kontodomäne. Der Ressourcendomäne-Domänencontroller gibt dann die Benutzerauthentifizierungsinformationen (die vom Kontodomänen-Domänencontroller empfangen wurden) an den Benutzer zurück.
Unabhängig davon, ob Benutzer bei ihnen angemeldet sind oder nicht, durchlaufen NT-Workstation-Clients die ID-Validierung während der Initialisierung und bei Bedarf später (z. B. wenn sich jemand mit dem lokalen zwischengespeicherten Profil am NT-Computer anmeldet, weil der Ressourcendomänencontroller ausgefallen ist).
Zuerst kommt die Namensauflösung der Domänencontroller. Der NT-Workstation-Client muss eine Ressourcendomäne finden – Domänencontroller. Der Erkennungsprozess, der von einem NT-Workstation-Client zum Suchen eines Ressourcendomänencontrollers verwendet wird, ist derselbe, der vom Ressourcendomänendomänencontroller zum Herstellen einer vertrauenswürdigen Verbindung mit einem Kontodomänendomänencontroller verwendet wird.
Als nächstes wird die NT-Maschinen-ID validiert. Der NT-Workstation-Client sendet immer eine lokale Anmeldesendung an Resource-Domain <1C>, bevor Unicast-Anmeldeanforderungen an Resource-Domain-Domänencontroller gesendet werden, die von WINS abgerufen werden.
Der Client validiert die NT Workstation-Computer-ID – mit dem ersten Domänencontroller aus der Ressourcendomäne, der auf die Anmeldeanforderung antwortet.
Der NT-Workstation-Client fordert die Ressource Domäne-Domänencontroller auf, die Liste der vertrauenswürdigen Domänen aufzulisten. Die erhaltenen Domänennamen werden im Dropdown-Feld Domäne im Anmeldefenster angezeigt.
Der NT-Workstation-Client übergibt die Anmeldeinformationen des Benutzers an die Ressourcendomäne-Domänencontroller und fordert die Pass-Through-Authentifizierung an.
Der Ressourcendomäne-Domänencontroller übergibt die Anmeldeinformationen des Benutzers an das Konto Domäne-Domänencontroller, mit dem er eine vertrauenswürdige Verbindung hergestellt hat, und fordert ihn auf, den Benutzer zu authentifizieren. Anschließend werden die Validierungsinformationen an den NT Workstation-Client zurückgegeben.

Der NT-Workstation-Client ruft den Namen des Kontos Domäne-Domänencontroller von der Ressource Domäne-Domänencontroller ab, um eine Verbindung herzustellen und das Anmeldeskript /-profil auszuführen, sofern es konfiguriert wurde.
Der NT-Benutzer ist nun bei der Kontodomäne angemeldet, hat ein Anmeldeskript ausgeführt und entsprechende Netzwerkverbindungen zu Home-Verzeichnissen hergestellt.
Wenn die Maschinen-ID bei einer Domäne außerhalb des lokalen Subnetzes registriert ist oder wenn sich der Benutzer bei einer Domäne anmeldet, die keinen Domänencontroller im lokalen Subnetz hat, erfordert der Anmeldevorgang natürlich eine Kommunikation über das WAN. Wenn es sich um eine langsame Verbindung handelt, wird der Anmeldevorgang verlängert.
Fazit
Bei Windows 9x-Clients wird die lokale Authentifizierung erreicht, indem der Arbeitsgruppenname mit der Anmeldung oder dem Konto oder der Domäne identisch ist oder indem b-mode oder m-node verwendet wird, um sicherzustellen, dass die Anmeldeanforderung zuerst lokal gesendet wird. Offensichtlich ist b-node nicht sehr vielseitig und führt zu einer fehlgeschlagenen Anmeldung, wenn der lokale Domänencontroller nicht schnell reagiert.
Bei Windows NT-Clients sollten sich im lokalen Segment ein Ressourcendomänencontroller und ein Kontodomänencontroller befinden. (Es kann sich um einen einzelnen Server handeln, wenn die Ressourcen- und Kontodomänen identisch sind.)
Sie können den Prozess weiter verbessern, indem Sie mehrere WINS-Server haben und die Clients auf den WINS-Server verweisen, der den lokalen oder nächstgelegenen Domänencontroller in der Liste <1C> registriert.

Richard Charringtons Computerkarriere begann, als er anfing, mit PCs zu arbeiten – damals, als sie als Mikrocomputer bekannt waren. Angefangen als Programmierer arbeitete er sich bis in die luftigen Höhen eines Windows NT-Systemadministrators vor, und er hat so ziemlich alles dazwischen gemacht. Richard arbeitet mit Windows, seit es eine richtige GUI hatte und mit Windows NT, seit es LanManager war. Jetzt ein Auftragnehmer, hat er in das Schreiben von Skripten für Windows NT geschlüpft und hat einige sehr nützliche Auto-Admin-Dienstprogramme gebaut.

Die Autoren und Redakteure haben bei der Erstellung der hierin enthaltenen Inhalte Sorgfalt walten lassen, übernehmen jedoch keine ausdrückliche oder stillschweigende Gewährleistung jeglicher Art und übernehmen keine Verantwortung für Fehler oder Auslassungen. Für eventuelle Schäden wird keine Haftung übernommen. Führen Sie immer ein verifiziertes Backup durch, bevor Sie Änderungen vornehmen.