TCP/IP-nodtyper och klientinloggning

när du bygger en domän med flera webbplatser som dirigeras över flera undernät kan du anta att om du sätter en reservdomänkontrollant på en fjärrplats kommer det att säkerställa att klienterna på den webbplatsen valideras lokalt. Syftet är naturligtvis dubbelt: att minska trafiken som kommer att gå utanför LAN över en dyr länk och för att säkerställa att klientloggningar inte försenas av hastigheten (eller bristen på den) för WAN-anslutningen. Att installera en lokal domänkontrollant kan verkligen fungera, men kommer den framgången att vara genom design eller av misstag?
tyvärr finns det inget sätt att ange domänkontrollanten som ska validera en viss klient, oavsett om den klienten kör Windows NT Server, Windows NT Workstation eller Windows 9x. tidigare versioner av Windows fungerar på samma sätt, förutsatt att de använder 32-bitars TCP/IP-stack eller en 16-bitars WINS-medveten TCP/IP-stack.
i den här dagliga borrningen ger vi dig en översikt över de processer som är inblandade. Vi förklarar också varför en domänkontrollant som är placerad i ett annat land på en långsam modemlänk kan vara den som valts av en klientmaskin för att betjäna sin inloggningsbegäran.
Bakgrund
för dig som inte är bekant med begreppet Windows NT-domäner, här är en snabb uppdatering: en nt-domän är en samling nätverksaktiverade servrar och andra datorer som delar gemensam säkerhet och kontoinformation. Domänen tillhandahåller centraliserad användar -, dator-och nätverksadministration. Säkerhetsinformationen lagras i en central databas på en server som har utsetts och konfigurerats som primär domänkontrollant (PDC) och replikeras till andra specialservrar, som har utsetts och konfigurerats som backup domain controllers (BDC). Endast en server kan vara PDC åt gången, men denna speciella roll kan överföras till vilken BDC som helst. När en klient som kör TCP/IP försöker logga in på den här nt-domänen behandlas inloggningsbegäran av någon av nätverkets domänkontrollanter som tillhör samma domän.
WINS
WINS-servrar har en lista över alla WINS-aktiverade klienter i nätverket. WINS-servrar har också en lista över domänkontrollanter som identifieras som typ <1C>. Av skäl som endast är kända för dem bestämde designarna av WINS att det skulle finnas en gräns på 25 poster i listan <1C>, vilket innebär att efterföljande domänkontrollanter inte kommer att visas på den här listan. Kunderna får den här listan när de försöker hitta en domänkontrollant för att betjäna sin inloggningsbegäran.
den ordning i vilken domänkontrollanterna visas i listan följer denna logik:

1. poster för domänkontrollant registrerade på WINS-servern, i den ordning som senast uppdaterats till minst nyligen uppdaterats
2. poster för domänkontrollant som erhållits från replikering med andra WINS-servrar
3. den första posten är alltid PDC

noder
när du konfigurerar TCP/IP på en klient, ett av alternativen som du kan se (beroende på hur du konfigurerar TCP / IP på en klient installationen) är nodtypen. Nodtypen hänvisar till hur klienten hittar en domänkontrollant för att betjäna sina inloggningsförfrågningar.
det finns fyra nodtyper i TCP / IP:

• B-node (broadcast node): när en klient behöver hitta en domänkontrollant kommer den att utföra en sändning. Den första domänkontrollanten som svarar kommer att få jobbet att betjäna inloggningsbegäran.
• p-nod (punkt-till-punkt-nod): i den här miljön går namnfrågor direkt till WINS-servern.
• m-node (Multi-homed node): en m-nodmiljö använder b—node först och sedan—om nödvändigt-p-node för att lösa namn.
• h-nod (hybridnod): en h-nodmiljö använder p-nod först och sedan b-nod om namntjänsten inte är tillgänglig.

låt oss undersöka varje nodtyp mer fullständigt.
B-node
b-node-läget använder sändningsmeddelanden för namnregistrering och upplösning. Till exempel, om en dator med namnet NT_PC1 vill kommunicera med en dator med namnet NT_PC2, skickar NT_PC1 ett sändningsmeddelande om att den Letar efter NT_PC2. Den väntar sedan en viss tid för NT_PC2 att svara.
B-node har två stora problem:

• i en stor miljö laddar den nätverket med sändningsmeddelanden.
• vanligtvis vidarebefordrar routrar inte sändningsmeddelanden, så datorer på motsatta sidor av en router hör aldrig förfrågningarna.

