Procura de domínios através de ficheiros TCP/IP e LMHOSTS

Em redes baseadas em TCP/IP que envolvam routers e vários segmentos, é genericamente recomendável que implemente o serviço de atribuição de nomes para a Internet do Windows (WINS, Windows Internet Naming Service) para a resolução de nomes e como suporte à procura. No entanto, e em alternativa ao WINS, é possível ter uma procura de domínios completa em todos os computadores usando apenas os ficheiros LMHOSTS, apesar de se registarem algumas limitações que serão tratadas neste artigo.

Em qualquer dos casos, é importante salientar que um cliente só participa na procura de domínios quando usar um nome do grupo de trabalho que seja equivalente ao nome do domínio (Nome_Grupo_Trabalho = Nome_Domínio). Os computadores com Windows NT também podem "juntar-se" a um domínio para ganhar esta funcionalidade, em vez de estarem num grupo de trabalho.

Esta funcionalidade de procura de domínios baseada em LMHOSTS (através de routers) não está formalmente documentada nem foi testada pela Microsoft e poderá não se encontrar disponível em futuras versões dos sistemas operadores do cliente e do servidor. Utilize esta informação discretamente.

A "Procura", numa rede Microsoft, deve ser considerada um serviço distribuído por um ou mais computadores. Cada computador pode desempenhar diversos papéis de procura; no entanto, este artigo ocupa-se dos dois papéis mais importantes:

• O browser principal do segmento (SegMB, Segment Master Browser) poderá ser qualquer Windows NT Server, qualquer estação de trabalho ou qualquer controlador de domínio. Também poderá ser um computador com Windows 95 ou Windows for Workgroups 3.11. O browser é responsável pela manutenção de uma lista de procuras dos computadores que façam parte do seu segmento local, reencaminhando essa lista para o browser principal do domínio e pedindo a lista de procuras de domínios ao browser principal do domínio. O SegMB une a lista do domínio com a sua lista local e disponibiliza essa lista a qualquer cliente local que a peça.
• O browser principal do domínio é o controlador de domínio principal (PDC, Primary Domain Controller) do Windows NT. É responsável pela manutenção da lista de procuras do seu segmento local (tal como um SegMB), assim como pela recolha de listas de procuras de outros browsers principais (remotos) do segmento que tenham o mesmo nome de domínio (ou Nome_Grupo_Trabalho = Nome_Domínio). O DomMB une as listas que recolhe, assim como a sua lista local e, em seguida, redistribui a lista combinada de volta a todos os SegMB remotos. Assim, O DomMB é o concentrador central da manutenção da lista de procuras de todo o domínio.

NOTA: O browser do Windows for Workgroups requer ficheiros actualizados.

Para mais informações, consulte o seguinte artigo na Microsoft Knowledge Base: Para que este serviço de procura distribuída resulte, os SegMB deverão ter uma forma de determinar com exactidão quem é o DomMB. Poderão fazê-lo localizando o computador que tenha registado o nome NetBIOS "Domain<1b>", pois este só é registado pelo PDC (que também é o DomMB, tal como foi dito acima).

Para mais informações, consulte o seguinte artigo na Microsoft Knowledge Base:

Procura de domínios com o WINS

Num ambiente WINS, um SegMB faria uma consulta ao WINS para determinar quem teria registado Domínio<1b>. Neste caso, o WINS funciona como um conveniente recurso central para estas informações. Existe ainda mais uma vantagem em ter o WINS para ajudar à procura: a procura de multi-domínios.

Procura de multi-domínios com o WINS

Um PDC que esteja configurado para fazer uma consulta ao WINS, pede periodicamente a lista de todos os domínios que estejam registados na base de dados. (Um domínio é identificado por um registo "Domínio<1b>" na base de dados e pelo endereço IP do PDC que o registou que se lhe encontra associado.) O PDC combina essa lista com a sua própria lista de procuras de domínios e passa, assim, a ter uma lista completa dos computadores do seu domínio, assim como uma lista de outros domínios em toda a rede alargada (WAN, Wide Area Network). Então, quando o PDC interage com os seus SegMB, dá-lhes esta lista completa. O utilizador vê o efeito deste procedimento quando efectua uma procura na rede utilizando o Gestor de ficheiros ou a Vizinhança na rede.

NOTA: É este o nível de ligação do WINS com a procura. O WINS não está ligado ao processo de eleição do browser, nem ajuda um cliente a determinar quem é o seu browser principal do segmento local ou o DomMB a determinar quem são os SegMB; tudo isso é feito no processo em que o SegMB contacta o DomMB pela primeira vez.

Em determinadas redes, poderá não ser vantajoso usar o WINS; isto só poderá ser determinado caso a caso. Poderá, então, usar quer LMHOSTS, quer DNS para resolver nomes de computador. No entanto, são necessários os LMHOSTS para a procura de domínios, assim como para outras questões de gestão do domínio, tais como a replicação de bases de dados e canais de domínio seguros.

