Articles /

TCP / IP-knudetyper og klientlogon

når du bygger et multisite-domæne, der dirigeres på tværs af flere undernet, kan du antage, at placering af en backup-domænecontroller på et eksternt sted vil sikre, at klienterne på dette sted valideres lokalt. Formålet er selvfølgelig Dobbelt: at reducere den trafik, der går uden for LAN ‘ et over et dyrt link og for at sikre, at klientlogoner ikke forsinkes af hastigheden (eller manglen på den) af Van-forbindelsen. Installation af en lokal domænecontroller fungerer muligvis, men vil denne succes være ved design eller ved et uheld?
desværre er der ingen måde at angive den domænecontroller, der vil validere en given klient, uanset om denne klient kører NT-Server, NT-arbejdsstation eller Vinduer 9 gange. tidligere versioner af vinduer fungerer på samme måde, forudsat at de bruger 32-bit TCP/IP-stakken eller en 16-bit vinder-opmærksom TCP/IP-stak.
i denne daglige øvelse giver vi dig et overblik over de processer, der er involveret. Vi forklarer også, hvorfor en domænecontroller, der er placeret i et andet land på et langsomt modemlink, kan være det, som en klientmaskine vælger til at servicere sin logonanmodning.
baggrund
for dem af jer, der ikke er bekendt med begrebet NT-domæner, er her en hurtig genopfriskning: et NT-domæne er en samling af netværksaktiverede servere og andre computere, der deler fælles sikkerheds-og kontooplysninger. Domænet giver mulighed for centraliseret bruger -, computer-og netværksadministration. Sikkerhedsoplysningerne opbevares i en central database på en server, der er udpeget og konfigureret som den primære domænecontroller (PDC) og replikeres til andre specielle servere, der er udpeget og konfigureret som backup-domænecontrollere (BDC). Kun en server kan være PDC ad gangen, men denne særlige rolle kan overføres til enhver BDC efter behov. Når en klient, der kører TCP/IP, forsøger at logge på dette NT-domæne, behandles logonanmodningen af en af netværkets domænecontrollere, der tilhører det samme domæne.
vinder
vinder servere vedligehold en liste over alle vinder-aktiverede klienter på netværket. Vinder servere opretholder også en liste over domænecontrollere, der er identificeret som type <1C>. Af grunde, der kun var kendt for dem, besluttede designerne af sejre, at der skulle være en grænse på 25 poster på listen <1C>, hvilket betyder, at efterfølgende domænecontrollere ikke vises på denne liste. Klienter får denne liste, når de forsøger at finde en domænecontroller til at servicere deres logonanmodning.
den rækkefølge, som domænecontrollerne vises på listen, følger denne logik:

  1. Domænecontrollerposter registreret hos vinder-serveren, i rækkefølgen af Senest opdateret til mindst opdateret
  2. Domænecontrollerposter opnået fra replikering med andre vinder-servere
  3. den første post er altid PDC

noder
når du konfigurerer TCP/IP på en klient, er en af de muligheder, du kan se (afhængigt af hvor mange på installationen) er node typen. Nodetypen refererer til, hvordan klienten finder en domænecontroller til at servicere sine logonanmodninger.
der er fire knudetyper i TCP / IP:

  • B-node (broadcast node): når en klient skal finde en domænecontroller, udfører den en udsendelse. Den første domænecontroller, der svarer, får opgaven med at servicere logonanmodningen.
  • P-node (punkt-til-punkt-node): i dette miljø går navneforespørgsler direkte til vinder-serveren.
  • M-node (multi-homed node): et m-node miljø bruger b-node først og derefter—om nødvendigt—p-node til at løse navne.
  • h-node (hybrid node): et h-node-miljø bruger p-node først og derefter b-node, hvis navnetjenesten ikke er tilgængelig.

lad os undersøge hver node type mere fuldt ud.
B-node
B-node-tilstanden bruger broadcast-meddelelser til navneregistrering og opløsning. For eksempel, hvis en computer ved navn NT_PC1 ønsker at kommunikere med en computer ved navn NT_PC2, sender NT_PC1 en udsendelsesmeddelelse om, at den leder efter NT_PC2. Det venter derefter et bestemt tidspunkt for NT_PC2 at reagere.
B-node har to store problemer:

  • i et stort miljø indlæser det netværket med udsendelsesmeddelelser.
  • routere videresender typisk ikke udsendelsesmeddelelser, så computere på modsatte sider af en router hører aldrig anmodningerne.

