typy uzlů TCP/IP a přihlášení klienta

když vytváříte doménu pro více webů, která je směrována přes několik podsítí, můžete předpokládat, že umístění řadiče záložní domény na vzdáleném webu zajistí, že klienti na tomto webu budou ověřeni lokálně. Účel je samozřejmě dvojí: snížit provoz, který půjde mimo LAN přes drahý odkaz, a zajistit, aby logony klientů nebyly zpožděny rychlostí (nebo nedostatkem) připojení WAN. Instalace řadiče místní domény může skutečně fungovat, ale bude tento úspěch záměrný nebo náhodou?
bohužel neexistuje způsob, jak určit řadič domény, který bude ověřovat daného klienta, ať už je tento klient se systémem Windows NT Server, Windows NT Workstation nebo Windows 9x. předchozí verze systému Windows budou fungovat stejným způsobem za předpokladu, že používají 32bitový zásobník TCP/IP nebo 16bitový zásobník TCP/IP, který si uvědomuje WINS.
v tomto denním cvičení vám poskytneme přehled procesů, které jsou zapojeny. Vysvětlíme také, proč řadič domény, který je umístěn v jiné zemi na pomalém modemovém odkazu, může být ten, který klientský počítač vybere pro obsluhu svého požadavku na přihlášení.
pozadí
pro ty z vás, kteří nejsou obeznámeni s konceptem domén Windows NT, je zde rychlé obnovení: doména NT je sbírka síťových serverů a dalších počítačů, které sdílejí společné informace o zabezpečení a účtu. Doména zajišťuje centralizovanou správu uživatelů, počítačů a sítí. Bezpečnostní informace jsou uchovávány v centrální databázi na serveru, který je označen a nakonfigurován jako primární řadič domény (PDC) a je replikován na jiné speciální servery, které jsou označeny a nakonfigurovány jako řadiče záložní domény (BDC). PDC může být kdykoli pouze jeden server, ale tato speciální role může být podle potřeby přenesena na libovolné BDC. Když se klient se systémem TCP/IP pokusí přihlásit k této doméně NT, žádost o přihlášení zpracovává některý z řadičů domény sítě, které patří do stejné domény.
WINS
WINS servery udržují seznam všech klientů s podporou WINS v síti. Servery WINS také udržují seznam řadičů domény, které jsou označeny jako typ <1C>. Z důvodů, které jsou jim známy, se návrháři WINS rozhodli, že v seznamu <1C> by měl být limit 25 položek, což znamená, že následující řadiče domény se na tomto seznamu neobjeví. Klientům je tento seznam poskytnut, když se pokusí najít řadič domény, který by obsloužil jejich žádost o přihlášení.
pořadí, ve kterém se řadiče domény objevují v seznamu, se řídí touto logikou:

1. položky řadiče domény registrované na serveru WINS, v pořadí Naposledy obnovené na nejméně nedávno obnovené
2. položky řadiče domény získané replikací s jinými servery WINS
3. první položka je vždy PDC

uzly
při konfiguraci TCP / IP na klientovi je jednou z možností, kterou můžete vidět (v závislosti na instalaci), typ uzlu. Typ uzlu odkazuje na to, jak klient najde řadič domény, aby splnil své požadavky na přihlášení.
v TCP / IP jsou čtyři typy uzlů:

• B-uzel (broadcast node): když klient potřebuje najít řadič domény, provede vysílání. První řadič domény, který odpoví, bude předán úloze servisu žádosti o přihlášení.
• P-node (point-to-point node): v tomto prostředí přejdou dotazy na jméno přímo na server WINS.
• m-node (multi-homed node): prostředí m-node používá nejprve B-node a poté-v případě potřeby-P-node k vyřešení jmen.
• H-node (hybridní uzel): prostředí h-node používá nejprve P-node a poté B-node, pokud služba name není k dispozici.

podívejme se na každý typ uzlu podrobněji.
B-node
režim B-node používá vysílané zprávy pro registraci a rozlišení jmen. Pokud například počítač s názvem NT_PC1 chce komunikovat s počítačem s názvem NT_PC2, NT_PC1 odešle vysílanou zprávu, že hledá NT_PC2. Poté čeká na stanovenou dobu, než NT_PC2 odpoví.
B-uzel má dva hlavní problémy:

• ve velkém prostředí načte síť vysílanými zprávami.
• směrovače obvykle nepředávají vysílané zprávy, takže počítače na opačných stranách routeru nikdy neuslyší požadavky.