exempel på datorer i nätverket som kan vara b-nodklienter är datorer som kör MS-DOS, Windows 3.1 eller Windows för arbetsgrupper som inte har WINS-klientprogramvara installerad. Möjliga servrar inkluderar Server Message Block (SMB) – baserade nätverksservrar, till exempel IBM LAN Server, DEC PATHWORKS, AT&t StarLAN och LAN Manager för OS/2 eller UNIX-system.
p-node
p-node-läget behandlar de problem som b-node inte löser. I en p-nodmiljö skapar eller svarar datorer varken på sändningsmeddelanden. Alla datorer registrerar sig hos WINS-servern, som ansvarar för att känna till datornamn och adresser och för att säkerställa att inga dubbla namn finns i nätverket.
i den här miljön, när NT_PC1 vill kommunicera med NT_PC2, frågar den WINS-servern efter adressen till NT_PC2. Vid mottagandet av adressen går NT_PC1 direkt till NT_PC2 utan sändning. Eftersom namnfrågorna går direkt till WINS-servern undviker p-node att ladda nätverket med sändningsmeddelanden. Eftersom sändningsmeddelanden inte används och adressen tas emot direkt kan datorer vara på motsatta sidor av routrar.

de mest signifikanta problemen med p-nod är:

• alla datorer måste konfigureras för att känna till adressen till WINS-servern.
• om WINS-servern är nere kan datorer som är beroende av den för att lösa adresser inte komma till några andra system i nätverket.

m-nod
m-nodläget skapades främst för att lösa problemen i samband med b-nod och p-nod. I en m-nodmiljö försöker en dator först registrering och upplösning med b-node. Om det misslyckas växlar det till p-node. Fördelarna inkluderar:

• M-node kan korsa routrar
• eftersom b-node alltid försökas först fortsätter datorer på samma sida av en router att fungera som vanligt om WINS-servern är nere
• i teorin bör m-node öka Lan-prestanda

H-node
h-node-läget löser de viktigaste problemen i samband med sändningsmeddelanden och dirigerade miljöoperationer. Detta läge är en kombination av b-nod och p-nod som använder sändningsmeddelanden som en sista utväg. H-node-läget gör mer än att ändra ordningen för att använda b-node och p-node: om WINS—servern är nere—vilket gör sändningsmeddelanden till en nödvändighet-fortsätter datorn att undersöka WINS-servern. När WINS-servern kan nås igen återgår systemet till p-node. H-node kan också konfigureras för att använda lmhosts-filen efter att sändningsnamnsupplösningen misslyckas.
eftersom p-node används först genereras inga sändningsmeddelanden om WINS-servern körs och datorer kan vara på motsatta sidor av routrar. Om WINS-servern är nere används b-node, så datorer på samma sida av en router fortsätter att fungera som vanligt.
andra kombinationer
en annan variant, känd som modifierad b-nod, används också i Microsoft-nätverk så att meddelanden kan gå över routrar. Modifierad b-node använder inte p-node-läge eller en WINS-server. I det här läget använder b-node en lista över datorer och adresser som lagras i en lmhosts-fil. Om ett B-nodförsök misslyckas ser systemet i LMHOSTS för att hitta ett namn och använder sedan den tillhörande adressen för att korsa routern. Varje dator måste dock ha den här listan, vilket skapar en administrativ börda eftersom listan måste underhållas och distribueras. Både Windows för arbetsgrupper 3.11 och LAN Manager 2.x använde ett sådant modifierat b-nodsystem. Windows NT använder den här metoden om WINS-servrar inte används i nätverket. I Windows NT har vissa tillägg lagts till i den här filen för att göra det lättare att hantera, men modifierad b-nod är inte en idealisk lösning.
vissa webbplatser kan kräva både B-nod och p-nod lägen. Även om denna konfiguration kan fungera måste administratörer vara extremt försiktiga och endast använda den för övergångssituationer. Eftersom p-node-värdar bortser från sändningsmeddelanden och b-node-värdar är beroende av sändningsmeddelanden för namnupplösning, kan de två värdarna potentiellt konfigureras med samma NetBIOS-namn, vilket leder till oförutsägbara resultat. Om en dator som är konfigurerad att använda b-node har en statisk mappning i WINS-databasen kan en dator som är konfigurerad att använda p-node inte använda samma datornamn.

