TCP / IP-knooppunttypen en clientaanmelding

wanneer u een multi-site-domein bouwt dat over meerdere subnetten wordt gerouteerd, kunt u ervan uitgaan dat het plaatsen van een back-updomeincontroller in een externe site ervoor zorgt dat de clients op die site lokaal worden gevalideerd. Het doel is natuurlijk tweeledig: het verminderen van het verkeer dat via een dure verbinding buiten het LAN zal gaan en ervoor zorgen dat de aanmeldingen van klanten niet worden vertraagd door de snelheid (of het ontbreken daarvan) van de WAN-verbinding. Het installeren van een lokale domeincontroller kan inderdaad werken, maar zal dat succes zijn door het ontwerp of per ongeluk?
helaas is er geen manier om de domeincontroller op te geven die een bepaalde client zal valideren, of die client nu Windows NT Server, Windows NT Workstation of Windows 9x draait. eerdere versies van Windows werken op dezelfde manier, op voorwaarde dat ze de 32-bits TCP/IP-stack of een 16-bits WINS-bewuste TCP/IP-stack gebruiken.
in deze dagelijkse oefening geven we u een overzicht van de processen die hierbij betrokken zijn. We zullen ook uitleggen waarom een domeincontroller die is gevestigd in een ander land op een langzame modem link kan worden gekozen door een client machine om zijn aanmeldingsverzoek te onderhouden.
Achtergrond
voor degenen onder u die niet bekend zijn met het concept van Windows NT-domeinen, hier is een snelle refresher: een NT-domein is een verzameling van netwerk-enabled servers en andere computers die gemeenschappelijke beveiliging en accountinformatie delen. Het domein biedt gecentraliseerde gebruikers -, computer-en netwerkbeheer. De beveiligingsinformatie wordt opgeslagen in een centrale database op een server die is aangewezen en geconfigureerd als de primaire domeincontroller (PDC) en wordt gerepliceerd naar andere speciale servers, die zijn aangewezen en geconfigureerd als BDC (back-up domeincontrollers). Er kan maar één server tegelijk de PDC zijn, maar deze speciale rol kan naar behoefte naar elke BDC worden overgedragen. Wanneer een client die TCP/IP uitvoert zich probeert aan te melden bij dit NT-domein, wordt de aanmeldingsverzoek verwerkt door een van de domeincontrollers van het netwerk die tot hetzelfde domein behoren.
WINS
WINS-servers houden een lijst bij van alle wins-ingeschakelde clients op het netwerk. WINS-servers houden ook een lijst bij van domeincontrollers die worden geïdentificeerd als type <1C>. Om redenen die alleen hen bekend waren, besloten de ontwerpers van WINS dat er een limiet van 25 vermeldingen in de <1C> lijst moest zijn, wat betekent dat volgende domeincontrollers niet op deze lijst zullen verschijnen. Clients krijgen deze lijst wanneer ze een domeincontroller proberen te vinden om hun aanmeldingsverzoek te onderhouden.

de volgorde waarin de domeincontrollers op de lijst verschijnen volgt deze logica:

1. Domain controller items geregistreerd bij de WINS-server, in de volgorde van meest recent vernieuwd naar minst recent vernieuwd
2. Domain controller items verkregen van replicatie met andere WINS-servers
3. De eerste vermelding is altijd de PDC

Knooppunten
Bij het configureren van TCP/IP op een opdrachtgever, een van de opties die u mogelijk te zien (afhankelijk van de installatie) is het type knooppunt. Het knooppunttype verwijst naar hoe de client een domeincontroller vindt om de aanmeldingsverzoeken te onderhouden.
er zijn vier knooppunttypen in TCP / IP:

• B-node (broadcast node): wanneer een client een domeincontroller moet vinden, zal deze een broadcast uitvoeren. De eerste domeincontroller die reageert, krijgt de taak om de aanmeldingsverzoek te beheren.
• P-node (point-to-point node): in deze omgeving gaan naamquery ‘ s rechtstreeks naar de WINS-server.
• M-node( multi-homed node): een M-node omgeving gebruikt eerst b-node en vervolgens—indien nodig—p-node om namen op te lossen.
• H-knooppunt( hybride knooppunt): een H-knooppuntomgeving gebruikt eerst p-knooppunt en vervolgens b-knooppunt als de naamservice niet beschikbaar is.

