tcp / IP-nodetyper og klientpålogging

når du bygger et domene med flere områder som rutes over flere undernett, kan du anta at det å sette en domenekontroller for sikkerhetskopiering på et eksternt område vil sikre at klientene på dette området blir validert lokalt. Formålet er selvsagt todelt: å redusere trafikken som vil gå utenfor LAN over en dyr kobling og for å sikre at klientloggene ikke forsinkes av hastigheten (eller mangelen på DET) PÅ WAN-tilkoblingen. Installere en lokal domenekontroller kan faktisk fungere, men vil den suksessen være ved design eller ved et uhell?
Dessverre er det ingen måte å angi domenekontrolleren som skal validere en gitt klient, enten den klienten kjører Windows Nt Server, Windows Nt Workstation eller Windows 9x. Tidligere versjoner av Windows vil fungere på samme måte, forutsatt at De bruker 32-biters TCP / IP-stakken eller en 16-biters WINS-oppmerksom TCP/IP-stack.
i Denne Daglige Drillen Gir vi deg en oversikt over prosessene som er involvert. Vi vil også forklare hvorfor en domenekontroller som er plassert i et annet land på en treg modemkobling, kan være den som er valgt av en klientmaskin for å betjene påloggingsforespørselen.
Bakgrunn
for de av dere som ikke er kjent med begrepet Windows nt-domener, her er en rask oppdatering: ET nt-domene er en samling av nettverksaktiverte servere og andre datamaskiner som deler felles sikkerhets-og kontoinformasjon. Domenet gir for sentralisert bruker, datamaskin og nettverksadministrasjon. Sikkerhetsinformasjonen oppbevares i en sentral database på en server som er utpekt og konfigurert som PRIMÆRDOMENEKONTROLLER (PDC) og replikeres til andre spesielle servere, som er utpekt og konfigurert som backup domain controllers (bdc). BARE en server KAN VÆRE PDC til enhver tid, men denne spesielle rollen kan overføres til HVILKEN SOM HELST BDC etter behov. Når en klient som kjører TCP/IP forsøker å logge på DETTE nt-domenet, behandles påloggingsforespørselen av en av nettverkets domenekontrollere som tilhører samme domene.
WINS
wins-servere opprettholder en liste over ALLE wins-aktiverte klienter på nettverket. WINS-servere har også en liste over domenekontrollere som er identifisert som type < 1C >. Av grunner som kun er kjent FOR DEM, bestemte designerne AV WINS at det skulle være en grense på 25 oppføringer i listen <1c>, noe som betyr at etterfølgende domenekontrollere ikke vil vises på denne listen. Klienter får denne listen når de prøver å finne en domenekontroller for å betjene påloggingsforespørselen.
rekkefølgen domenekontrollere vises i på listen, følger denne logikken:

1. Domenekontrolleroppføringer registrert MED wins-serveren, i rekkefølgen sist oppdatert til minst nylig oppdatert
2. Domenekontrolleroppføringer hentet fra replikering med ANDRE wins-servere
3. DEN første oppføringen ER ALLTID PDC

Noder
når du konfigurerer TCP/IP på en klient, er ett av alternativene du kan se (avhengig AV på installasjonen) er nodetypen. Nodetypen refererer til hvordan klienten finner en domenekontroller for å betjene påloggingsforespørslene.
det finnes fire nodetyper I TCP / IP:

• b-node (broadcast node): Når en klient trenger å finne en domenekontroller, vil den utføre en kringkasting. Den første domenekontrolleren som svarer, får jobben med å betjene påloggingsforespørselen.
• P-node( punkt-til-punkt-node): i dette miljøet går navnespørringer direkte til wins-serveren.
• M-node( multi-homed node): Et m-node-miljø bruker b-node først og deretter—om nødvendig-p-node for å løse navn.
• h-node (hybrid node): et h-node-miljø bruker p-node først og deretter b-node hvis navnetjenesten ikke er tilgjengelig.

la oss undersøke hver nodetype mer fullstendig.
B-node
b-node-modusen bruker kringkastingsmeldinger for registrering og oppløsning av navn. HVIS for eksempel EN DATAMASKIN SOM heter NT_PC1 vil kommunisere MED en datamaskin som heter NT_PC2, SENDER NT_PC1 en kringkastingsmelding om AT DEN leter ETTER NT_PC2. Den venter deretter en bestemt tid FOR NT_PC2 å svare.
B-node har to store problemer:

• I et stort miljø laster det nettverket med kringkastingsmeldinger.
• rutere videresender vanligvis ikke kringkastingsmeldinger, slik at datamaskiner på motsatte sider av en ruter aldri hører forespørslene.