Procura de domínios através de LMHOSTS

Sem o WINS, precisará de entradas LMHOSTS especiais para designar quem são todos os controladores do domínio. Isto é feito na seguinte convenção: Quando um computador é iniciado, lê estas entradas e arquiva-as permanentemente na cache do nome de NetBIOS até que o computador seja desligado. (Por este motivo, é melhor que estas entradas sejam as últimas do ficheiro LMHOSTS, para que haja uma subsequente eficácia de interpretação do LMHOSTS.) Todos os computadores de um domínio necessitam de uma destas entradas para cada controlador de domínio (no domínio local), assim como de uma outra para o PDC. Tenha também em atenção a ordem exacta de #PRE #DOM e o facto de ambos estarem em maiúsculas. Os outros nomes não são sensíveis a maiúsculas e minúsculas.

Browsers principais de segmento do Windows NT

Ter as entradas acima enunciadas é o suficiente para um computador com o Windows NT: ao transformar-se em Browser Principal do Domínio, um computador com o Windows NT determina quem é o PDC fazendo uma consulta (usando a API NetGetDcName) a todas as entradas LMHOSTS com a designação #DOM:<domínio_local> Só o PDC responde. O computador com o Windows NT contacta, então, o PDC, informa o PDC de que é um browser principal e, em seguida, dá continuidade ao processo de obtenção da lista de procuras de domínios. O PDC contacta, em seguida, o computador com Windows NT para obter a lista de procuras do segmento local deste computador. Este processo repete-se a cada 12 - 15 minutos.

Browsers principais de segmento do Windows 95 e do Windows for Workgroups

O Windows 95 e o Windows for Workgroups não executam a API NetGetDcName, pelo que precisam de entradas no ficheiro LMHOSTS que indiquem quem é o PDC. Assumindo o exemplo acima como PDC do domínio, o utilizador teria duas entradas para o cliente com Windows 95 ou Windows for Workgroups: A primeira entrada permite ao PDC funcionar como um controlador de domínio de início de sessão para o cliente, enquanto que a segunda entrada permite ao serviço do browser do cliente encontrar explicitamente o PDC. Não esqueça que provavelmente terá várias linhas semelhantes à primeira linha (para vários controladores de domínio), mas só terá uma linha com a directiva \0x1b (para designar o PDC). Repare que o nome do domínio tem que estar entre aspas, a que terá de acrescentar espaços para um total de 15 caracteres antes da parte \0x1b (O exemplo oferecido acima contém vírgulas como marcadores de posição visuais, mas num ficheiro LMHOSTS verdadeiro essas vírgulas seriam substituídas por espaços.) Lembre-se também que a alteração do papel de PDC e a sua atribuição a outro Windows NT Server (via promoção) fará com que a sua entrada \0x1b seja inválida. Opções para corrigir esta situação:

• Troque os endereços IP nos controladores, para que, na realidade, o PDC tenha sempre o mesmo endereço. Não necessitaria de alterar nada no ficheiro LMHOSTS.
• Altere todos os endereços IP \0x1b em todos os ficheiros LMHOSTS dos clientes, ou no ficheiro LMHOSTS que é distribuído a partir de um ponto central (se implementar este dispositivo).

Nota acerca de nomes de NetBIOS

Cada nome de NetBIOS tem uma totalidade de 16 caracteres de comprimento, sendo que os 15 primeiros são definíveis pelo utilizador (ou são-lhes acrescentados espaços) e o 16º carácter é reservado para a identificação do serviço de rede que registou o nome. O mais familiar dos exemplos de um nome de NetBIOS é o Nome_de_Computador em qualquer cliente de uma rede Microsoft. Quando o cliente é iniciado, vários serviços de rede clientes irão registar o Nome_Computador em conjunto com a sua extensão exclusiva, tal como, por exemplo, Nome_Computador<00> (serviço de estação de trabalho) e Nome_Computador<20> (serviço de servidor). Neste caso, a única diferença entre estes dois nomes é o 16º carácter, o que faz com que sejam individualmente identificáveis. Um cliente pode registar todos os seus nomes através de difusão e através de datagramas enviados directamente ao WINS, dependendo do tipo de nó do cliente. Outras companhias poderão registar extensões de NetBIOS que não estejam reservadas pela Microsoft.

Para mais informações, consulte os seguintes artigos na Microsoft Knowledge Base:

Exemplo de LMHOSTS

O nome do seu domínio é "Globo", o nome de NetBIOS do seu PDC é "Mongo" e você tem vários outros controladores de domínio secundários. O seu ficheiro LMHOSTS teria o seguinte aspecto: Para se certificar de que introduziu correctamente os nomes, abra uma janela de comandos (linha de comandos do DOS) e veja a sua cache de NetBIOS: SUGESTÃO: A entrada <1B> não aparecerá se não tiver exactamente 15 caracteres no nome ou se não usar aspas, ou se introduzir a barra "/0x1b" (em vez de "\0x1b").