eksempler på computere på netværket, der kan være b-node-klienter, omfatter computere, der kører MS-DOS, vinduer 3.1 eller vinduer til arbejdsgrupper, der ikke har vundet-klientprogrammet installeret. Mulige servere inkluderer Server Message Block (SMB)-baserede netværksservere, f.eks IBM LAN Server, DEC STIVÆRKER, at&t Starlanog LAN Manager til OS/2 eller unikke systemer.
P-node
p-node-tilstanden løser de problemer, som b-node ikke løser. I et P-node miljø, computere hverken oprette eller reagere på broadcast-meddelelser. Alle computere registrerer sig hos vinder-serveren, som er ansvarlig for at kende computernavne og adresser og for at sikre, at der ikke findes duplikatnavne på netværket.
i dette miljø, når NT_PC1 ønsker at kommunikere med NT_PC2, spørger den vinder-serveren til adressen til NT_PC2. Efter modtagelse af adressen går NT_PC1 direkte til NT_PC2 uden udsendelse. Da navneforespørgslerne går direkte til vinder-serveren, undgår p-node at indlæse netværket med udsendelsesmeddelelser. Da broadcast-meddelelser ikke bruges, og adressen modtages direkte, kan computere være på modsatte sider af routere.

de mest betydningsfulde problemer med p-node er:

  • alle computere skal konfigureres til at kende adressen på vinder serveren.
  • hvis vinder-serveren er nede, kan computere, der er afhængige af den til at løse adresser, ikke komme til andre systemer på netværket.

M-node
m-node-tilstanden blev oprettet primært for at løse problemerne forbundet med b-node og p-node. I et m-node-miljø forsøger en computer først registrering og opløsning med b-node. Hvis det mislykkes, skifter det til p-node. Fordele omfatter:

  • M-node kan krydse routere
  • da b-node altid prøves først, fortsætter computere på samme side af en router som normalt, hvis vinder-serveren er nede
  • i teorien skal brug af m-node øge LAN-ydelsen

H-node
h-node-tilstanden løser de mest betydningsfulde problemer forbundet med udsendelsesmeddelelser og dirigerede miljøoperationer. Denne tilstand er en kombination af b-node og p-node, der bruger broadcast-meddelelser som en sidste udvej. H-node-tilstanden gør mere end at ændre rækkefølgen for brug af b-node og p-node: hvis vinder—serveren er nede—hvilket gør udsendelsesmeddelelser til en nødvendighed-fortsætter computeren med at afstemme vinder-serveren. Når GEVINSTSERVEREN kan nås igen, vender systemet tilbage til p-node. H-node også kan konfigureres til at bruge lmhosts fil efter broadcast navn opløsning mislykkes.
da p-node bruges først, genereres der ingen udsendelsesmeddelelser, hvis vinder-serveren kører, og computere kan være på modsatte sider af routere. Hvis GEVINSTSERVEREN er nede, bruges b-node, så computere på samme side af en router fortsætter med at fungere som normalt.
andre kombinationer
en anden variation, kendt som modificeret B-node, bruges også i Microsoft-netværk, så meddelelser kan gå på tværs af routere. Modificeret b-node bruger ikke p-node-tilstand eller en vinder-server. I denne tilstand bruger b-node en liste over computere og adresser, der er gemt i en lmhosts-fil. Hvis et B-node-forsøg mislykkes, ser systemet i LMHOSTS for at finde et navn og bruger derefter den tilknyttede adresse til at krydse routeren. Hver computer skal dog have denne liste, hvilket skaber en administrativ byrde, fordi listen skal opretholdes og distribueres. Begge vinduer til arbejdsgrupper 3.11 og LAN Manager 2.et sådant modificeret B-node-system. NT bruger denne metode, hvis vinder-servere ikke bruges på netværket. Nogle udvidelser er blevet tilføjet til denne fil for at gøre det lettere at administrere, men modificeret b-node er ikke en ideel løsning.
nogle steder kan kræve både B-node og p-node tilstande. Selvom denne konfiguration kan fungere, skal administratorer udvise ekstrem forsigtighed og kun bruge den til overgangssituationer. Da p-node-værter ignorerer udsendelsesmeddelelser, og B-node-værter er afhængige af udsendelsesmeddelelser til navneopløsning, kan de to værter potentielt konfigureres med det samme NetBIOS-navn, hvilket fører til uforudsigelige resultater. Hvis en computer, der er konfigureret til at bruge b-node, har en statisk kortlægning i databasen gevinster, kan en computer, der er konfigureret til at bruge p-node, ikke bruge det samme computernavn.

