par Mark Minasi - Mis en ligne le 09/10/2002
Dans « Résoudre les problèmes de
Logon AD liés à DNS, 1e partie », je
commençais à expliquer comment les
erreurs faciles à commettre dans DNS
pouvaient entraîner l'échec des logons
au domaine AD (Active Directory).
Comme je l'ai expliqué, pour de nombreux
nouveaux domaines AD, les ennuis
commencent quand on exécute
Dcpromo, qui doit trouver le serveur
DNS primaire pour le domaine DNS
dont le nom correspond au nom de
votre domaine AD.
Pour récapituler, j'ai constaté que
dans les vastes domaines et les petits
domaines de test, vous essayez souvent
de tromper DNS afin de pouvoir
créer un domaine AD avec un nom correspondant
à un autre domaine sur
Internet - peut-être même votre
propre domaine Internet public, si
vous mettez en oeuvre DNS split-brain.
Supposons, par exemple, que vous
créiez un petit domaine de test
AD nommé acme.com. Comme quelqu'un
d'autre possède le domaine
acme.com, une recherche DNS sur Internet aboutit à un serveur DNS de
type UNIX. Quand Dcpromo demande
à ce serveur s'il accepte des mises à
jour dynamiques - comme doit le faire
tout serveur DNS qui sert un domaine
AD - le serveur DNS du vrai acme.com
répond, sans surprise, « Bien sûr que
non ! »
Après cette rebuffade, Dcpromo
vous demande quoi faire. Plutôt que de
vous dire qu'il a trouvé un serveur DNS
mais que celui-ci n'acceptera pas de
mises à jour dynamiques, Dcpromo
prétend qu'il n'a pas pu trouver le serveur
DNS d'acme.com. (Si quelqu'un
de chez Microsoft lit cet article, je
suggère de corriger ce comportement
de Dcpromo dans Microsoft .NET
Server.) Dcpromo propose ensuite
d'installer votre service serveur
DNS sur ce serveur UNIX et de le
configurer comme le serveur DNS
pour votre domaine acme.com local.
La plupart des gens acceptent l'offre, et
comme je l'ai dit dans mon article
précédent, c'est là que les ennuis
commencent.
Quand il établit un serveur DNS local,
Dcpromo crée une zone de même
nom que le domaine acme.com, dans
mon exemple. Donc, quand vous créez
un nouveau domaine AD, l’ordinateur
a une double casquette : il est à la fois
le premier DC (domain controller) et
le serveur DNS pour le domaine. Mais
comme Dcpromo ne dit jamais au logiciel
DC que le logiciel DNS existe sur le
même ordinateur, le DC ne peut toujours
pas trouver un serveur DNS qui
acceptera des mises à jour dynamiques
pour acme.com.
Autrement dit, Dcpromo met en
place le service serveur DNS et la zone
acme.com mais ne dit pas à la pile
TCP/IP de l’ordinateur de se référer à
elle-même quand elle recherche un
serveur DNS. Le serveur DNS est en
fonctionnement, mais aucun ordinateur
– pas même celui sur lequel
tourne le serveur DNS – ne sait qu’il
doit d’abord se référer à ce serveur
DNS quand il recherche un domaine. Par conséquent, Dcpromo termine la
préparation basique du domaine, puis
demande et obtient l’autorisation de
réinitialiser l’ordinateur.
Au cours de cette réinitialisation,
l’ordinateur établit une pile TCP/IP
exactement comme vous aviez établi la
pile avant de faire de l’ordinateur un
DC. A ce moment-là , vous avez utilisé
DHCP soit pour configurer la pile, soit
pour l’établir statiquement. Si vous
avez utilisé DHCP, le serveur DHCP est
soit le serveur DHCP de votre ISP, soit
votre serveur DHCP d’entreprise. Quoi
qu’il en soit, il est peu probable que le
serveur DHCP dira à votre ordinateur
de s’utiliser lui-même comme serveur
DNS favori. Si vous avez initialement
configuré votre pile TCP/IP statiquement,
avez-vous dit à l’ordinateur de
s’utiliser lui-même comme serveur
DNS préféré ? Probablement pas.
(Mais, si vous l’avez fait, bien joué !)
De ce fait, quand l’ordinateur s’initialise,
sa configuration DHCP ou statique
dit à l’ordinateur d’utiliser un serveur
DNS autre que lui-même –
probablement un serveur sur Internet.
Ensuite, le service Netlogon se met en
action.
Comme sur Windows NT 4.0,
Netlogon sur Windows 2000 est un service
important qui ne fonctionne que
sur des DC. Les principales missions de
Netlogon consistent à trouver le serveur
DNS primaire pour son domaine
(acme.com, par exemple), puis à utiliser
DDNS (Dynamic DNS) pour écrire
les enregistrements d’identification de
serveur (SRV) et de nom d’hôte (A)
pour Netlogon dans la zone du domaine.
Le service Netlogon sur chaque
DC se réintroduit périodiquement
dans la zone DNS du domaine afin que
DNS connaisse l’existence de ce DC.
Une fois que la zone acme.com connaît
l’existence d’un DC, les stations de travail
et autres DC dans acme.com peuvent
trouver ce DC.
Mais quand la pile TCP/IP du DC
acme.com pointe sur un serveur DNS
autre qu’elle-même, une requête
concernant le serveur DNS primaire aboutit aux serveurs DNS d’Internet
publics et renvoie l’adresse du serveur
DNS pour le domaine acme.com enregistré.
Quand Netlogon essaie d’écrire
des enregistrements sur ce serveur
DNS UNIX, le serveur refuse les mises
à jour et Netlogon signale le problème
dans le System log comme événement
ID 5773 : The DNS server for this DC
does not support dynamic DNS. Add
the DNS records from the file
‘%SystemRoot%\System32\Config\netlogon.
dns’ to the DNS server serving
the domain referenced in that file.
Si vous ne pouvez pas convaincre
une station de travail de se connecter à
un nouveau domaine AD ou si
Dcpromo refuse de fonctionner sur
une seconde machine dont vous avez
l’intention de faire un autre DC dans
votre domaine, recherchez l’événement
ID 5773 dans le System log. Si
Dcpromo vous a dit qu’il configurerait
DNS, l’événement ID 5773 est la
preuve que vous devez pointer la pile
TCP/IP de votre DC sur elle-même.
Pour avoir une preuve supplémentaire,
démarrez le snap-in MMC
(Microsoft Management Console)
DNS, double-cliquez sur l’icône de
votre serveur, ouvrez le dossier
Forward Lookup Zones, puis doublecliquez
sur le dossier de votre domaine.
Un dossier ne contenant que
deux ou trois enregistrements et pas
d’autres dossiers indique que
Netlogon n’a pas pu trouver le serveur
DNS qui fonctionne sur le même ordinateur
que Netlogon. Configurez les
paramètres TCP/IP de votre ordinateur
pour qu’ils pointent sur votre ordinateur
comme serveur DNS préféré, redémarrez
Netlogon, puis vérifiez à
nouveau le dossier de votre domaine ;
il contiendra quatre dossiers plein d’informations
sur la recherche d’un DC.
Téléchargez cette ressource
Guide de Sécurité IA et IoT
Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.