Procura de multi-domínios através de LMHOSTS

É importante ter em conta que a principal desvantagem da procura através de LMHOSTS é que não fornece automaticamente a capacidade de procura multi-domínios. Tal como foi mencionado acima, o PDC fará uma consulta ao WINS à procura de uma lista de domínios remotos e irá incluir essas informações na sua lista de procuras. No entanto, o PDC não irá analisar o ficheiro LMHOSTS para obter as mesmas informações, nem irá incluir outras entradas \0x1b com a directiva #PRE (cache). Na realidade, se o seu PDC não fizer uma consulta ao WINS, não será possível ver outros domínios através do Gestor de ficheiros ou da Vizinhança de rede. No entanto, ainda poderá fazer a procura de outros domínios de modo manual (desde que saiba o nome do domínio e que tenha entradas especiais no seu ficheiro LMHOSTS) e ainda existe a hipótese de poder procurar domínios remotos a partir de difusões.

Método manual: isto é levado a cabo incluindo uma entrada \0x1b para o PDC de qualquer domínio remoto que queira procurar. Esta técnica é aplicável ao Windows NT, ao Windows 95 e ao Windows for Workgroups. É eficaz devido à seguinte sequência de eventos, que é necessária para que se possa efectuar a procura de domínios remotos:

1. O cliente determina quem é o PDC do domínio remoto através do nome domínio_<1b> (para os LMHOSTS isto faz-se com a entrada \0x1b; no caso do WINS, seria via consulta).
2. O cliente envia um pedido de API GetBackupList ao PDC remoto
3. O PDC remoto responde com uma lista de até três browsers principais, incluindo-se potencialmente a si próprio.
4. O cliente envia um pedido API NetServerEnum a um dos browsers principais
5. O browser principal responde com a sua lista de procuras de todo o domínio.

O "modo manual" de obter esta lista de procuras é levado a cabo através de uma janela de comandos: Método de difusão: Este método aplica-se caso exista um segmento de rede que tenha membros provenientes de múltiplos domínios. Existe um SegMB de cada domínio no segmento "mútuo" e cada SegMB anuncia o seu domínio via difusão a um nome de NetBIOS especial <01><02>_MSBROWSE_<02><01>. Este pacote de difusão inclui o nome do domínio e o nome do computador do SegMB que o anunciou.

Os SegMB de outros domínios (neste segmento mútuo) recebem estas informações e acrescentam-nas à respectiva lista de procuras local. Um SegMB neste segmento acabou de "descobrir" outros domínios e envia as informações descobertas ao DomMB do seu domínio e aos clientes locais (no seu domínio) que peçam uma lista de procuras.

Um cliente pede a lista de procuras do domínio local (a um SegMB local) e visualiza os domínios descobertos no Gestor de ficheiros e na Vizinhança de rede. Quando o cliente selecciona o domínio descoberto, na realidade pede uma lista de procuras directamente ao SegMB que fez o anúncio no pacote <01><02>_MSBROWSE_<02><01> Para além disso, e uma vez que estas informações também foram enviadas ao DomMB do cliente, é propagada aos SegMB noutros segmentos que façam parte deste domínio.

Os clientes que estejam num segmento remoto poderão, então, tirar partido destas informações e fazer a procura no domínio remoto embora não exista nenhum membro do domínio remoto no respectivo segmento. No entanto, este processo é muito volátil quando forem utilizados ficheiros LMHOSTS, porque se está dependente do facto de os "SegMB remotos descobertos" ainda estarem activos. Num ambiente WINS, esta funcionalidade de procura remota é muito mais estável, porque o WINS fornece informações acerca dos domínios remotos ao PDC do utilizador.

Questões a tomar em consideração:

1. Para que o início de sessão do domínio e a procura de domínios via LMHOSTS resulte, todos os computadores necessitam de um ficheiro LMHOSTS que inclua entradas para todos os controladores de domínio e entradas \0x1b apropriadas, e o PDC necessita de uma entrada para cada localizador principal de segmento remoto (caso não esteja ainda listado).-{}-
2. É muito provável que cada computador WAN esteja listado. Isto poderá ser feito de forma mais eficaz tendo um ficheiro LMHOSTS comum que é distribuído a todos os clientes e servidores, sendo que, no entanto, este ficheiro terá que ser mantido actualizado com todas as alterações de endereços IP apropriadas e que isso se poderá tornar um fardo administrativo excessivo.
3. Visualizar um computador na lista de procuras não significa que se possa ligar a ele. Se esse computador se encontrar no seu segmento local, poderá ligar-se a ele através de difusão; caso esteja num segmento remoto, necessitará de uma entrada LMHOSTS para o fazer.