Eksempler på datamaskiner på nettverket som kan være b-node-klienter, inkluderer datamaskiner som kjører MS-DOS, Windows 3.1 eller Windows For Arbeidsgrupper som ikke har INSTALLERT wins-klientprogramvare. Mulige servere inkluderer SERVER Message Block (SMB)-baserte nettverksservere, SLIK SOM IBM LAN Server, DEC PATHWORKS, AT&T StarLAN, OG LAN Manager FOR OS/2 eller UNIX-systemer.
P-node
p-node-modus løser problemene som b-node ikke løser. I en p-node miljø, datamaskiner verken opprette eller svare på kringkastingsmeldinger. Alle datamaskiner registrerer SEG med wins-serveren, som er ansvarlig for å kjenne datamaskinnavn og adresser og for å sikre at det ikke finnes dupliserte navn på nettverket.
I dette miljøet, NÅR NT_PC1 ønsker å kommunisere MED NT_PC2, spør DEN wins-serveren for ADRESSEN TIL NT_PC2. VED mottak av adressen GÅR NT_PC1 direkte til NT_PC2 uten kringkasting. Siden navneforespørslene går direkte til wins-serveren, unngår p-node å laste nettverket med kringkastingsmeldinger. Siden kringkastingsmeldinger ikke brukes og adressen mottas direkte, kan datamaskiner være på motsatte sider av rutere.

de viktigste problemene med p-node er:

• alle datamaskiner må være konfigurert til å vite adressen TIL wins-serveren.
• hvis wins-serveren er nede, kan ikke datamaskiner som er avhengige av den for å løse adresser, komme til andre systemer på nettverket.

M-node
m-node-modusen ble opprettet primært for å løse problemene knyttet til b-node og p-node. I et m-node-miljø forsøker en datamaskin først registrering og oppløsning med b-node. Hvis det mislykkes, bytter det til p-node. Fordeler inkluderer:

• M-node kan krysse rutere
• siden b-node alltid blir prøvd først, fortsetter datamaskiner på samme side av en ruter å fungere som vanlig hvis wins-serveren er nede
• i teorien skal bruk av m-node øke LAN-ytelsen

H-node
h-node-modusen løser de viktigste problemene knyttet til kringkastingsmeldinger og rutede miljøoperasjoner. Denne modusen er en kombinasjon av b-node og p-node som bruker kringkastingsmeldinger som en siste utvei. H-node-modusen gjør mer enn å endre rekkefølgen for bruk av b-node og p-node: HVIS wins-serveren er nede – noe som gjør kringkastingsmeldinger en nødvendighet – fortsetter datamaskinen å avstemme wins-serveren. Når wins-serveren kan nås igjen, går systemet tilbake til p-node. H-node kan også konfigureres til å bruke lmhosts filen etter kringkasting navn oppløsning mislykkes.
siden p-node brukes først, genereres ingen kringkastingsmeldinger hvis wins-serveren kjører, og datamaskiner kan være på motsatte sider av rutere. HVIS wins-serveren er nede, brukes b-node, slik at datamaskiner på samme side av en ruter fortsetter å fungere som vanlig.
Andre kombinasjoner
En annen variant, kjent som modifisert b-node, brukes også I Microsoft-nettverk slik at meldinger kan gå på tvers av rutere. Modifisert b-node bruker ikke p-node-modus eller EN wins-server. I denne modusen bruker b-node en liste over datamaskiner og adresser som er lagret i en lmhosts-fil. Hvis et b-node-forsøk mislykkes, ser systemet ut I LMHOSTS for å finne et navn og bruker deretter den tilknyttede adressen til å krysse ruteren. Hver datamaskin må imidlertid ha denne listen, noe som skaper en administrativ byrde fordi listen må vedlikeholdes og distribueres. Både Windows For Arbeidsgrupper 3.11 OG LAN Manager 2.x brukte et slikt modifisert b-node system. Windows nt bruker denne metoden hvis wins-servere ikke brukes på nettverket. I Windows NT har noen utvidelser blitt lagt til denne filen for å gjøre det enklere å administrere, men modifisert b-node er ikke en ideell løsning.
Noen områder kan kreve både b-node og p-node moduser. Selv om denne konfigurasjonen kan fungere, må administratorer utvise ekstrem forsiktighet og bruke den bare for overgangssituasjoner. Siden p-node-verter ignorerer kringkastingsmeldinger og b-node-verter er avhengige av kringkastingsmeldinger for navneløsning, kan de to vertene potensielt konfigureres med Samme NetBIOS-navn, noe som fører til uforutsigbare resultater. Hvis en datamaskin som er konfigurert til å bruke b-node, har en statisk tilordning I wins-databasen, kan ikke en datamaskin som er konfigurert til å bruke p-node bruke samme datamaskinnavn.