laten we elk knooppunttype uitvoeriger onderzoeken.
B-node
de B-node-modus gebruikt broadcast-berichten voor naamregistratie en-resolutie. Bijvoorbeeld, als een computer genaamd NT_PC1 wil communiceren met een computer genaamd NT_PC2, NT_PC1 stuurt een broadcast bericht dat het op zoek is naar NT_PC2. Het wacht dan een bepaalde tijd voor NT_PC2 om te reageren.
B-node heeft twee grote problemen:

• In een grote omgeving, het laadt het netwerk met broadcast berichten.
• routers sturen normaal gesproken geen broadcast-berichten door, zodat computers aan weerszijden van een router de verzoeken nooit horen.

voorbeelden van computers op het netwerk die b-knooppuntclients kunnen zijn, zijn computers met MS-DOS, Windows 3.1 of Windows voor werkgroepen waarvoor geen WINS-clientsoftware is geïnstalleerd. Mogelijke servers zijn Server Message Block (SMB)-gebaseerde netwerkservers, zoals IBM LAN Server, DEC PATHWORKS, at&T StarLAN, en LAN Manager voor OS/2 of UNIX systemen.
P-node
de P-node-modus lost de problemen op die b-node niet oplost. In een p-knooppuntomgeving maken computers geen broadcast-berichten en reageren ze niet op deze berichten. Alle computers registreren zich bij de WINS-server, die verantwoordelijk is voor het kennen van computernamen en-adressen en om ervoor te zorgen dat er geen dubbele namen op het netwerk bestaan.

in deze omgeving, wanneer NT_PC1 wil communiceren met NT_PC2, vraagt het de WINS-server om het adres van NT_PC2. Na ontvangst van het adres, NT_PC1 gaat rechtstreeks naar NT_PC2 zonder uitzending. Omdat de naamquery ‘ s rechtstreeks naar de WINS-server gaan, voorkomt p-node dat het netwerk wordt geladen met broadcast-berichten. Omdat broadcast-berichten niet worden gebruikt en het adres direct wordt ontvangen, kunnen computers zich aan weerszijden van routers bevinden.
de belangrijkste problemen met p-node zijn:

• alle computers moeten zo zijn geconfigureerd dat ze het adres van de WINS-server kennen.
• als de WINS-server down is, kunnen computers die erop vertrouwen om adressen op te lossen, niet naar andere systemen in het netwerk komen.

M-knooppunt
de M-knooppuntmodus werd voornamelijk gemaakt om de problemen met b-knooppunt en p-knooppunt op te lossen. In een M-node-omgeving probeert een computer eerst registratie en resolutie met b-node. Als dat niet lukt, schakelt het over naar p-node. Voordelen:

• M-node kruis routers
• Aangezien de b-node wordt altijd geprobeerd de eerste computers aan dezelfde kant van een router blijven functioneren zoals gebruikelijk als de WINS-server is down
• In theorie, met behulp van m-node moeten verhogen LAN-prestaties

