Exploration de domaine avec TCP/IP et les fichiers LMHOSTS

Dans les réseaux TCP/IP utilisant des routeurs et plusieurs segments, il est généralement recommandé d'implémenter WINS pour la résolution de nom et la prise en charge de l'exploration. À la place de WINS, il est cependant possible d'assurer la prise en charge intégrale de l'exploration de domaine en utilisant uniquement des fichiers LMHOSTS sur tous les ordinateurs, malgré quelques restrictions, traitées dans cet article.

Quel que soit le cas, il est important de noter qu'un client participe uniquement à l'exploration de domaine lorsqu'il utilise un nom de groupe de travail identique au nom de domaine (WorkgroupName = DomainName). Pour obtenir cette fonctionnalité sous Windows NT, un ordinateur peut également se joindre au domaine au lieu d'appartenir à un groupe de travail.

Microsoft n'a pas officiellement documenté ni testé la fonctionnalité d'exploration de domaine reposant sur LMHOSTS (par l'intermédiaire de routeurs). Elle ne sera peut-être pas disponible dans les prochaines versions des systèmes d'exploitation client et serveur. Utilisez ces informations avec parcimonie.

L'exploration dans un réseau Microsoft doit être considérée comme un service distribué fourni par un ou plusieurs ordinateurs. Chaque ordinateur peut jouer plusieurs rôles de navigation ; cet article traite toutefois uniquement des deux plus importants :

• Explorateur maître de segments (SegMB) : il peut s'agir de n'importe quel poste Windows NT Server, Workstation ou contrôleur de domaine. Il peut également s'agir d'un ordinateur Windows 95 ou Windows pour Workgroups 3.11. Le poste est chargé de maintenir la liste d'exploration des ordinateurs se trouvant sur son segment local, de transférer cette liste à l'explorateur maître de domaine et de demander la liste d'exploration de domaine à l'explorateur maître de domaine. L'explorateur SegMB fusionne la liste de domaine avec sa liste locale et met la liste résultante à disposition de tout client local qui la demande.
• Explorateur maître de domaine (DomMB) : il s'agit du contrôleur de domaine principal Windows NT. Il est chargé de maintenir la liste d'exploration sur son segment local (de même que l'explorateur SegMB) et de recueillir les listes d'exploration auprès d'autres explorateurs maîtres de segment (distants) portant le même nom de domaine (ou WorkgroupName = DomainName). L'explorateur DomMB fusionne les listes qu'il recueille, ainsi que sa liste locale, puis redistribue la liste résultante à l'ensemble des explorateurs SegMB distants. Il joue donc le rôle de concentrateur central pour la maintenance de la liste d'exploration de l'ensemble des domaines.

REMARQUE : Les fichiers de l'explorateur Windows pour Workgroups doivent être mis à jour.

Pour plus d'informations, consultez l'article suivant de la Base de connaissances Microsoft : Pour que ce service d'exploration distribué fonctionne, les explorateurs SegMB doivent être capables d'identifier précisément l'explorateur DomMB. Pour ce faire, ils doivent rechercher l'ordinateur ayant enregistré le nom NetBIOS " Domain<1b> ", car il s'agit du nom enregistré par le contrôleur de domaine principal (qui est également l'explorateur DomMB, comme indiqué ci-dessus).

Pour plus d'informations, consultez l'article suivant de la Base de connaissances Microsoft :

Exploration de domaine avec WINS

Dans un environnement WINS, un explorateur SegMB interroge le service WINS pour identifier le poste ayant enregistré le nom Domain<1b>. Dans ce cas, WINS joue le rôle de ressource centrale pour cette information. WINS présente un avantage supplémentaire pour l'exploration : il permet l'exploration de plusieurs domaines.

Exploration de plusieurs domaines avec WINS

Un contrôleur de domaine principal configuré pour interroger le service WINS à intervalle régulier demande la liste de tous les domaines enregistrés dans la base de données (un domaine s'identifie au nom " Domain<1b> " enregistré dans la base de données et à l'adresse IP associée du contrôleur de domaine principal qui l'a enregistré). Le contrôleur de domaine principal combine ces informations à sa propre liste d'exploration de domaine pour avoir la liste de tous les ordinateurs de son domaine, ainsi qu'à la liste de tous les autres domaines sur le réseau local. Lorsque le contrôleur de domaine principal interagit par la suite avec ses explorateurs SegMB, il leur communique la liste complète. Vous pouvez en constater l'impact lorsque vous naviguez sur le réseau à l'aide du Gestionnaire de fichiers ou du Voisinage réseau.

REMARQUE : Il s'agit là du rôle que le service WINS tient lors de l'exploration. Le service n'intervient pas dans le processus de sélection de l'explorateur. Il n'assiste pas non plus un client à identifier l'explorateur maître de son segment local, ni l'explorateur DomMB à identifier les explorateurs SegMB ; ces opérations s'effectuent lorsque l'explorateur SegMB contacte initialement l'explorateur DomMB.

Sur certains réseaux, il est préférable de ne pas utiliser le service WINS ; ceci se détermine uniquement au cas par cas. Vous pouvez alors utiliser les fichiers LMHOSTS ou DNS pour la résolution de nom des ordinateurs ; les fichiers LMHOSTS sont cependant obligatoires pour l'exploration de domaine, ainsi que pour toute autre tâche de gestion de domaine, telle que la réplication de la base de données et les canaux sécurisés de domaine.

Exploration de domaine avec les fichiers LMHOSTS

Sans le service WINS, des entrées LMHOSTS spéciales doivent servir à identifier les contrôleurs de domaine. Cette opération s'effectue de la manière suivante : Au démarrage, un ordinateur lit les entrées et les stocke de façon permanente dans la mémoire cache de nom NetBIOS jusqu'à ce qu'il soit éteint. Pour des raisons d'efficacité des analyses LMHOSTS ultérieures, il est préférable que ces entrées figurent à la fin du fichier LMHOSTS. Tous les ordinateurs du domaine requièrent une entrée par contrôleur de domaine (dans le domaine local), ainsi qu'une entrée pour le contrôleur de domaine principal. Remarquez en outre l'ordre exact de #PRE #DOM et leur casse (majuscules). Il n'est pas important de respecter la casse pour les autres noms.

Explorateurs maîtres de segment Windows NT

Les entrées ci-dessus sont suffisantes pour un ordinateur Windows NT. Lorsqu'il devient explorateur maître de segment, un ordinateur Windows NT identifie le contrôleur de domaine principal en envoyant une requête (à l'aide de l'API NetGetDcName) à toutes les entrées LMHOSTS portant la désignation #DOM:<domainelocal>. Seul le contrôleur de domaine principal répond. L'ordinateur Windows NT contacte ensuite le contrôleur de domaine principal, informe le contrôleur de domaine principal qu'il est explorateur maître, puis continue le processus d'obtention de la liste d'exploration de domaine. Le contrôleur de domaine principal contacte ensuite l'ordinateur Windows NT pour obtenir la liste d'exploration de son segment local. Ce processus se répète à intervalle régulier de 12 à 15 minutes.

Explorateurs maîtres de segment Windows 95 et Windows pour Workgroups

Ils n'exécutent pas l'API NetGetDcName. Ils ont donc besoin des entrées du fichier LMHOSTS identifiant le contrôleur de domaine principal. Dans l'exemple ci-dessus, supposons que l'ordinateur soit le contrôleur de domaine principal du domaine ; vous auriez donc deux entrées pour le client Windows 95 ou Windows pour Workgroups : La première entrée permet au contrôleur de domaine principal de jouer le rôle de contrôleur de domaine de connexion pour le client tandis que la deuxième permet au service d'exploration client d'identifier précisément le contrôleur de domaine principal. N'oubliez pas que vous aurez probablement plusieurs lignes ressemblant à la première (pour plusieurs contrôleurs de domaine), mais une seule ligne comportant la notation \0x1b (pour désigner le contrôleur de domaine principal). Notez que le nom du domaine doit se trouver entre guillemets et comporter autant d'espaces que nécessaires pour parvenir à 15 caractères avant la partie \0x1b. Dans l'exemple ci-dessus, les virgules servent d'espaces réservés visuels ; dans un fichier LMHOSTS réel, ces virgules sont remplacées par des espaces. Notez également que le transfert du rôle PDC (contrôleur de domaine principal) sur un autre poste Windows NT Server (via la promotion) invalide l'entrée \0x1b. Suivez l'une des procédures ci-dessous pour résoudre ce problème :

• Modifiez les adresses IP sur les contrôleurs de façon à ce que le contrôleur de domaine principal ait toujours la même adresse. Vous n'avez pas besoin de modifier quoi que ce soit dans le fichier LMHOSTS.
• Modifiez l'adresse IP \0x1b dans tous les fichiers LMHOSTS des clients ou dans le fichier LMHOSTS central distribué (le cas échéant).

Remarque sur les noms NetBIOS

Chaque nom NetBIOS se compose de 16 caractères ; les 15 premiers sont des caractères définis par les utilisateurs (ou à remplir d'espaces) tandis que le 16ème caractère est réservé à l'identification du service de réseau ayant enregistré le nom. L'exemple de nom NetBIOS le plus courant est le nom NomOrdinateur sur tout client de réseau Microsoft. Lors de l'amorçage d'un client, différents services de réseau client enregistre le NomOrdinateur ainsi que son extension unique, NomOrdinateur<00> par exemple (service de station de travail) et NomOrdinateur<20> (service de serveur). Dans ce cas, la seule différence entre ces deux noms est le 16ème caractère, ce qui suffit à les identifier de façon unique. Un client peut enregistrer tous ses noms par diffusion et par datagramme direct auprès de WINS, selon le type de n?ud du client. D'autres sociétés peuvent également enregistrer les extensions NetBIOS non réservées par Microsoft.

Pour plus d'informations, consultez les articles suivants de la Base de connaissances Microsoft :

Exemple LMHOSTS

Supposons que le nom de votre domaine est " Globe ", le nom NetBIOS de votre contrôleur de domaine principal est " Mongo " et que vous disposez de divers autres contrôleurs de domaine de sauvegarde. Votre fichier LMHOSTS ressemble alors à ceci : Pour vérifier que vous avez correctement entré ces informations, ouvrez une fenêtre de commande (invite DOS) et étudiez le cache NetBIOS : CONSEIL : l'entrée <1B> n'apparaît pas si le nom ne comporte pas exactement 15 caractères, si vous n'utilisez pas de guillemets ou si vous entrez une barre oblique "/0x1b" (par opposition à une barre oblique inverse "\0x1b").

Exploration de plusieurs domaines avec LMHOSTS

Il est important de noter l'inconvénient majeur de l'exploration à l'aide des fichiers LMHOSTS : il n'est pas possible d'effectuer l'exploration de plusieurs domaines. Comme précédemment indiqué, le contrôleur de domaine principal demande au service WINS la liste des domaines distants et inclut ces informations dans sa liste d'exploration. Le contrôleur de domaine principal n'analyse cependant pas le fichier LMHOSTS pour obtenir ces informations ni n'inclut d'autres entrées \0x1b portant la mention #PRE (cache). Si votre contrôleur de domaine principal n'interroge pas le service WINS, les autres domaines n'apparaîtront pas dans le Gestionnaire de fichiers ou le Voisinage réseau. Vous pouvez cependant toujours explorer les autres domaines manuellement (si vous connaissez leur nom et que votre fichier LMHOSTS comporte des entrées spéciales). Il se pourrait également que vous puissiez explorer les domaines distants grâce aux diffusions.

Méthode manuelle : vous devez inclure une entrée \0x1b pour le contrôleur de domaine principal de tout domaine distant à explorer. Cette technique peut être utilisée sous Windows NT, Windows 95 et Windows pour Workgroups. Son fonctionnement repose sur la séquence d'événements suivante, nécessaire pour l'exploration de domaine distant :

1. Le client identifie le contrôleur de domaine principal du domaine distant domaine grâce au nom domain<1b> (avec le fichier LMHOSTS, l'identification se fait par l'intermédiaire de l'entrée \0x1b ; avec le service WINS, elle s'effectue par l'intermédiaire d'une requête).
2. Le client envoie une demande d'API GetBackupList au contrôleur de domaine principal distant.
3. Le contrôleur de domaine principal distant répond en envoyant la liste de trois explorateurs maîtres maximum, s'incluant éventuellement dedans.
4. Le client envoie une demande d'API NetServerEnum à l'un des explorateurs maîtres.
5. L'explorateur maître répond en communiquant sa liste d'exploration globale.

Pour obtenir cette liste d'exploration manuelle, utilisez une invite de commandes : Méthode de diffusion : Cette méthode fonctionne en présence de tout segment de réseau comportant des membres de plusieurs domaines. Il existe un explorateur SegMB pour chaque domaine sur le segment " mutuel "et chaque explorateur SegMB annonce son domaine par diffusion vers un nom NetBIOS spécial <01><02>_MSBROWSE_<02><01>. Ce paquet de diffusion inclut le nom de domaine et le nom d'ordinateur de l'explorateur SegMB l'ayant annoncé.

Les explorateurs SegMB d'autres domaines (sur ce segment mutuel) détectent ces informations et les ajoutent à leur liste d'exploration locale. Un explorateur SegMB sur ce segment connaît maintenant les autres domaines et envoie les informations découvertes à l'explorateur DomMB de son domaine et aux clients locaux (de son domaine) demandant une liste d'exploration.

Un client demande la liste d'exploration locale de domaine (en interrogeant un explorateur SegMB local) et peut voir les domaines découverts dans le Gestionnaire de fichiers et le Voisinage réseau. Lorsque le client sélectionne le domaine découvert, il demande en fait directement une liste d'exploration à l'explorateur SegMB responsable de l'annonce dans le paquet <01><02>_MSBROWSE_<02><01>. De plus, ces informations ayant été envoyées à l'explorateur DomMB du client, elles sont également transmises aux explorateurs SegMB d'autres segments faisant partie de ce domaine.

Les clients sur un segment distant peuvent maintenant exploiter ces informations et explorer le domaine distant, même s'il n'existe aucun membre de domaine distant sur leur segment. Ce processus est toutefois instable avec les fichiers LMHOSTS, car vous dépendez des " explorateurs SegMB distants découverts " encore actifs. Dans un environnement WINS, cette fonction d'exploration à distance est beaucoup plus stable, car le service WINS fournit des informations sur les domaines distants à votre contrôleur de domaine principal.

Points importants :

1. Pour que la connexion et l'exploration de domaine fonctionnent par l'intermédiaire des fichiers LMHOSTS, tous les ordinateurs requièrent un fichier LMHOSTS incluant les entrées de tous les contrôleurs de domaine et des entrées \0x1b correctes. Le contrôleur de domaine principal requiert une entrée pour chaque explorateur maître de segment distant (s'ils ne figurent pas déjà dans la liste).
2. Il est très probable que tous les ordinateurs du réseau local figurent déjà dans la liste. La méthode la plus efficace pour y parvenir consiste à disposer d'un fichier LMHOSTS commun distribué à l'ensemble des clients et serveurs ; vous devez cependant l'actualiser pour qu'il tienne compte des modifications d'adresse IP, ce qui peut représenter une lourde tâche administrative.
3. Vous ne pouvez pas nécessairement vous connecter à un ordinateur figurant dans la liste d'exploration. S'il appartient à votre segment local, vous pouvez vous y connecter par diffusion ; s'il se trouve sur un segment distant, vous avez besoin d'une entrée LMHOSTS.