LES ENTREES / ENREGISTREMENTS DNS NE SE METTENT PAS A JOUR !

Bonjour

J’ai récemment travaillé sur des problèmes DNS (entrées DNS à jour).

DESCRIPTION DU PROBLEME :
Les entrées DNS de type A (Hôte) des stations de travail (en DHCP) et des imprimantes (en DHCP) ne se mettent pas à jour.
A T=0, la station de travail A.MSREPORT.LOCAL a l’IP 192.168.0.100. L’entrée DNS A est créé dans la zone MSREPORT.LOCAL avec comme IP : 192.168.0.100.
A T=1, la station de travail A.MSREPORT.LOCAL a l’IP 192.168.0.101. L’entrée DNS A dans la zone MSREPORT.LOCAL reste sur 192.168.0.100. On a le problème !
Ce problème se pose :
– Cas 1 : si le compte ordinateur Active Directory d’une station de travail Windows est supprimée puis recréée.
– Cas 2 : si on déplace une imprimante / machine non Windows entre VLANS (même serveur DHCP).
– Cas 3 : si on déplace une imprimante / machine non Windows entre deux sites géographiques (changement de serveurs DHCP).
– Cas 4 : si une personne de l’informatique a créé manuellement l’entrée DNS d’une station de travail / imprimante.
– Cas 5 : si on a récemment changé de serveur DHCP (Windows Server).

La configuration est la suivante :
– Annuaire Active Directory (on a le problème avec toutes les versions des contrôleurs de domaine Windows).
– Zones DNS intégrées à l’annuaire. Les mises à jour dynamiques DNS sont activées sur les zones DNS et sont configurées sur “Sécurisées uniquement”.

D’OU VIENT LE PROBLEME ?
Il s’agit tout simplement d’un problème de permissions au niveau de l’entrée DNS !

EXPLICATIONS :
Quand on intègre une zone DNS dans l’annuaire Active Directory, les entrées DNS deviennent des objets (comme les comptes utilisateurs) de type DNSNODE.
Ces objets ont des permissions. Hors pour pouvoir mettre à jour l’adresse IP d’une entrée DNS de type A (type Hôte, nom résolu en IP), il faut avoir le droit “Ecrire” sur l’entrée DNS (l’objet de type DNSNODE).

QUI A LE DROIT DE METTRE A JOUR UNE ENTREE DNS ?
– Quand on crée manuellement une entrée DNS, c’est le compte utilisateur qui a créé l’entrée qui a le droit d’écrire. Il existe une option qui permet d’autoriser tous les utilisateurs authentifiées à mettre à jour l’entrée DNS.
– Pour les machines en DHCP, cela dépend de la configuration du serveur DHCP. Selon le cas, c’est le compte ordinateur du serveur DHCP, le compte ordinateur de la station de travail ou un compte de service qui a le droit de modifier l’entrée DNS.

COMMENT DETERMINER QUI A LE DROIT DE MODIFIER UNE ENTREE DNS ?
Ouvrir la console DNS. Cliquer dans le menu “Affichage” puis sélectionner “Affichage détaillée“.
Quand on double clic sur une entrée DNS, on voit maintenant la date de création de l’enregistrement (si c’est une entrée DNS créée dynamiquement) et l’onglet “Sécurité” (permission sur l’objet).

COMMENT CONFIGURER QUI A LE DROIT DE MODIFIER UNE ENTREE DNS CREES MANUELLEMENT (ENTREE DNS STATIQUE) ?
On a la case “Autoriser tout utilisateur identifié à mettre à jour les enregistrements DNS…” dans la fenêtre de création de l’entrée DNS A. Tous les utilisateurs authentifiées (machines et utilisateurs du domaine peuvent modifier l’entrée DNS).