datorer som kör Windows NT kan konfigureras som WINS – proxyagenter för att hjälpa övergången till att använda WINS. Windows – baserade nätverksklienter (WINS-aktiverade Windows NT, Windows 95 eller Windows for Workgroups 3.11-datorer) kan använda WINS direkt. Icke-WINS-datorer som är b-node-kompatibla (som beskrivs i RFC 1001 och 1002) kan komma åt WINS via proxyservrar. En WINS-proxy är en WINS-aktiverad dator som lyssnar på namnfrågesändningsmeddelanden och sedan svarar på namn som inte finns i det lokala undernätet. Proxies är p-node datorer.
när du konfigurerar TCP hittar du inget sätt att ställa in nodtypen. Nodtypen är inställd på en standard under TCP-konfiguration. Standard Windows 95 TCP / IP-nodtyper är:
om DHCP=False, och WINS är inaktiverat, då nodtyp b-node (0x01)
om DHCP=False, och WINS är manuellt inställd, då nodtyp h-node (0x08)
om DHCP=True, och DHCP sätter WINS, då nodtyp h-node (0x08)
om DHCP=True, och WINS är manuellt inställd, då nodtyp h-node (0x08)
om DHCP=true, och Wins är inaktiverat, då nodtyp B-nod (0x01)
om wins-serveralternativ tillhandahålls via DHCP, bör nodtyp ställas in med DHCP-alternativ 46; att lokalt definiera en WINS-server på klienten kommer dock att åsidosätta dessa två alternativ eftersom lokalt definierade WINS-servrar automatiskt ställer in din nodtyp till h-node.
nodtypen kan ändras manuellt genom att redigera Windows 95-registret. Platsen finns under underträdet HKEY_LOCAL_MACHINE under undernyckeln
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type
NodeType kan läggas till som ett strängvärde under MSTCP om det inte redan finns.
inloggningsbegäran
låt oss nu titta på vad som sker efter att klienten har angett användarnamnet, lösenordet och domäninformationen och klickar på OK i inloggningsfönstret (innan inloggningsbegäran servas). Windows 9x och Windows NT beter sig lite annorlunda, så jag diskuterar dem separat.
Windows 9x client
klienten försöker hitta en domänkontrollant på ett sätt som definieras av den nodtyp som den har konfigurerats med. Nedan följer en mycket förenklad händelsesekvens:

1. en b-nod klient kommer att sända en begäran. Om en server inte svarar misslyckas inloggningen.
2. en p-node-klient kommer att begära listan <1C> från WINS-servern. Det kommer sedan att sända en begäran till var och en av servrarna i listan <1C> i sin tur, med början med den första (PDC).
3. m-node-och h-node-klienterna gör båda dessa saker i den ordning som beskrivs ovan, förutom att om klientens arbetsgruppsnamn är samma som den Kontodomän som inloggningen försöker, hoppas WINS-sökningen efter domänkontrollanter på det lokala undernätet. Förutsatt att WINS-servern är aktiv och kan nås betyder det att den första domänkontrollanten i listan <1C> som svarar alltid hanterar inloggningsbegäran.

som nämnts ovan måste du, för att säkerställa att klienten valideras av den lokala domänkontrollanten, göra arbetsgruppens namn detsamma som domänen som representeras av den domänkontrollanten. Men om du vill använda arbetsgrupper i kontorsmiljön kanske den här metoden för att säkerställa lokal validering inte är acceptabel. I det här fallet bör nodtypen ställas in på m för att säkerställa att klienten sänder på det lokala undernätet initialt så att det finns en bättre chans att den lokala domänkontrollanten svarar Först. Observera att det inte är en hård och snabb regel. Domänkontrollanten behöver bara vara lite upptagen-vilka fjärrservrar ofta beror på att det är vanligt för administratörer att sätta en enda domänkontrollant på en fjärrplats—och en mer lyhörd, icke-lokal domänkontrollant kan komma in först.
alternativt kan WINS installeras på den lokala domänkontrollanten, och klienterna kan använda den som den primära WINS-servern. Den här metoden kan vara bra om användare sällan får tillgång till resurser utanför den lokala filialen, men det är en extra börda på servern, som förmodligen tillhandahåller fil-och utskriftstjänster, DHCP, SQL, Exchange och andra uppgifter.
om arbetsgruppens namn skiljer sig från kontodomänen ökar chansen att få inloggningsbegäran servad lokalt med hjälp av m-node.
Windows NT-klient
Windows NT—inloggning skiljer sig något från Windows 9x-inloggning-nt-arbetsstationen har ett maskin-ID i en domän. Så klienten går igenom fyra steg för inloggningsvalidering. Först validerar NT Workstation-klienten sitt maskin-ID med domänkontrollanterna från resursdomänen och skickar sedan användarinloggningsinformation för genomgångsvalidering. Domänkontrollanten från resursdomänen skickar inloggningsinformationen till en domänkontrollant i kontodomänen. Resursdomän – domänkontrollanten skickar sedan tillbaka användarautentiseringsinformationen (mottagen från Kontodomän-domänkontrollanten) till användaren.
oavsett om användare är inloggade på dem, går NT Workstation-klienter igenom ID-validering under initialisering och efter behov senare (till exempel om någon loggar in på nt-datorn med den lokala cachelagrade profilen eftersom resursdomänkontrollanten är nere).
först kommer namnupplösningen för domänkontrollanterna. NT Workstation-klienten måste hitta en resursdomän-domänkontrollant. Upptäcktsprocessen som används av en NT Workstation-klient för att hitta en resursdomänkontrollant är densamma som den som används av resursdomändomänkontrollanten för att upprätta en betrodd anslutning till en kontodomändomänkontrollant.

