Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article vous aide à résoudre le problème dans lequel plusieurs enregistrements sont inscrits avec la même adresse IP. Le problème est dû aux configurations de la récupération du système DNS (Domain Name System) et de la durée du bail DHCP (Dynamic Host Configuration Protocol).
Scénario
Considérons le scénario suivant.
Sur un serveur DHCP, vous disposez des configurations suivantes :
- Une étendue DHCP a sa durée de bail définie sur les huit jours par défaut.
- L’étendue DHCP est faible sur les adresses IP disponibles.
- Le client A ne renouvelle pas son bail d’adresse IP en huit jours et expire.
- Le client B demande une nouvelle adresse IP.
- Le serveur DHCP attribue au client B l’adresse qui est louée au client A.
Ce scénario est typique et tout fonctionne correctement.
Sur un serveur DNS, vous avez les configurations suivantes :
- Une zone DNS intégrée Active Directory (AD) est définie sur des enregistrements de ressources obsolètes.
- Le balayage d’enregistrement DNS utilise les paramètres par défaut : intervalle d’actualisation sans actualisation = 7 jours, intervalle d’actualisation = 7 jours et période d’actualisation = 7 jours.
- Le client A renouvelé son enregistrement DNS il y a huit jours lorsque le bail DHCP du client a été mis à jour pour la dernière fois.
- Par défaut, le client A est le propriétaire de son enregistrement DNS. L’enregistrement ne peut donc pas être supprimé par le serveur DHCP.
- Le client B inscrit son enregistrement DNS avec la nouvelle adresse IP reçue du serveur DHCP, qui est identique à l’enregistrement enregistré auprès du client A.
Dans ce scénario, le serveur DNS ne peut pas venger l’enregistrement DNS du client A pendant six jours. À présent, le client A et le client B ont la même adresse IP inscrite dans DNS.
Analyse des problèmes
Plusieurs problèmes se produisent en raison du même enregistrement DNS pour différents noms. Par exemple, problème d’installation avec les clients Microsoft System Center Configuration Manager (SCCM).
Voici un autre exemple. Lorsque vous accédez à un partage sur le client A, vous recevez le message d’erreur suivant, même lorsque le client A n’est pas activé.
Cette erreur est due au fait qu’un ticket Kerberos destiné à un ordinateur est envoyé à un autre ordinateur. La section suivante décrit l’ensemble du processus.
Flux réseau lors de l’échec de connexion
L’ordinateur (Infra-App1) effectue une requête DNS pour client-a.corp.contoso.com. Réponses DNS avec l’adresse IP 10.0.0.100.
En ce qui concerne DNS, le résultat est correct. Le client A a la valeur 10.0.0.100 listée comme adresse IP. Par conséquent, le client B.
Ensuite, l’ordinateur Infra-App1 demande un ticket Kerberos. La requête DNS concerne le client A. Par conséquent, la requête TGS (Ticket Granting Service) est également destinée au client A.
Requête TGS :
Réponse du contrôleur de domaine :
Une fois que l’ordinateur Infra-App1 reçoit le ticket, l’ordinateur tente de se connecter au client A. Le ticket Kerberos est inclus dans ce cadre.
Enfin, le client distant retourne une erreur, car l’ordinateur Infra-App1 se connecte au client B.
L’erreur est attendue, car vous devez présenter le ticket approprié au compte approprié pour que Kerberos fonctionne.
Note
Pour plus d’informations sur Kerberos, consultez Kerberos pour l’administrateur occupé.
Ce problème ne se produit pas si vous utilisez l’adresse IP au lieu du nom de domaine complet (FQDN), car l’authentification NTLM (New Technology LAN Manager) est utilisée au lieu de l’authentification Kerberos. Lorsque vous utilisez l’adresse IP pour vous connecter au client, il n’existe aucune hypothèse quant au client auquel il est connecté. Par conséquent, l’ordinateur doit d’abord négocier NTLM. Pour l’exemple de la section scénario , Kerberos retourne une réponse valide, de sorte que l’ordinateur ne bascule pas pour utiliser NTLM.
Résolutions
Étant donné que ce problème est lié aux enregistrements DNS obsolètes, vous pouvez utiliser différentes résolutions pour empêcher le problème de se produire.
Note
Pour chaque résolution, nous vous recommandons de réduire l’intervalle de décavenage à un à trois jours. La valeur par défaut de sept jours étend la période pendant laquelle les enregistrements non valides restent dans DNS.
Résolution 1
Augmentez la durée du bail DHCP pour qu’elle corresponde aux intervalles No-refresh + Refresh . Pour l’exemple de la section scénario , vous pouvez augmenter le bail DHCP à 14 jours.
Avantage:
Les baux DHCP restent jusqu’à ce que l’enregistrement DNS soit délimité. Aucun autre client ne reçoit et n’inscrit l’adresse dans DNS.
Désavantage:
Si l’étendue DHCP est déjà faible sur les adresses, les adresses IP peuvent s’exécuter.
Un petit pourcentage d’enregistrements peut ne pas être réduit avant l’expiration du bail en raison de petites différences de temps. La définition de l’intervalle d’actualisation sur un jour garantit que les enregistrements obsolètes sont supprimés le lendemain.
Résolution 2
Réduisez les intervalles Sans actualisation + Actualisation pour qu’ils correspondent au bail DHCP. Pour l’exemple de la section du scénario, vous pouvez réduire à la fois l’actualisation sans actualisation et l’actualisation à quatre jours.
Avantage:
L’enregistrement DNS existant est délimité plus tôt pour atteindre les mêmes résultats que dans la première solution.
Désavantage:
S’il s’agit de zones DNS intégrées AD, la fréquence de réplication AD augmente. Cela est dû au fait que les enregistrements DNS sont actualisés plus fréquemment par les clients. Par exemple, tous les quatre jours au lieu de tous les sept jours.
Un petit pourcentage d’enregistrements peut ne pas être réduit avant l’expiration du bail en raison de petites différences de temps. La définition de l’intervalle d’actualisation sur un jour garantit que les enregistrements obsolètes sont supprimés le lendemain.
Résolution 3
Autorisez le serveur DHCP à inscrire les adresses pour le compte des clients.
Avantage:
Le serveur DHCP peut supprimer l’enregistrement DNS dès l’expiration du bail. Si le programme d’installation est correct, aucun enregistrement en double ne doit exister.
Désavantage:
La configuration est plus impliquée.
Un compte de service doit être configuré pour exécuter le service DHCP, ou tous les serveurs DHCP doivent être joints au groupe DNSUpdateProxy (moins sécurisé). La configuration ajoute de la complexité.
Pour ce faire, consultez Comment configurer des mises à jour dynamiques DNS dans Windows.
Expérimentez la durée du bail DHCP, l’intervalle sans actualisation et l’intervalle d’actualisation. Vous devrez peut-être quitter complètement les valeurs par défaut. Les durées de bail DHCP faibles (en heures) sont parfois utilisées pour les sous-réseaux sans fil. Gardez à l’esprit les performances de vos serveurs, en particulier si vous avez un serveur DNS défini pour se venger toutes les quelques heures sur de grandes zones DNS.
Identifier les enregistrements avec des adresses IP dupliquées
Cette section explique comment utiliser PowerShell pour identifier les enregistrements en double. Le script vise à rechercher des enregistrements dans DNS qui contiennent des adresses IP en double.
#Import the Active Directory Module
import-module activedirectory
#Define an empty array to store computers with duplicate IP address registrations in DNS
$duplicate_comp = @()
#Get all computers in the current Active Directory domain along with the IPv4 address
#The IPv4 address is not a property on the computer account so a DNS lookup is performed
#The list of computers is sorted based on IPv4 address and assigned to the variable $comp
$comp = get-adcomputer -filter * -properties ipv4address | sort-object -property ipv4address
#For each computer object returned, assign just a sorted list of all
#of the IPv4 addresses for each computer to $sorted_ipv4
$sorted_ipv4 = $comp | foreach {$_.ipv4address} | sort-object
#For each computer object returned, assign just a sorted, unique list
#of all of the IPv4 addresses for each computer to $unique_ipv4
$unique_ipv4 = $comp | foreach {$_.ipv4address} | sort-object | get-unique
#compare $unique_ipv4 to $sorted_ipv4 and assign just the additional
#IPv4 addresses in $sorted_ipv4 to $duplicate_ipv4
$duplicate_ipv4 = Compare-object -referenceobject $unique_ipv4 -differenceobject $sorted_ipv4 | foreach {$_.inputobject}
#For each instance in $duplicate_ipv4 and for each instance
#in $comp, compare $duplicate_ipv4 to $comp If they are equal, assign
#the computer object to array $duplicate_comp
foreach ($duplicate_inst in $duplicate_ipv4)
{
foreach ($comp_inst in $comp)
{
if (!($duplicate_inst.compareto($comp_inst.ipv4address)))
{
$duplicate_comp = $duplicate_comp + $comp_inst
}
}
}
#Pipe all of the duplicate computers to a formatted table
$duplicate_comp | ft name,ipv4address -a
Voici un exemple de sortie :
Ce script PowerShell est simple. Considérez le script comme un exemple. Ce script retourne uniquement des adresses IP dupliquées inscrites dans des comptes d’ordinateur réels dans AD. N’oubliez pas que le script interroge chaque ordinateur d’un domaine AD. Ensuite, il effectue une requête DNS pour obtenir l’adresse IP. Si vous avez de nombreux ordinateurs, utilisez le -searchbase commutateur avec get-adcomputer pour limiter le nombre d’ordinateurs retournés à chaque fois. Si l’ordinateur n’est pas joint à AD, l’ordinateur n’est pas retourné à partir de la get-adcomputer commande.