COMMENT CONFIGURER QUI A LE DROIT DE MODIFIER UNE ENTREE DNS CREE DYNAMIQUEMENT ?
Ouvrir la console DHCP et aller dans les propriétés du serveur DHCP.
Aller dans l’onglet “DNS“.
Si vous sélectionnez, “Mettre à jour les enregistrements PTR et A DNS uniquement si des clients DHCP le demandent” :
– Pour les machines Windows en DHCP : elles créent elles-même l’entrée DNS. C’est donc le compte ordinateur de la machine Windows qui a le droit de modifier l’entrée DNS.
– Pour les autres machines (qui ne savent pas faire des mises à jour dynamiques DNS sécurisées), c’est le compte ordinateur du serveur DHCP.
Si vous sélectionner “Toujours mettre à jour dynamiquement les enregistrements PTR et A DNS“, c’est le compte ordinateur du serveur DHCP qui a le droit de modifier les entrées DNS (pour les stations Windows ou autres).

Attention, cela n’est vrai que si vous n’avez pas configuré un compte de service pour effectuer les mises à jour dynamiques DNS au niveau du service DHCP.
Cela se configure dans l’onglet “Avancé” dans les propriétés du serveur DHCP. Cliquer sur “Informations d’identification”. Voir article Microsoft :
http://support.microsoft.com/kb/282001/en-us
Si cette option est activée ce n’est plus le compte ordinateur du serveur DHCP qui a les droits mais ce compte de service.
Si vous sélectionnez, “Mettre à jour les enregistrements PTR et A DNS uniquement si des clients DHCP le demandent” :
– Pour les machines Windows en DHCP : elles créent elles-même l’entrée DNS. C’est donc le compte ordinateur de la machine Windows qui a le droit de modifier l’entrée DNS.
– Pour les autres machines (qui ne savent pas faire des mises à jour dynamiques DNS sécurisées), c’est le compte de service DNS configuré dans l’onglet “Avancé” du serveur DHCP qui a le droit de modifier l’entrée.

PRECONISATIONS :
Mettre en place la configuration suivante :
– Tous les serveurs DHCP doivent avoir la même configuration (DHCP Microsoft).
– Configurer le serveur DHCP pour “Mettre à jour les enregistrements PTR et A DNS uniquement si des clients DHCP le demandent“.
– Ne jamais supprimé les comptes ordinateurs des stations de travail. On peut les réinitialiser. Au pire supprimer les ServicePrincipalname intule avec la commande SETSPN.
– Configurer le serveur DHCP pour effectuer les mises à jour dynamiques DNS à l’aide d’un compte de service. Voir article Microsoft : http://support.microsoft.com/kb/282001/en-us
– Mettre en place le SCAVENGING. Cela purge les entrée dynamiques qui n’ont pas été mise à jour depuis plus de 14 jours par défaut (les entrées statiques ne sont pas purgées).
Cette configuration nous permet de gérer les cas 2 et 3 car c’est plus le compte ordinateur du serveur DHCP qui a les droits mais un compte de service identique sur tous les serveurs DHCP.
Je préfère laisser “Mettre à jour les enregistrements PTR et A DNS uniquement si des clients DHCP le demandent” car il n’est pas rare qu’une station de travail Windows repasse en IP fixe puis de nouveau en DHCP selon la configuration de vos sites. Dans ce cas c’est le compte ordinateur de la station de travail qui a les droits donc pas de problème.

Il sera nécessaire de modifier les permissions des entrées DNS si :
– Vous changez de serveur DHCP (changement du compte ordinateur du serveur DHCP) sans avoir activé le compte de service pour les mises à jour dynamique DNS au niveau de tous les serveurs DHCP.
– Si vous changez les paramètres de la mise à jour dynamique DNS au niveau de vos serveurs DHCP (danger).

CODE SOURCE DU SCRIPT POWERSHELL POUR METTRE A JOUR LES ENTREES DNS :
Le script ci-dessous nécessite PowerShell V1 / V2 et l’installation du module Quest Active management Shell for Active Directory
Dans l’exemple ci-dessous, la zone réplique au niveau de la partition de domaine.
Il faudra valider où se trouve la zone et se connecter sur cette zone avec ADSIEDIT.MSC (installer les support tools présents sur le CD d’installation de Windows 2003 Server).

Dans le conteneur système de la partition de domaine msreport.local :
DC=msreport.local,CN=MicrosoftDNS,CN=System,DC=MSREPORT,DC=LOCAL
Dans la ForestDnsZones :
DC=msreport.local,CN=MicrosoftDNS,DC=ForestDnsZones,DC=archidfs,DC=local
Dans la DomainDnsZones :
DC=msreport.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=archidfs,DC=local

