tipos de nó TCP/IP e logon do cliente

quando você está construindo um domínio de vários sites roteado em várias sub-redes, você pode assumir que colocar um controlador de domínio de backup em um site remoto garantirá que os clientes nesse site sejam validados localmente. O objetivo, é claro, é duplo: reduzir o tráfego que sairá da LAN por um link caro e garantir que os logons do cliente não sejam atrasados pela velocidade (ou falta dela) da conexão WAN. Instalar um controlador de domínio local pode realmente funcionar, mas esse sucesso será por design ou por acidente?
infelizmente, não há como especificar o controlador de domínio que validará um determinado cliente, se esse cliente está executando o Windows NT Server, Windows NT Workstation ou Windows 9x. as versões anteriores do Windows funcionarão da mesma maneira, desde que estejam usando a pilha TCP/IP de 32 bits ou uma pilha TCP/IP com reconhecimento de WINS de 16 bits.
neste detalhamento diário, forneceremos uma visão geral dos processos envolvidos. Também explicaremos por que um controlador de domínio localizado em outro país em um link de modem lento pode ser o escolhido por uma máquina cliente para atender sua solicitação de logon.
Background
para aqueles que não estão familiarizados com o conceito de domínios do Windows NT, aqui está uma atualização rápida: um domínio NT é uma coleção de servidores habilitados para rede e outros computadores que compartilham informações comuns de segurança e conta. O domínio fornece administração centralizada de usuário, computador e rede. As informações de segurança são mantidas em um banco de dados central em um servidor designado e configurado como o controlador de domínio primário (PDC) e são replicadas para outros servidores especiais, que são designados e configurados como controladores de domínio de backup (BDC). Apenas um servidor pode ser o PDC a qualquer momento, mas essa função especial pode ser transferida para qualquer BDC, conforme necessário. Quando um cliente que está executando TCP / IP tenta fazer logon neste domínio NT, a solicitação de logon é processada por qualquer um dos controladores de domínio da rede que pertencem ao mesmo domínio.Os servidores WINS mantêm uma lista de todos os clientes habilitados para WINS na rede. Os servidores WINS também mantêm uma lista de controladores de domínio identificados como type <1C>. Por razões conhecidas apenas por eles, os designers do WINS decidiram que deveria haver um limite de 25 entradas na lista <1C>, o que significa que os controladores de domínio subsequentes não aparecerão nesta lista. Os clientes recebem essa lista quando tentam encontrar um controlador de domínio para atender à solicitação de logon.

a ordem em que os controladores de domínio aparecem na lista segue esta lógica:

1. entradas de controlador de Domínio registrado com o servidor WINS, na ordem do mais atualizado recentemente para menos recentemente atualizada
2. entradas de controlador de Domínio obtido a partir de replicação com outros servidores WINS
3. A primeira entrada é sempre o PDC

Nós
Quando configurar o TCP/IP em um cliente, uma das opções que você pode ver (dependendo da instalação) é o tipo de nó. O tipo de nó refere-se a como o cliente encontra um controlador de domínio para atender suas solicitações de logon.
existem quatro tipos de nós no TCP / IP:

• B-node( broadcast node): quando um cliente precisa encontrar um controlador de domínio, ele executará uma transmissão. O primeiro controlador de domínio a responder receberá o trabalho de manutenção da solicitação de logon.
• P-node( nó ponto a ponto): neste ambiente, as consultas de nome vão diretamente para o servidor WINS.
• M-node( nó multi-homed): um ambiente m-node USA b-node primeiro e então—se necessário—p-node para resolver nomes.
• H-node( nó híbrido): um ambiente h-node usa p-node primeiro e depois b-node se o serviço name não estiver disponível.

vamos examinar cada tipo de nó mais completamente.
B-node
o modo B-node usa mensagens de transmissão para registro e resolução de nomes. Por exemplo, se um computador chamado NT_PC1 quer se comunicar com um computador chamado NT_PC2, NT_PC1 envia uma mensagem de difusão que está procurando NT_PC2. Em seguida, espera um tempo especificado para NT_PC2 responder.
B-node tem dois grandes problemas:

• em um ambiente grande, ele carrega a rede com mensagens de transmissão.
• Normalmente, os roteadores não encaminham mensagens de transmissão, portanto, os computadores em lados opostos de um roteador nunca ouvem as solicitações.