příklady počítačů v síti, které mohou být klienty B-uzlu, zahrnují počítače se systémem MS-DOS, Windows 3.1 nebo Windows pro pracovní skupiny, které nemají nainstalovaný klientský software WINS. Mezi možné servery patří síťové servery založené na serveru Message Block (SMB), například IBM LAN Server, DEC PATHWORKS, AT &T StarLAN a LAN Manager pro systémy OS/2 nebo UNIX.
P-node
režim P-node řeší problémy, které b-node nevyřeší. V prostředí p-uzlu počítače nevytvářejí ani nereagují na vysílané zprávy. Všechny počítače se registrují na serveru WINS, který je zodpovědný za znalost názvů a adres počítačů a za zajištění toho, aby v síti neexistovaly žádné duplicitní názvy.
v tomto prostředí, když NT_PC1 chce komunikovat s NT_PC2, požádá server WINS o adresu NT_PC2. Po obdržení adresy přejde NT_PC1 přímo na NT_PC2 bez vysílání. Protože dotazy na jméno jdou přímo na server WINS, P-node se vyhýbá načítání sítě pomocí vysílaných zpráv. Protože se nepoužívají vysílané zprávy a adresa je přijímána přímo, počítače mohou být na opačných stranách směrovačů.
nejvýznamnější problémy s p-uzlem jsou:

• všechny počítače musí být nakonfigurovány tak, aby znaly adresu serveru WINS.
• pokud je server WINS nefunkční, počítače, které se na něj spoléhají při řešení adres, se nemohou dostat do jiných systémů v síti.

m-node
režim M-node byl vytvořen primárně pro řešení problémů spojených s B-uzlem a p-uzlem. V prostředí m-uzlu se počítač nejprve pokusí o registraci a rozlišení pomocí B-uzlu. Pokud se to nezdaří, přepne se na P-uzel. Mezi výhody patří:

• M-node může křížit směrovače
• protože b-node je vždy vyzkoušen jako první, počítače na stejné straně routeru nadále fungují jako obvykle, pokud je server WINS nefunkční
• teoreticky by použití M-node mělo zvýšit výkon LAN

h-node
režim h-node řeší nejvýznamnější problémy spojené s vysíláním zpráv a operacemi směrovaného prostředí. Tento režim je kombinací B-uzlu a p-uzlu, který používá vysílané zprávy jako poslední možnost. Režim h-node dělá více než změnit pořadí pro použití B-node a p-node: v případě, že server WINS je down-takže vysílání zpráv nutnost-počítač pokračuje hlasování WINS server. Po opětovném dosažení serveru WINS se systém vrátí do P-uzlu. H-node lze také nakonfigurovat tak, aby používal soubor LMHOSTS po selhání rozlišení názvu vysílání.
vzhledem k tomu, že p-node je použit jako první, nejsou generovány žádné vysílané zprávy, pokud je spuštěn server WINS a počítače mohou být na opačných stranách směrovačů. Pokud je server WINS nefunkční, použije se b-node, takže počítače na stejné straně routeru nadále fungují jako obvykle.
jiné kombinace
další varianta, známá jako modifikovaný B-uzel, se také používá v sítích společnosti Microsoft, takže zprávy mohou procházet směrovači. Modifikovaný B-uzel nepoužívá režim P-uzlu ani server WINS. V tomto režimu b-node používá seznam počítačů a adres, které jsou uloženy v souboru LMHOSTS. Pokud se pokus o b-uzel nezdaří, systém vyhledá v LMHOSTS jméno a poté použije přidruženou adresu k překročení routeru. Každý počítač však musí mít tento seznam, což vytváří administrativní zátěž, protože seznam musí být udržován a distribuován. Obě okna pro pracovní skupiny 3.11 a LAN Manager 2.x použil takový upravený systém B-uzlu. Windows NT používá tuto metodu, pokud servery WINS nejsou v síti používány. V systému Windows NT byly do tohoto souboru přidány některé přípony, které usnadňují správu, ale upravený B-uzel není ideálním řešením.
některé weby mohou vyžadovat režimy b-node i p-node. Ačkoli tato konfigurace může fungovat, Administrátoři musí být velmi opatrní a používat ji pouze pro přechodové situace. Vzhledem k tomu, že hostitelé P-uzlu ignorují vysílané zprávy a hostitelé B-uzlu spoléhají na vysílané zprávy pro rozlišení názvu, mohou být oba hostitelé potenciálně nakonfigurováni se stejným názvem NetBIOS, což vede k nepředvídatelným výsledkům. Pokud má počítač nakonfigurovaný pro použití B-uzlu statické mapování v databázi WINS, počítač nakonfigurovaný pro použití P-uzlu nemůže použít stejný název počítače.