H-node
Het h-node-modus lost de belangrijkste problemen in verband met de broadcast-berichten en routed-milieu-activiteiten. Deze modus is een combinatie van b-node en p-node die broadcast berichten als laatste redmiddel gebruikt. De h-node-modus doet meer dan de volgorde wijzigen voor het gebruik van b-node en p—node: als de WINS—server down is-waardoor broadcast-berichten een noodzaak zijn-blijft de computer de WINS-server pollen. Wanneer de WINS-server opnieuw kan worden bereikt, keert het systeem terug naar p-node. H-node kan ook worden geconfigureerd om het Lmhosts-bestand te gebruiken nadat de broadcast-naamresolutie mislukt.
omdat p-node als eerste wordt gebruikt, worden er geen broadcast-berichten gegenereerd als de WINS-server draait en kunnen computers zich aan weerszijden van routers bevinden. Als de WINS-server uitgeschakeld is, wordt b-node gebruikt, zodat computers aan dezelfde kant van een router blijven werken zoals gewoonlijk.
andere combinaties
een andere variant, bekend als modified b-node, wordt ook gebruikt in Microsoft-netwerken zodat berichten over routers kunnen gaan. Gewijzigde b-node maakt geen gebruik van de P-node-modus of een WINS-server. In deze modus gebruikt b-node een lijst met computers en adressen die zijn opgeslagen in een Lmhosts-bestand. Als een poging tot b-knooppunt mislukt, zoekt het systeem in LMHOSTS een naam op en gebruikt vervolgens het bijbehorende adres om de router te kruisen. Elke computer moet echter over deze lijst beschikken, wat een administratieve last met zich meebrengt omdat de lijst moet worden bijgehouden en verspreid. Zowel Windows voor werkgroepen 3.11 en LAN Manager 2.x gebruikte zo ‘ n aangepast B-knooppuntsysteem. Windows NT gebruikt deze methode als WINS-servers niet op het netwerk worden gebruikt. In Windows NT zijn enkele extensies aan dit bestand toegevoegd om het beheer te vergemakkelijken, maar gewijzigde b-node is geen ideale oplossing.

sommige sites hebben mogelijk zowel B-node als p-node modi nodig. Hoewel deze configuratie kan werken, moeten beheerders uiterste voorzichtigheid betrachten en het alleen gebruiken voor overgangssituaties. Aangezien p-node-hosts broadcast-berichten negeren en B-node-hosts afhankelijk zijn van broadcast-berichten voor naamomzetting, kunnen de twee hosts mogelijk worden geconfigureerd met dezelfde NetBIOS-naam, wat tot onvoorspelbare resultaten leidt. Als een computer die is geconfigureerd voor het gebruik van b-node een statische toewijzing heeft in de WINS-database, kan een computer die is geconfigureerd voor het gebruik van p-node niet dezelfde computernaam gebruiken.
Computers waarop Windows NT wordt uitgevoerd, kunnen worden geconfigureerd als WINS-proxy-agents om de overgang naar het gebruik van WINS te vergemakkelijken. Windows-netwerkclients (WINS-enabled Windows NT, Windows 95 of Windows for Workgroups 3.11 computers) kunnen WINS rechtstreeks gebruiken. Niet-WINS-computers die compatibel zijn met b-node (zoals beschreven in RFCs 1001 en 1002) hebben toegang tot WINS via proxy ‘ s. Een WINS-proxy is een WINS-computer die luistert naar broadcast-berichten met naamquery en vervolgens reageert op Namen die niet in het lokale subnet staan. Proxies zijn P-node computers.
wanneer u TCP configureert, zult u geen enkele manier vinden om het knooppunttype in te stellen. Het knooppunttype is ingesteld op een standaard tijdens TCP-configuratie. De standaard Windows 95 TCP/IP node types zijn:
als DHCP=False, en WINS is uitgeschakeld, dan knooppunt Type b-node (0x01)
als DHCP=False, en WINS is handmatig ingesteld, dan knooppunt Type h-node (0x08)
als DHCP=True, en DHCP sets WINS, dan knooppunt Type h-node (0x08)
als DHCP=True, en WINS is handmatig ingesteld, dan knooppunt Type h-node (0x08)
als DHCP=True, en WINS is uitgeschakeld, dan knooppunt type b-node (0x01)
als wins-Serveropties worden geleverd via DHCP, moet het knooppunttype worden ingesteld met DHCP-optie 46; het lokaal definiëren van een WINS-server op de client heeft echter voorrang op deze twee opties, omdat lokaal gedefinieerde WINS-servers uw knooppunttype automatisch instellen op h-knooppunt.
het knooppunttype kan handmatig worden gewijzigd door het Windows 95-register te bewerken. De locatie bestaat onder de subboom HKEY_LOCAL_MACHINE onder de subsleutel
SYSTEM \ CURRENTCONTROLSET\SERVICES \ VXD \ MSTCP \ Node Type
NodeType kan worden toegevoegd als een tekenreekswaarde onder MSTCP als het nog niet bestaat.
de aanmeldingsverzoek