exemplos de computadores na rede que podem ser clientes de nó b incluem computadores executando MS-DOS, Windows 3.1 ou Windows para grupos de trabalho que não possuem software cliente WINS instalado. Os servidores possíveis incluem servidores de rede baseados em bloco de mensagens de servidor (SMB), como IBM LAN Server, DEC PATHWORKS, at&T StarLAN e LAN Manager para sistemas OS/2 ou UNIX.
P-node
o modo P-node resolve os problemas que o B-node não resolve. Em um ambiente p-node, os computadores não criam nem respondem a mensagens de transmissão. Todos os computadores se registram no servidor WINS, que é responsável por saber nomes e endereços de computadores e por garantir que não existam nomes duplicados na rede.

neste ambiente, quando NT_PC1 quer se comunicar com NT_PC2, ele consulta o servidor WINS para o endereço de NT_PC2. Após o recebimento do endereço, NT_PC1 vai diretamente para NT_PC2 sem transmissão. Como as consultas de nome vão diretamente para o servidor WINS, o p-node evita carregar a rede com mensagens de transmissão. Como as mensagens de transmissão não são usadas e o endereço é recebido diretamente, os computadores podem estar em lados opostos dos roteadores.
os problemas mais significativos com o nó p são:

• todos os computadores devem ser configurados para saber o endereço do servidor WINS.
• se o servidor WINS estiver inativo, os computadores que dependem dele para resolver endereços não poderão acessar nenhum outro sistema na rede.

M-node
o modo m-node foi criado principalmente para resolver os problemas associados ao B-node e ao p-node. Em um ambiente m-node, um computador tenta primeiro o registro e a resolução com o B-node. Se isso falhar, ele muda para P-node. Vantagens:

• M-nó pode atravessar roteadores
• Desde o nó b é sempre tentado em primeiro lugar, os computadores no mesmo lado de um roteador continuar a funcionar como de costume, se o servidor WINS é baixo
• Em teoria, usando o nó m, deve aumentar o desempenho da LAN

H-node
O nó h modo resolve os problemas mais significativos associados com mensagens de difusão e encaminhadas-ambiente de operações. Este modo é uma combinação de nó b e nó p que usa mensagens de transmissão como último recurso. O modo h-node faz mais do que alterar a ordem para usar b-node e p—node: se o servidor WINS estiver inativo—tornando as mensagens de transmissão uma necessidade-o computador continua a pesquisar o servidor WINS. Quando o servidor WINS pode ser alcançado novamente, o sistema retorna ao p-node. O h-node também pode ser configurado para usar o arquivo LMHOSTS após a falha na resolução do nome da transmissão.
como o p-node é usado primeiro, nenhuma mensagem de transmissão é gerada se o servidor WINS estiver em execução e os computadores podem estar em lados opostos dos roteadores. Se o servidor WINS estiver inativo, o nó b é usado, portanto, os computadores do mesmo lado de um roteador continuam a operar como de costume.
outras combinações
outra variação, conhecida como nó B modificado, também é usada nas redes da Microsoft para que as mensagens possam atravessar roteadores. O nó B modificado não usa o modo P-node ou um servidor WINS. Neste modo, o B-node usa uma lista de computadores e endereços armazenados em um arquivo LMHOSTS. Se uma tentativa de nó b falhar, o sistema procura em LMHOSTS para encontrar um nome e, em seguida, usa o endereço associado para cruzar o roteador. No entanto, cada computador deve ter essa lista, o que cria uma carga administrativa porque a lista deve ser mantida e distribuída. Windows para grupos de trabalho 3.11 e Lan Manager 2.x usou um sistema de nó B modificado. O Windows NT usa esse método se os servidores WINS não forem usados na rede. No Windows NT, algumas extensões foram adicionadas a este arquivo para facilitar o gerenciamento, mas o nó B modificado não é uma solução ideal.