počítače se systémem Windows NT mohou být nakonfigurovány jako agenti proxy WINS, kteří pomáhají při přechodu na používání WINS. Síťoví klienti se systémem Windows (Windows NT, Windows 95 nebo Windows pro pracovní skupiny 3.11 počítače s podporou WINS) mohou používat WINS přímo. Počítače bez výher, které jsou kompatibilní s B-uzlem (jak je popsáno v RFC 1001 a 1002), mají přístup k výhrám prostřednictvím proxy. WINS proxy je počítač s podporou WINS, který poslouchá zprávy o vysílání dotazu na jméno a poté reaguje na jména, která nejsou v místní podsíti. Proxy jsou počítače S P-uzlem.
při konfiguraci TCP nenajdete žádný Způsob nastavení typu uzlu. Typ uzlu je během konfigurace TCP nastaven na výchozí hodnotu. Výchozí typy uzlů TCP/IP systému Windows 95 jsou:
pokud DHCP=False a WINS je zakázán, pak typ uzlu B-node (0x01)
pokud je DHCP=False a WINS ručně nastaven, pak typ uzlu h-node (0x08)
pokud DHCP=True a DHCP nastaví WINS, pak typ uzlu h-node (0x08)
pokud je DHCP=True a WINS ručně nastaven, pak typ uzlu h-node (0x08)
pokud je DHCP=True a WINS deaktivován, pak typ uzlu b-node (0x01)
pokud jsou volby serveru wins poskytovány prostřednictvím DHCP, měl by být typ uzlu nastaven pomocí volby DHCP 46; lokální definování serveru WINS v klientovi však tyto dvě možnosti přepíše, protože lokálně definované servery WINS automaticky nastaví typ uzlu na h-uzel.
typ uzlu lze změnit ručně úpravou registru systému Windows 95. Umístění existuje pod podstrom HKEY_LOCAL_MACHINE pod podklíčem
SYSTEM \ CURRENTCONTROLSET\SERVICES \ VXD\MSTCP \ Node Type
NodeType lze přidat jako hodnotu řetězce pod MSTCP, pokud již neexistuje.
žádost o přihlášení
nyní se podívejme na to, co se děje poté, co klient zadá informace o uživatelském jménu, hesle a doméně a klikne na OK v okně výzvy k přihlášení (před servisem žádosti o přihlášení). Windows 9x a Windows NT se chovají trochu jinak, takže o nich budu diskutovat samostatně.
Windows 9x client
klient se pokusí najít řadič domény způsobem definovaným typem uzlu, se kterým byl nakonfigurován. Níže je velmi zjednodušená posloupnost událostí:

1. klient B-uzlu vysílá požadavek. Pokud server neodpovídá, přihlášení se nezdaří.
2. klient P-uzlu požádá ze serveru WINS seznam <1C>. Poté vyšle požadavek na každý ze serverů v seznamu <1C>, počínaje prvním (PDC).
3. klienti m-node a H-node dělají obě tyto věci v pořadí popsaném výše, kromě toho, že pokud je název pracovní skupiny klienta stejný jako doména účtu, ke které se pokouší o přihlášení, je vyhledávání WINS pro řadiče domény v místní podsíti přeskočeno. Pokud je server WINS aktivní a dosažitelný, znamená to, že první řadič domény v seznamu <1C>, který odpoví, bude vždy zpracovávat požadavek na přihlášení.