laten we nu kijken wat er gebeurt nadat de client de gebruikersnaam, het wachtwoord en de domeininformatie invoert en op OK klikt in het aanmeldpromptvenster (voordat de aanmeldingsverzoek wordt onderhouden). Windows 9x en Windows NT gedragen zich iets anders, dus Ik zal ze apart bespreken.
Windows 9x client
de client probeert een domeincontroller te vinden op een manier die wordt gedefinieerd door het knooppunttype waarmee het is geconfigureerd. Hieronder is een zeer vereenvoudigde volgorde van gebeurtenissen:

1. een B-node client zal een verzoek uitzenden. Als een server niet reageert, zal de aanmelding mislukken.
2. een P-node client zal de <1C> lijst opvragen bij de WINS server. Het zal vervolgens een verzoek uitzenden naar elk van de servers in de <1C> lijst op zijn beurt, te beginnen met de eerste (de PDC).
3. de M-node-en h-node-clients doen beide dingen in de hierboven beschreven volgorde, behalve dat, als de naam van de werkgroep van de client dezelfde is als het accountdomein waarvoor de aanmeldingspoging wordt gedaan, de WINS-zoekopdracht voor domeincontrollers op het lokale subnet wordt overgeslagen. Op voorwaarde dat de WINS-server actief en bereikbaar is, betekent dit dat de eerste domeincontroller in de <1C> lijst die reageert, altijd de aanmeldingsverzoek zal afhandelen.

om ervoor te zorgen dat de client wordt gevalideerd door de lokale domeincontroller, moet u de naam van de werkgroep hetzelfde maken als het domein dat door die domeincontroller wordt vertegenwoordigd. Als u echter werkgroepen binnen de kantooromgeving wilt gebruiken, is deze methode om lokale validatie te garanderen mogelijk niet aanvaardbaar. In dit geval moet het knooppunttype op m worden ingesteld om ervoor te zorgen dat de client in eerste instantie op het lokale subnet uitzendt, zodat de kans groter is dat de lokale domeincontroller als eerste reageert. Merk op dat het niet een harde en snelle regel. De domeincontroller hoeft alleen een beetje druk te zijn-wat remote site servers vaak zijn omdat het gebruikelijk is voor beheerders om een enkele domeincontroller op een remote site te plaatsen—en een meer responsieve, niet-lokale domeincontroller zou als eerste binnen kunnen komen.
als alternatief kan WINS op de lokale domeincontroller worden geïnstalleerd en kunnen de clients deze als primaire WINS-server gebruiken. Deze methode kan een goed idee zijn als gebruikers zelden toegang krijgen tot bronnen buiten de lokale branch, maar het is een extra last voor de server, die waarschijnlijk bestand-en printdiensten, DHCP, SQL, Exchange en andere taken levert.