computere kører vinduer NT kan konfigureres som vinder fuldmægtig agenter til at hjælpe overgangen til at bruge gevinster. Vinduer-baserede netværksklienter (vinder-aktiverede vinduer NT, vinduer 95 eller vinduer til arbejdsgrupper 3.11 computere) kan bruge gevinster direkte. Ikke-vinder computere, der er B-node kompatible (som beskrevet i RFC ‘ er 1001 og 1002) kan få adgang til gevinster gennem fuldmagter. En vinder fuldmægtig er en vinder-aktiveret computer, der lytter til udsendelsesmeddelelser om navneforespørgsler og derefter reagerer på Navne, der ikke findes på det lokale undernet. Fuldmagter er p-node computere.
når du konfigurerer TCP, finder du ingen måde at indstille nodetypen på. Nodetypen er indstillet til en standard under TCP-konfiguration. Standard vinduer 95 TCP / IP node typer er:
hvis DHCP=False, og gevinster er deaktiveret, så Node Type b-node (0h01)
hvis DHCP=False, og gevinster er manuelt indstillet, så Node Type h-node (0h08)
hvis DHCP=True, og DHCP sæt vinder, så Node Type h-node (0h08)
hvis DHCP=True, og gevinster er manuelt indstillet, så Node Type h-node (0h08)
hvis DHCP=true, og gevinster er deaktiveret, så node type B-node (0h01)
hvis vinder serverindstillinger leveres via DHCP, skal node type indstilles ved hjælp af DHCP option 46; imidlertid, lokalt at definere en vinder-server på klienten tilsidesætter disse to muligheder, fordi lokalt definerede vinder-servere automatisk indstiller din node-type til h-node.
nodetypen kan ændres manuelt ved at redigere vinduet 95 registreringsdatabasen. Placeringen findes under undertræet HKEY_LOCAL_MACHINE under undernøglen
SYSTEM\CURRENTCONTROLSET\SERVICES\MSTCP\Node Type
NodeType kan tilføjes som en strengværdi under MSTCP, hvis den ikke allerede findes.
logonanmodningen
lad os nu se på, hvad der sker, når klienten indtaster brugernavn, adgangskode og domæneoplysninger og klikker på OK i logonpromptvinduet (før logonanmodningen serviceres). Vinduer 9 og vinduer NT opfører sig lidt anderledes, så jeg vil diskutere dem separat.
Vinduer 9 gange klient
klienten forsøger at finde en domænecontroller på en måde defineret af den nodetype, som den er konfigureret med. Nedenfor er en meget forenklet rækkefølge af begivenheder:

  1. en B-node-klient sender en anmodning. Hvis en server ikke reagerer, vil logon mislykkes.
  2. en p-node-klient vil anmode om listen< 1C > fra vinder-serveren. Derefter sender den en anmodning til hver af serverne på listen <1C> igen, startende med den første (PDC).
  3. m-node-og h-node-klienterne gør begge disse ting i den rækkefølge, der er beskrevet ovenfor, bortset fra at hvis klientens arbejdsgruppenavn er det samme som det Kontodomæne, som logon forsøges på, bliver VINDEROPSLAGET for domænecontrollere på det lokale undernet sprunget over. Forudsat at vinder-serveren er aktiv og kan nås, betyder det, at den første domænecontroller på listen <1C> til at svare altid håndterer logonanmodningen.

som nævnt ovenfor skal du gøre arbejdsgruppenavnet det samme som det domæne, der er repræsenteret af den pågældende domænecontroller, for at sikre, at klienten er valideret af den lokale domænecontroller. Men hvis du vil bruge arbejdsgrupper i kontormiljøet, er denne metode til at sikre lokal Validering muligvis ikke acceptabel. I dette tilfælde skal nodetypen indstilles til m for at sikre, at klienten oprindeligt sender på det lokale undernet, så der er en bedre chance for, at den lokale domænecontroller reagerer først. Bemærk, at det ikke er en hård og hurtig regel. Domænecontrolleren behøver kun at være lidt optaget-hvilke eksterne site-servere ofte er, fordi det er normalt for administratorer at placere en enkelt domænecontroller på et eksternt sted—og en mere lydhør, ikke-lokal domænecontroller kunne komme ind først.
alternativt kan gevinster installeres på den lokale domænecontroller, og klienterne kan bruge den som den primære GEVINSTSERVER. Denne metode kan være en god ide, hvis brugere sjældent får adgang til ressourcer uden for den lokale filial, men det er en ekstra byrde for serveren, som sandsynligvis leverer fil-og udskrivningstjenester, DHCP, kvm, udveksling og andre opgaver.
hvis arbejdsgruppenavnet er forskelligt fra kontodomænet, øger brugen af m-node chancerne for at få logonanmodningen serviceret lokalt.
vinduer NT—klient
vinduer NT-logon er noget anderledes end Vinduer 9 gange logon-NT-Arbejdsstationen har et maskin-ID i et domæne. Så klienten gennemgår fire trin til logonvalidering. Først validerer NT-Arbejdsstationsklienten sit maskin-ID med domænecontrollerne fra ressourcedomænet, og derefter sender den brugerlogonoplysninger til pass-through Validering. Domænecontrolleren fra ressourcedomænet overfører logonoplysningerne til en domænecontroller i kontodomænet. Resource domain-domain controller sender derefter tilbage brugergodkendelsesoplysningerne (modtaget fra kontodomænedomænecontrolleren) til brugeren.
uanset om brugerne er logget på dem, gennemgår NT-arbejdsstationsklienter id-validering under initialisering og efter behov senere (f.eks. hvis nogen logger på NT-maskinen med den lokale cachelagrede profil, fordi ressourcedomænecontrolleren er nede).
først kommer navneopløsning af domænecontrollere. NT-Arbejdsstationsklienten skal finde en ressourcedomæne-domænecontroller. Den opdagelsesproces, der bruges af en NT-Arbejdsstationsklient til at finde en ressourcedomænecontroller, er den samme som den, der bruges af ressourcedomænedomænecontrolleren til at etablere en pålidelig forbindelse med en kontodomænedomænecontroller.