jak bylo uvedeno výše, abyste zajistili, že klient bude ověřen místním řadičem domény, musíte název pracovní skupiny nastavit stejně jako doménu reprezentovanou tímto řadičem domény. Pokud však chcete používat pracovní skupiny v kancelářském prostředí, nemusí být tento způsob zajištění místní validace přijatelný. V tomto případě by měl být typ uzlu nastaven na m, aby se zajistilo, že klient nejprve vysílá v místní podsíti, takže existuje větší šance, že řadič místní domény nejprve odpoví. Všimněte si, že to není tvrdé a rychlé pravidlo. Řadič domény musí být jen trochu zaneprázdněn-což jsou servery vzdálených webů často, protože je obvyklé, že administrátoři umístí jeden řadič domény na vzdálený web—a jako první by se mohl dostat citlivější řadič domény, který není lokální.
alternativně lze WINS nainstalovat na řadič místní domény a klienti jej mohli použít jako primární server WINS. Tato metoda může být dobrý nápad, pokud uživatelé zřídka přistupují k prostředkům mimo místní pobočku, ale je to další zátěž pro server, který pravděpodobně poskytuje souborové a tiskové služby, DHCP, SQL, Exchange a další povinnosti.
pokud se název pracovní skupiny liší od domény účtu, pak použití M-node zvýší šance na místní opravu požadavku na přihlášení.
Windows NT client
Windows NT logon se poněkud liší od Windows 9x logon—pracovní stanice NT má ID počítače v doméně. Klient tedy prochází čtyřmi kroky pro ověření přihlášení. Klient NT Workstation nejprve ověří své ID počítače pomocí řadičů domény z domény prostředků a poté odešle informace o přihlášení uživatele k ověření průchodu. Řadič domény z domény zdroje předává přihlašovací informace řadiči domény v doméně účtu. Řadič domény-domény zdroje poté předá uživateli informace o ověření uživatele (přijaté z řadiče domény-domény účtu).
bez ohledu na to, zda jsou k nim uživatelé přihlášeni, klienti NT Workstation procházejí ověřením ID během inicializace a podle potřeby později (například pokud se někdo přihlásí k počítači NT s místním profilem uloženým v mezipaměti, protože řadič domény zdrojů je nefunkční).
nejprve přichází rozlišení názvů řadičů domény. Klient NT Workstation musí najít doménu zdroje-řadič domény. Proces zjišťování, který používá klient NT Workstation k nalezení řadiče domény prostředků, je stejný jako proces, který používá řadič domény prostředků k navázání důvěryhodného spojení s řadičem domény účtu.
dále je ověřeno ID stroje NT. Klient NT Workstation vždy odešle lokální přihlašovací vysílání do Resource-Domain <1C> před odesláním požadavků unicast přihlášení do řadičů resource domain-domain, které jsou získány z WINS.

klient ověřuje ID počítače NT Workstation-s prvním řadičem domény z domény zdroje, který odpoví zpět na požadavek přihlášení.
klient NT Workstation požaduje, aby řadič domény zdroje-domény vyjmenoval seznam důvěryhodných domén. Získaná doménová jména se zobrazí v rozevíracím seznamu doména v přihlašovacím okně.
klient NT Workstation předá přihlašovací údaje uživatele řadiči domény zdroje-domény a požaduje ověření průchodu.
řadič domény-domény prostředků předá přihlašovací údaje uživatele řadiči domény-domény účtu, se kterým navázal důvěryhodné připojení, a požádá jej o ověření uživatele. Poté předá informace o ověření klientovi NT Workstation.
klient NT Workstation získá název řadiče domény účtu-domény z řadiče domény zdroje pro připojení a spuštění přihlašovacího skriptu / profilu, pokud byl nakonfigurován.
uživatel NT je nyní přihlášen k doméně účtu, provedl přihlašovací skript a provedl příslušná síťová připojení k domovským adresářům.
samozřejmě, pokud je ID stroje zaregistrováno s doménou mimo místní podsíť nebo pokud se uživatel přihlašuje k doméně, která nemá řadič domény v místní podsíti, proces přihlášení bude vyžadovat komunikaci přes WAN. Pokud se jedná o pomalý odkaz, proces přihlášení bude rozšířen.
závěr
u klientů systému Windows 9x je lokálně ověřeno, že název pracovní skupiny je stejný jako přihlašovací jméno nebo účet, doména nebo pomocí režimu b nebo M-node, aby se zajistilo, že žádost o přihlášení bude nejprve vysílána lokálně. Je zřejmé, že B-node není příliš univerzální a pokud místní řadič domény nereaguje rychle, způsobí neúspěšné přihlášení.
u klientů Windows NT by měl být v místním segmentu řadič domény zdrojů a řadič domény účtu. (Může to být jeden server, pokud jsou domény zdrojů a účtů stejné.)
proces můžete dále vylepšit tím, že budete mít více serverů WINS a nasměrujete klienty na server WINS, který zaregistruje místní nebo nejbližší řadič domény v seznamu <1C>.

počítačová kariéra Richarda Charringtona začala, když začal pracovat s počítači-zpět, když byly známé jako mikropočítače. Začínal jako programátor, propracoval se až do vznešených výšin správce systémů Windows NT a udělal téměř všechno mezi tím. Richard pracuje s Windows, protože předtím, než měl správné GUI a Windows NT, protože to byl LANManager. Nyní dodavatel, on vklouzl do psaní skriptů pro Windows NT a vybudoval některé velmi užitečné auto-admin nástroje.

autoři a editoři se postarali o přípravu obsahu obsaženého v tomto dokumentu, ale neposkytují žádné výslovné ani předpokládané záruky jakéhokoli druhu a nenesou žádnou odpovědnost za chyby nebo opomenutí. Za škody se nepřebírá žádná odpovědnost. Před provedením jakýchkoli změn mějte vždy ověřenou zálohu.