därefter valideras nt-maskin-ID. NT Workstation-klienten skickar alltid en lokal inloggningssändning till Resource-Domain < 1C> innan du skickar unicast-inloggningsbegäranden till resource domain-domain controllers som erhålls från WINS.
klienten validerar NT Workstation machine ID-med den första domänkontrollanten från resursdomänen för att svara tillbaka på inloggningsbegäran.
NT Workstation-klienten begär resursdomän – domänkontrollanten att räkna upp listan över betrodda domäner. De erhållna domännamnen visas i rullgardinsmenyn domän i inloggningsfönstret.
NT Workstation-klienten skickar användarinloggningsuppgifterna till resursdomän-domänkontrollanten och begär genomgångsautentisering.
resursdomändomänkontrollanten skickar användarinloggningsuppgifterna till den kontodomändomänkontrollant med vilken den har upprättat en betrodd anslutning och begär att den ska autentisera användaren. Den skickar sedan tillbaka valideringsinformationen till NT Workstation-klienten.
NT Workstation-klienten får namnet på kontodomändomänkontrollanten från resursdomändomänkontrollanten för att ansluta och köra inloggningsskriptet/profilen, om den har konfigurerats.
nt-användaren är nu inloggad på kontodomänen, har exekverat ett inloggningsskript och har gjort lämpliga nätverksanslutningar till hemkataloger.
naturligtvis, om maskin-ID är registrerat med en domän utanför det lokala delnätet eller om användaren loggar in på en domän som inte har en domänkontrollant på det lokala delnätet, kräver inloggningsprocessen kommunikation över WAN. Om det är en långsam länk förlängs inloggningsprocessen.
slutsats
med Windows 9x-klienter uppnås autentisering lokalt genom att göra arbetsgruppens namn detsamma som inloggningen, eller kontot, domänen eller genom att använda b-läge eller m-nod för att säkerställa att inloggningsbegäran sänds lokalt först. Självklart är b-node inte särskilt mångsidig, och det kommer att orsaka en misslyckad inloggning om den lokala domänkontrollanten inte svarar snabbt.
med Windows NT-klienter bör det finnas en resursdomänkontrollant och en kontodomänkontrollant i det lokala segmentet. (Det kan vara en enda server om resurs-och kontodomänerna är desamma.)
du kan förbättra processen ytterligare genom att ha flera WINS-servrar och genom att peka klienterna till WINS-servern som registrerar den lokala eller närmaste domänkontrollanten i listan <1C>.

Richard Charringtons datorkarriär började när han började arbeta med PC-back när de var kända som mikrodatorer. Han började som programmerare och arbetade sig upp till de höga höjderna hos en Windows NT-systemadministratör, och han har gjort nästan allt däremellan. Richard har arbetat med Windows sedan innan det hade en riktig GUI och med Windows NT eftersom det var LANManager. Nu en entreprenör, han har glidit in i manusskrivning för Windows NT och har byggt några mycket användbara auto-admin verktyg.

författarna och redaktörerna har tagit hand om förberedelserna av innehållet häri, men lämnar ingen uttrycklig eller underförstådd garanti av något slag och tar inget ansvar för fel eller försummelser. Inget ansvar tas för eventuella skador. Ha alltid en verifierad säkerhetskopia innan du gör några ändringar.