alguns sites podem exigir os modos b-node e p-node. Embora essa configuração possa funcionar, os administradores devem ter extrema cautela e usá-la apenas para Situações de transição. Como os hosts p-node desconsideram as mensagens de transmissão e os hosts b-node dependem das mensagens de transmissão para resolução de nomes, os dois hosts podem ser configurados com o mesmo nome NetBIOS, levando a resultados imprevisíveis. Além disso, se um computador configurado para usar o nó b tiver um mapeamento estático no banco de dados WINS, um computador configurado para usar o nó p não poderá usar o mesmo nome de computador.Os computadores que executam o Windows NT podem ser configurados como agentes proxy WINS para ajudar na transição para o uso do WINS. Clientes de rede baseados no Windows (Windows NT, Windows 95 ou Windows para computadores Workgroups 3.11 habilitados para WINS) podem usar WINS diretamente. Computadores não-WINS compatíveis com B-node (conforme descrito em RFCs 1001 e 1002) podem acessar WINS por meio de proxies. Um proxy WINS é um computador habilitado para WINS que escuta mensagens de transmissão de consulta de nome e, em seguida, responde por Nomes que não estão na sub-rede local. Proxies são computadores p-node.
ao configurar o TCP, você não encontrará nenhuma maneira de definir o tipo de nó. O tipo de nó é definido como um padrão durante a configuração TCP. Os tipos de nó TCP/IP padrão do Windows 95 são:
Se o DHCP=False, e o WINS é desactivado e, em seguida, Tipo de Nó nó b (0x01)
Se o DHCP=False, e o WINS é definir manualmente e, em seguida, Tipo de Nó nó h (0x08)
Se o DHCP=True, define o WINS e DHCP e, em seguida, Tipo de Nó nó h (0x08)
Se o DHCP=True, e o WINS é definir manualmente e, em seguida, Tipo de Nó nó h (0x08)
Se o DHCP=True, e o WINS é desactivado e, em seguida, Tipo de Nó nó b (0x01)
Se opções de servidor WINS são fornecidas através de DHCP e, em seguida, Tipo de Nó deve ser definido usando a opção de DHCP 46; no entanto, definir localmente um servidor WINS no cliente substituirá essas duas opções porque os servidores WINS definidos localmente definirão automaticamente seu tipo de nó como H-node.
o tipo de nó pode ser alterado manualmente editando o registro do Windows 95. O local existe sob a subárvore HKEY_LOCAL_MACHINE sob a subchave
SYSTEM \ CURRENTCONTROLSET\SERVICES \ VXD \ MSTCP \ node Type
NodeType pode ser adicionado como um valor de String sob MSTCP se ainda não existir.
a solicitação de logon
agora, vamos ver o que ocorre depois que o cliente insere as informações de nome de usuário, senha e domínio e clica em OK na janela de prompt de logon (antes que a solicitação de logon seja atendida). O Windows 9x e o Windows NT se comportam de maneira um pouco diferente, então vou discuti-los separadamente.

Cliente Windows 9x
o cliente tenta encontrar um controlador de domínio de uma forma definida pelo tipo de nó com o qual foi configurado. Abaixo está uma sequência muito simplificada de eventos:

1. um cliente b-node transmitirá uma solicitação. Se um servidor não responder, o logon falhará.
2. um cliente p-node solicitará a lista< 1C > do servidor WINS. Em seguida, ele transmitirá uma solicitação para cada um dos servidores na lista <1C>, começando com o primeiro (o PDC).
3. os clientes m-node e H-node fazem ambas as coisas na ordem descrita acima, exceto que, se o nome do grupo de trabalho do cliente for o mesmo que o domínio da conta ao qual o logon está sendo tentado, a pesquisa WINS para controladores de domínio na sub-rede local é ignorada. Desde que o servidor WINS esteja ativo e acessível, isso significa que o primeiro controlador de domínio na lista <1C> a responder sempre lidará com a solicitação de logon.

conforme mencionado acima, para garantir que o cliente seja validado pelo controlador de domínio local, você deve tornar o nome do grupo de trabalho igual ao domínio representado por esse controlador de domínio. No entanto, se você quiser usar grupos de trabalho dentro do ambiente do office, esse método de garantir a validação local pode não ser aceitável. Nesse caso, o tipo de nó deve ser definido como m para garantir que o cliente transmita na sub-rede local inicialmente para que haja uma melhor chance de O controlador de domínio local responder primeiro. Observe que não é uma regra difícil e rápida. O controlador de domínio só precisa estar um pouco ocupado—quais servidores de sites remotos geralmente são porque é comum os administradores colocarem um único controlador de domínio em um site remoto-e um controlador de domínio mais responsivo e não local pode entrar em primeiro lugar.
Alternativamente, o WINS pode ser instalado no controlador de domínio local e os clientes podem usá-lo como o servidor principal do WINS. Esse método pode ser uma boa ideia se os usuários raramente acessam recursos fora da filial local, mas é um fardo extra para o servidor, que provavelmente está fornecendo serviços de arquivo e impressão, DHCP, SQL, Exchange e outras funções.
se o nome do grupo de trabalho for diferente do domínio da conta, o uso do M-node aumentará as chances de obter a solicitação de logon atendida localmente.
Windows NT client
o logon do Windows NT é um pouco diferente do logon do Windows 9x—a estação de trabalho NT tem um ID de máquina em um domínio. Portanto, o cliente passa por quatro etapas para validação de logon. Primeiro, o cliente NT Workstation valida seu ID de máquina com os controladores de domínio do domínio de recursos e, em seguida, envia informações de logon do Usuário para validação de passagem. O controlador de domínio do domínio de recurso passa as informações de logon para um controlador de domínio no domínio da conta. O controlador resource domain-domain devolve as informações de autenticação do Usuário (recebidas do controlador account domain-domain) ao usuário.