Datamaskiner som kjører Windows Nt, kan konfigureres SOM wins-proxy-agenter for å hjelpe overgangen til Å bruke WINS. Windows-baserte nettverksklienter (wins-aktiverte Windows Nt, Windows 95 eller Windows for Arbeidsgrupper 3.11-datamaskiner) kan bruke WINS direkte. Ikke-WINS-datamaskiner som er b-node-kompatible (som beskrevet I RFCs 1001 og 1002), kan få TILGANG TIL WINS via proxyer. EN wins-proxy er en wins-aktivert datamaskin som lytter etter kringkastingsmeldinger for navnespørring og deretter svarer for navn som ikke er på det lokale delnettverket. Proxyer er p-node datamaskiner.
når du konfigurerer TCP, finner du ingen måte å angi nodetypen på. Nodetypen er satt til en standard under tcp-konfigurasjon. Standard windows 95 tcp/IP-nodetyper er:
Hvis DHCP=False, OG WINS er deaktivert, Så Node type b-node (0x01)
Hvis DHCP=False, OG WINS er manuelt angitt, Så Node type h-node (0x08)
HVIS DHCP=True, OG WINS er manuelt angitt, Så Node type h-node (0x08)
Hvis dhcp=true, Og Wins ER DEAKTIVERT, så nodetype B-node (0x01)
hvis wins-serveralternativer leveres Via Dhcp, Bør Nodetype angis ved hjelp av dhcp-alternativ 46; men lokalt definere EN wins-server på klienten vil overstyre disse to alternativene fordi lokalt definerte wins-servere automatisk angi nodetypen til h-node.
nodetypen kan endres manuelt ved å redigere Windows 95-Registret. Plasseringen finnes Under UNDERTREET HKEY_LOCAL_MACHINE under undernøkkelen
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\Mstcp\Node Type
NodeType kan legges Til Som En Strengverdi UNDER MSTCP hvis Den ikke allerede finnes.
påloggingsforespørselen
nå, la Oss se på hva som skjer etter at klienten går inn i brukernavn, passord og domeneinformasjon og klikker OK i påloggingspromptvinduet(før påloggingsforespørselen blir betjent). Windows 9x Og Windows Nt oppfører seg litt annerledes, så jeg diskuterer dem separat.
Windows 9x client
klienten forsøker å finne en domenekontroller på en måte som er definert av nodetypen den er konfigurert med. Nedenfor er en svært forenklet rekkefølge av hendelser:

1. en b-node klient vil kringkaste en forespørsel. Hvis en server ikke svarer, mislykkes påloggingen.
2. en p-node-klient vil be om <1c> – listen fra wins-serveren. Det vil da kringkaste en forespørsel til hver av serverne i < 1c > listen i sin tur, og starter med den første (PDC).
3. m-node-og h-node-klientene gjør begge disse tingene i rekkefølgen som er beskrevet ovenfor, bortsett fra at HVIS klientens arbeidsgruppenavn er det samme som kontodomenet som påloggingen forsøkes, hoppes wins-oppslaget FOR domenekontrollere på det lokale delnettet. Forutsatt AT wins-serveren er aktiv og tilgjengelig, betyr det at den første domenekontrolleren i <1c> – listen som svarer, alltid håndterer påloggingsforespørselen.

som nevnt ovenfor, for å sikre at klienten er validert av den lokale domenekontrolleren, må du gjøre arbeidsgruppenavnet det samme som domenet som representeres av domenekontrolleren. Hvis du vil bruke arbeidsgrupper i kontormiljøet, kan det imidlertid hende at denne metoden for å sikre lokal validering ikke er akseptabel. I dette tilfellet bør nodetypen settes til m for å sikre at klienten sender på det lokale subnettet først, slik at det er en bedre sjanse for at den lokale domenekontrolleren svarer først. Merk at det ikke er en hard og rask regel. Domenekontrolleren trenger bare å være litt opptatt – hvilke eksterne nettstedsservere er ofte fordi det er vanlig for administratorer å sette en enkelt domenekontroller på et eksternt nettsted-og en mer responsiv, ikke-lokal domenekontroller kan komme inn først.
ALTERNATIVT KAN WINS installeres på den lokale domenekontrolleren, og klientene kan bruke DEN som den primære wins-serveren. Denne metoden kan være en god ide hvis brukere sjelden får tilgang til ressurser utenfor den lokale grenen, men det er en ekstra byrde på serveren, som sannsynligvis gir fil-og utskriftstjenester, DHCP, SQL, Exchange og andre oppgaver.
hvis arbeidsgruppenavnet er forskjellig fra kontodomenet, vil bruk av m-node øke sjansene for å få påloggingsforespørselen betjent lokalt.
Windows nt-klient
Windows nt-pålogging er noe forskjellig Fra windows 9x-pålogging-NT-Arbeidsstasjonen har en maskin-ID i et domene. Så går klienten gjennom fire trinn for påloggingsvalidering. FØRST validerer nt Workstation-klienten sin maskin-ID med domenekontrollere fra ressursdomenet, og deretter sender den brukerpåloggingsinformasjon for gjennomgangsvalidering. Domenekontrolleren fra ressursdomenet sender påloggingsinformasjonen til en domenekontroller i kontodomenet. Ressursdomene-domenekontrolleren sender deretter tilbake brukerautentiseringsinformasjonen (mottatt fra kontodomene-domenekontrolleren) til brukeren.
Uansett om brukere er logget på DEM, går nt Workstation-klienter GJENNOM id-validering under initialisering og etter behov senere(for eksempel hvis noen logger PÅ nt-maskinen med den lokale bufrede profilen fordi ressursdomenekontrolleren er nede).
først kommer navneløsning for domenekontrollere. Nt Workstation-klienten må finne en ressurs domene-domenekontroller. Oppdagelsesprosessen som brukes AV en Nt Workstation-klient til å finne en ressursdomenekontroller, er den samme som den som brukes av ressursdomenekontrolleren til å opprette en klarert tilkobling med en kontodomenekontroller.