Set-QADPSSnapinSettings -DefaultSizeLimit 0
Connect-Qadservice nom_du_contrôleur_domaine
Get-QADObject -UseGlobalCatalog -Identity m –SearchRoot “DC=msreport.local,CN=MicrosoftDNS, CN=System,DC=MSREPORT,DC=LOCAL” -Type Dnsnode | Add-QADPermission -Account “compte_groupe_pour_permissions_modifier_entrees” –Rights ‘GenericWrite,ReadControl,WriteProperty’ -ApplyTo ‘ThisObjectOnly’ 

POUR ALLER PLUS LOIN :
On peut voir les accès refusés au niveau des mises à jour des entrées DNS en activant l’audit (réussite et échec) pour « l’accès aux objets » au niveau de la stratégie « Default Domain Controller Policy ».
Faire un gpupdate /force sur chaque contrôleur de domaine ou attendre 5 minutes.
Par défaut, l’audit est configuré que pour les réussites au niveau d’une zone DNS. Il faut aussi ajouter les SACL pour les échecs.
Aller dans les propriétés de la zone DNS, dans « Sécurité », cliquez sur « Permissions avancées » au niveau de la zone DNS « MSREPORT.LOCAL ». Ajouter une entrée en « réussite / échec » pour tout le monde et pour les actions d’écriture.
Ouvrir le journal sécurité du contrôleur de domaine utilisé par le client DHCP / station de travail (voir LOGONSERNAME de la commande SET pour obtenir cette information).
On obtient ces messages :
Type de l’événement : Audit des échecs
Source de l’événement : Security
Catégorie de l’événement : Accès Active Directory
ID de l’événement : 566
Date : 6/20/2011
Heure : 6:07:40 PM
Utilisateur : MSREPORT\XPGMATHI-6DB635$
Ordinateur : SRVDFSR1
Description :
Opération d’objet :
   Serveur d’objet : DS
   Type d’opération : Object Access
   Type d’objet : dnsNode
   Nom d’objet : DC=xpgmathi-6db635,DC=msreport.local, CN=MicrosoftDNS,DC=DomainDnsZones,DC=archidfs,DC=local
   ID de handle : –
   Nom d’utilisateur principal : SRVDFSR1$
   Domaine principal : ARCHIDFS
   ID d’ouv de session principale : (0x0,0x3E7)
   Nom d’utilisateur client : XPGMATHI-6DB635$
   Domaine client : ARCHIDFS
   ID d’ouv de session client : (0x0,0x390006)
   Accès : Écriture personnelle  
   Propriétés :
   Default property set
   dnsRecord
   dNSTombstoned
   dnsNode
   Informations additionnelles :
   Informations additionnelles 2 :
   Masque d’accès : 0x8

Type de l’événement : Audit des échecs
Source de l’événement : Security
Catégorie de l’événement : Accès Active Directory
ID de l’événement : 566
Date : 6/20/2011
Heure : 6:11:11 PM
Utilisateur : MSREPORT\XPGMATHI-6DB635$
Ordinateur : SRVDFSR1
Description :
Opération d’objet :
   Serveur d’objet : DS
   Type d’opération : Object Access
   Type d’objet : dnsNode
   Nom d’objet : DC=xpgmathi-6db635,DC=msreport.local,CN=MicrosoftDNS,DC=DomainDnsZones,DC=archidfs,DC=local
   ID de handle : –
   Nom d’utilisateur principal : SRVDFSR1$
   Domaine principal : ARCHIDFS
   ID d’ouv de session principale : (0x0,0x3E7)
   Nom d’utilisateur client : XPGMATHI-6DB635$
   Domaine client : ARCHIDFS
   ID d’ouv de session client : (0x0,0x39DB62)
   Accès : Propriété d’écriture    
   Propriétés :
   Default property set
   dnsRecord
   dNSTombstoned
   dnsNode
   Informations additionnelles :
   Informations additionnelles 2 :
   Masque d’accès : 0x20

A+
Guillaume MATHIEU
PROSERVIA
La connaissance s’accroît quand on la partage
http://msreport.free.fr