dernæst valideres NT-maskine-ID ‘ et. NT-Arbejdsstationsklienten sender altid en lokal logonudsendelse til Resource-Domain < 1C >, før unicast-logonanmodninger sendes til resource domain-domain-controllere, der opnås fra gevinster.
klienten validerer NT-arbejdsstationsmaskinens ID-med den første domænecontroller fra ressourcedomænet til at svare tilbage på logonanmodningen.
NT-Arbejdsstationsklienten anmoder ressourcedomænedomænecontrolleren om at opregne listen over betroede domæner. De opnåede domænenavne vises i rullemenuen domæne i logonvinduet.
NT-Arbejdsstationsklienten overfører brugerlogonoplysningerne til ressourcedomænedomænecontrolleren og anmoder om godkendelse af pass-through.
ressourcedomænedomænecontrolleren overfører brugerlogonoplysningerne til den kontodomænedomænecontroller, som den har oprettet en pålidelig forbindelse med, og anmoder den om at godkende brugeren. Den sender derefter valideringsoplysningerne tilbage til NT-Arbejdsstationsklienten.
NT-Arbejdsstationsklienten får navnet på kontodomænedomænecontrolleren fra ressourcedomænedomænecontrolleren til at forbinde og udføre logonscriptet/profilen, hvis det er konfigureret.
NT-brugeren er nu logget på kontodomænet, har udført et logon-script og har lavet passende netværksforbindelser til hjemmekataloger.
hvis maskin-ID ‘ et er registreret med et domæne uden for det lokale undernet, eller hvis brugeren logger på et domæne, der ikke har en domænecontroller på det lokale undernet, vil logonprocessen naturligvis kræve kommunikation over netværket. Hvis det er et langsomt link, forlænges logonprocessen.
konklusion
med Vinduer 9 gange klienter opnås godkendelse lokalt ved at gøre arbejdsgruppenavnet det samme som logon, konto, domæne eller ved at bruge B-tilstand eller m-node for at sikre, at logonanmodningen først udsendes lokalt. Det er klart, at b-node ikke er meget alsidig, og det vil medføre en mislykket logon, hvis den lokale domænecontroller ikke reagerer hurtigt.
med NT-klienter skal der være en ressourcedomænecontroller og en kontodomænecontroller i det lokale segment. (Det kan være en enkelt server, hvis ressource-og kontodomænerne er de samme.)
du kan forbedre processen yderligere ved at have flere GEVINSTSERVERE og ved at pege klienterne på GEVINSTSERVEREN, der registrerer den lokale eller nærmeste domænecontroller i listen <1C>.

Richard Charringtons computerkarriere begyndte, da han begyndte at arbejde med pc ‘ er—tilbage, da de blev kendt som mikrocomputere. Starter som programmør, han arbejdede sig op til de høje højder af en Vinduer NT systemadministrator, og han har gjort næsten alt derimellem. Richard har arbejdet med vinduer siden før det havde en ordentlig GUI og med vinduer NT siden det var LANManager. Nu en entreprenør, har han gled ind script skriftligt til vinduer NT og har bygget nogle meget nyttige auto-admin hjælpeprogrammer.

forfatterne og redaktørerne har sørget for forberedelsen af indholdet heri, men giver ingen udtrykkelig eller underforstået garanti af nogen art og påtager sig intet ansvar for fejl eller udeladelser. Intet ansvar påtages for eventuelle skader. Hav altid en verificeret sikkerhedskopi, inden du foretager ændringer.

Leave a Reply