se os usuários estão conectados ou não a eles, os clientes da estação de trabalho NT passam pela validação de ID durante a inicialização e conforme necessário mais tarde (como se alguém fizer logon na máquina NT com o perfil em cache local porque o controlador de domínio de recursos está inativo).
primeiro vem a resolução de nome dos controladores de domínio. O cliente NT Workstation deve localizar um controlador de domínio de recurso. O processo de descoberta usado por um cliente de estação de trabalho NT para encontrar um controlador de domínio de recurso é o mesmo usado pelo controlador de domínio de recurso para estabelecer uma conexão confiável com um controlador de domínio de domínio de conta.
em seguida, o ID da máquina NT é validado. O cliente NT Workstation sempre envia uma transmissão de logon local para Resource-Domain <1C> antes de enviar solicitações de logon unicast para controladores resource domain-domain obtidos do WINS.
o cliente valida o ID da máquina de Estação de trabalho NT – com o primeiro controlador de domínio do domínio do recurso para responder de volta à solicitação de logon.
o cliente da estação de trabalho NT solicita que o controlador de domínio de recurso enumere a lista de domínio confiável. Os nomes de domínio obtidos são exibidos na caixa suspensa domínio na janela logon.
o cliente de estação de trabalho NT passa as credenciais de logon do Usuário para o controlador de domínio de recurso e solicita autenticação de passagem.
o controlador resource domain-domain passa as credenciais de logon do Usuário para o controlador account domain-domain com o qual estabeleceu uma conexão confiável e solicita que ele autentique o usuário. Em seguida, ele devolve as informações de validação ao cliente da estação de trabalho NT.
o cliente de estação de trabalho NT obtém o nome do controlador de domínio de conta do controlador de domínio de domínio de recurso para conectar e executar o script/perfil de logon, se ele tiver sido configurado.
o usuário NT agora está conectado ao Domínio da conta, executou um script de logon e fez conexões de rede apropriadas para diretórios domésticos.Obviamente, se o ID da máquina estiver registrado com um domínio fora da sub-rede local ou se o usuário estiver fazendo logon em um domínio que não tenha um controlador de domínio na sub-rede local, o processo de logon exigirá comunicação pela WAN. Se for um link lento, o processo de logon será estendido.
conclusão
com clientes do Windows 9x, a autenticação local é obtida fazendo com que o nome do grupo de trabalho seja o mesmo que o logon, ou conta, domínio ou usando o modo b ou M-node para garantir que a solicitação de logon seja transmitida localmente primeiro. Obviamente, o B-node não é muito versátil e causará um logon com falha se o controlador de domínio local não responder rapidamente.
com clientes Windows NT, deve haver um controlador de domínio de recursos e um controlador de domínio de conta no segmento local. (Pode ser um único servidor se os domínios de recursos e contas forem os mesmos.)
você pode aprimorar ainda mais o processo tendo vários servidores WINS e apontando os clientes para o servidor WINS que registrará o controlador de domínio local ou mais próximo na lista <1C>.A carreira de Richard Charrington começou quando ele começou a trabalhar com PCs—back quando eles eram conhecidos como microcomputadores. Começando como programador, ele trabalhou até as alturas elevadas de um administrador de sistemas Windows NT, e ele fez quase tudo no meio. Richard tem trabalhado com o Windows desde antes de ter uma GUI adequada e com o Windows NT desde que era LANManager. Agora um empreiteiro, ele entrou na escrita de script para o Windows NT e construiu alguns utilitários de auto-administração muito úteis.Os autores e editores cuidaram da preparação do conteúdo aqui contido, mas não fazem nenhuma garantia expressa ou implícita de qualquer tipo e não assumem nenhuma responsabilidade por erros ou omissões. Nenhuma responsabilidade é assumida por quaisquer danos. Sempre tenha um backup verificado antes de fazer qualquer alteração.