als de naam van de werkgroep verschilt van het accountdomein, dan vergroot het gebruik van m-node de kans om de aanmeldingsverzoek lokaal te laten uitvoeren.
Windows NT-client
Windows NT-aanmelding verschilt enigszins van Windows 9x—aanmelding-het NT-werkstation heeft een machine-ID in een domein. Zo, de client gaat door vier stappen voor logon validatie. Eerst valideert de nt-werkstation-client zijn machine-ID met de domeincontrollers uit het brondomein en verzendt deze de aanmeldingsgegevens van de gebruiker voor pass-through-validatie. De domeincontroller van het brondomein geeft de aanmeldingsgegevens door aan een domeincontroller in het accountdomein. De brondomein-domeincontroller geeft vervolgens de verificatiegegevens van de gebruiker (ontvangen van de accountdomein-domeincontroller) door aan de gebruiker.
of gebruikers wel of niet bij hen zijn aangemeld, NT-werkstation-clients doorlopen ID-validatie tijdens initialisatie en zoals later vereist is (zoals wanneer iemand zich aanmeldt bij de nt-machine met het lokale profiel in de cache omdat de brondomeincontroller down is).
komt eerst de naamresolutie van de domeincontrollers. De NT Workstation-client moet een brondomein-domeincontroller vinden. Het zoekproces dat door een NT-werkstation-client wordt gebruikt om een brondomeincontroller te vinden, is hetzelfde als het proces dat door de brondomein-domeincontroller wordt gebruikt om een vertrouwde verbinding tot stand te brengen met een accountdomein-domeincontroller.
vervolgens wordt de nt machine ID gevalideerd. De nt-werkstation-client verzendt altijd een lokale aanmeldingsuitzending naar brondomein <1C> voordat unicast-aanmeldingsaanvragen worden verzonden naar brondomein-domeincontrollers die worden verkregen van WINS.
de client valideert de machine-ID van NT Workstation-waarbij de eerste domeincontroller uit het brondomein reageert op de aanmeldingsverzoek.
de nt-werkstation-client verzoekt de brondomein-domeincontroller om de lijst met vertrouwde domeinen op te sommen. De verkregen domeinnamen worden weergegeven in het vervolgkeuzelijst domein in het aanmeldvenster.
de nt-werkstation-client geeft de aanmeldingsreferenties van de gebruiker door aan de brondomein-domeincontroller en vraagt om pass-through-verificatie.
de brondomein-domeincontroller geeft de aanmeldingsreferenties van de gebruiker door aan de accountdomein-domeincontroller waarmee hij een vertrouwde verbinding tot stand heeft gebracht en verzoekt deze om verificatie van de gebruiker. Het geeft vervolgens de validatiegegevens terug aan de NT Workstation client.
de nt-werkstation-client krijgt de naam van de accountdomein-domeincontroller van de brondomein-domeincontroller om verbinding te maken en het aanmeldingsscript/profiel uit te voeren, als het is geconfigureerd.
de nt-gebruiker is nu aangemeld bij het accountdomein, heeft een aanmeldingsscript uitgevoerd en heeft de juiste netwerkverbindingen gemaakt met persoonlijke mappen.
natuurlijk, als de machine-ID is geregistreerd met een domein buiten het lokale subnet of als de gebruiker zich aanmeldt bij een domein dat geen domeincontroller heeft op het lokale subnet, zal het aanmeldingsproces communicatie via het WAN vereisen. Als het een langzame koppeling is, wordt het aanmeldingsproces uitgebreid.
conclusie
bij Windows 9x-clients wordt lokaal geverifieerd door de naam van de werkgroep hetzelfde te maken als de aanmelding, of account, domein of door de B-modus of M-node te gebruiken om ervoor te zorgen dat de aanmeldingsverzoek eerst lokaal wordt uitgezonden. Het is duidelijk dat b-node niet erg veelzijdig is en dat het een mislukte aanmelding veroorzaakt als de lokale domeincontroller niet snel reageert.
bij Windows NT-clients moet er een brondomeincontroller en een accountdomeincontroller in het lokale segment aanwezig zijn. (Het kan een enkele server zijn als de resource en account domeinen hetzelfde zijn.)
u kunt het proces verder verbeteren door meerdere WINS-servers te hebben en door de clients te wijzen naar de WINS-server die de lokale of dichtstbijzijnde domeincontroller registreert in de lijst <1C>.Richard Charrington ‘s computercarrière begon toen hij begon te werken met PC’ s—toen ze bekend stonden als microcomputers. Beginnend als een programmeur, werkte hij zich een weg omhoog naar de hoge hoogten van een Windows NT systeembeheerder, en hij heeft zo ongeveer alles daartussenin gedaan. Richard werkt al met Windows voordat het een goede GUI had en met Windows NT sinds het LANManager was. Nu een aannemer, hij is gleed in script schrijven voor Windows NT en heeft een aantal zeer nuttige auto-admin hulpprogramma ‘ s gebouwd.de auteurs en redacteuren hebben zorg gedragen bij de voorbereiding van de inhoud die hierin is opgenomen, maar geven geen expliciete of impliciete garantie van welke aard dan ook en aanvaarden geen verantwoordelijkheid voor fouten of weglatingen. Er is geen aansprakelijkheid voor eventuele schade. Zorg altijd voor een geverifieerde back-up voordat u wijzigingen aanbrengt.