Régler les problèmes d’authentification AD

Nslookup a fait deux
choses : il a contacté avec succès un
serveur DNS et il lui a demandé de résoudre
à  l’envers l’adresse IP du serveur
dans un nom DNS. La résolution
inverse n’est pas nécessaire pour des
logons AD, mais si un serveur DNS fonctionnel ne fait pas la résolution inverse,
Nslookup renvoie un message
laissant entendre qu’il se passe
quelque chose de grave :

DNS request timed out.

timeout was 2 seconds.

*** Can t find server name

for address 200.200.10.10;

Timed out

*** Default servers are not

available

Default Server: UnKnown

Address: 200.200.10.20

Toutefois, si vous tapez une
adresse Internet (www.win2000mag.
com, par exemple) à  l'invite Nslookup,
la réponse révèle que Nslookup résout
facilement ce nom :

www.win2000.com

Server: ns1.yourisp.com

Address: 200.200.10.10

Name: www.win2000mag.com

Address: 63.88.172.66

Nslookup se plaint également si le
serveur DNS que votre client DNS est
supposé utiliser est « mort » ou a un
problème:

*** Can t find server name

for address 200.200.10.10;

No response from server

*** Default servers are not

available

Default Server: UnKnown

Address: 200.200.10.10

Voyez-vous une différence notable
entre cette réponse et celle qui indique
qu'une résolution inverse a échoué ?
Non ? Moi non plus. Alors comment
pouvez-vous déterminer si le serveur a
un vrai problème ou si Nslookup se
plaint à  propos de la résolution inverse
? Le mieux est d'essayer simplement
de résoudre une adresse
Internet. Si le problème se situe sur le
serveur, la réponse ressemblera à  celleci
:

Server: UnKnown

Address: 200.200.10.20

*** UnKnown can t find

www.win2000mag.com: No

response from server

Ensuite, demandons à  Nslookup
de simuler en utilisant un DC local pour se connecter. Vous devrez
connaître le nom de votre domaine et
de votre site AD. Vous aurez toujours
au moins un site : quand vous créez le
premier DC dans une forêt, Dcpromo
crée un site appelé, par défaut,
Default-First-Site-Name. Tapez la commande
Nslookup sur une ligne de
commande. A l'invite, entrez deux
commandes, en utilisant la syntaxe

set type=srv

_kerberos._tcp.

._sites.dc._msdcs.

Respectez les traits de soulignement,
et tapez la seconde commande
sur une ligne sans espaces. Par
exemple, pour un site nommé HQ
dans le domaine acme.com, vous taperiez

set type=srv

_kerberos._tcp.hq._sites.doc

._msdcs.acme.com

Si vous tapez les commandes correctement,
vous pourriez obtenir une
réponse comme celle de la figure 1 (si
ce n'est pas le cas, ne soyez pas inquiet
: c'est pour ça que nous recherchons
la solution). Mais si ces commandes
ne fonctionnent pas dans
votre cas, Dcpromo ne pourra pas non
plus se connecter. Il dirait alors à  DNS,
« Informez-moi sur tous les DC du
monde pour acme.com ». Vous pouvez également utiliser Nslookup pour simuler
cette requête,

_kerberos._tcp.dc._msdcs

.acme.com

Mais si la première requête a
échoué, il en sera probablement de
même pour celle-ci, avec un message
ressemblant à  ceci ns1.yourisp.com
can't find kerberos._tcp.dc._msdcs.
acme.com: Non-existent domain.

La raison de ce problème dans la
plupart des réseaux de test est que
votre domaine AD (acme.com, par
exemple) porte le même nom qu'un
domaine Internet enregistré et que ce
conflit de noms pose des problèmes.
Pour voir pourquoi, revenons au moment
où vous avez créé le premier DC
dans la forêt de test.