deretter valideres nt-maskin-IDEN. Nt Workstation-klienten sender alltid en lokal pålogging til Ressurs-Domene < 1C > før du sender unicast-påloggingsforespørsler til ressurs-domene-domenekontrollere som er hentet FRA WINS.
klienten validerer nt Arbeidsstasjon maskin-ID – med den første domenekontrolleren fra ressursdomenet til å svare tilbake på påloggingsforespørselen.
nt Workstation-klienten ber ressursdomene-domenekontrolleren om å nummerere listen over klarerte domener. De innhentede domenenavnene vises i Rullegardinlisten Domene i påloggingsvinduet.
nt Workstation-klienten sender påloggingslegitimasjonen for brukeren til ressursdomene-domenekontrolleren og ber om godkjenning.
ressursdomene-domenekontrolleren sender brukerpåloggingslegitimasjonen til konto-domenekontrolleren som den har opprettet en klarert tilkobling med, og ber den om å godkjenne brukeren. Den sender deretter valideringsinformasjonen tilbake TIL Nt Workstation-klienten.
Nt Workstation-klienten får navnet på konto domene-domenekontrolleren fra ressurs domene-domenekontrolleren for å koble til og utføre påloggingsskriptet / profilen, hvis den er konfigurert.
nt-brukeren er nå logget på kontodomenet, har utført et påloggingsskript og har gjort passende nettverkstilkoblinger til hjemmekataloger.
selvfølgelig, hvis maskinen ID er registrert med et domene utenfor det lokale subnettet, eller hvis brukeren logger på et domene som ikke har en domenekontroller på det lokale subnettet, vil påloggingsprosessen kreve kommunikasjon over WAN. Hvis det er en treg kobling, vil påloggingsprosessen bli utvidet.
Konklusjon
med Windows 9x-klienter oppnås godkjenning lokalt ved å gjøre arbeidsgruppenavnet det samme som påloggingen eller kontoen, domenet eller ved å bruke b-modus eller m-node for å sikre at påloggingsforespørselen sendes lokalt først. Åpenbart er b-node ikke veldig allsidig, og det vil føre til en mislykket pålogging hvis den lokale domenekontrolleren ikke reagerer raskt.
Med Windows NT-klienter, bør det være en ressurs domenekontroller og en konto domenekontroller i det lokale segmentet. (Det kan være en enkelt server hvis ressurs-og kontodomenene er de samme.)
du kan forbedre prosessen ytterligere ved å ha flere wins-servere og ved å peke klientene TIL wins-serveren som vil registrere den lokale eller nærmeste domenekontrolleren i listen<1C >.

Richard Charringtons datakarriere begynte da Han begynte å jobbe Med Pcer-tilbake da de var kjent som mikrodatamaskiner. Starter som programmerer, han jobbet seg opp til høye høyder Av En Windows NT Systemadministrator, og han har gjort omtrent alt i mellom. Richard har jobbet Med Windows siden før den hadde en skikkelig GUI og Med Windows NT siden Det Var LANManager. Nå en entreprenør, han har gled inn skriptskriving For Windows Nt og har bygget noen svært nyttige auto-admin verktøy.

forfatterne og redaktørene har tatt vare på forberedelsen av innholdet heri, men gir ingen uttrykt eller underforstått garanti av noe slag og påtar seg intet ansvar for feil eller utelatelser. Ingen ansvar antas for eventuelle skader. Alltid ha en bekreftet backup før du gjør noen endringer.