Active Directory : pourquoi et comment empêcher les utilisateurs d’ajouter des enregistrements DNS ?
Sommaire
I. Présentation
Par défaut, dans un environnement Active Directory, tous les utilisateurs authentifiés ont la capacité d'ajouter des enregistrements DNS dans la zone principale. Cette configuration est en partie nécessaire pour le bon fonctionnement des mises à jour dynamiques, mais elle constitue également une porte d'entrée pour plusieurs techniques d'attaque.
Il est toutefois possible d'interdire cette action aux comptes utilisateurs tout en continuant à autoriser les ordinateurs à gérer leurs propres enregistrements DNS. C’est ce que nous allons faire dans ce tutoriel.
II. Pourquoi interdire la création d'enregistrements DNS aux utilisateurs ?
Laisser n'importe quel utilisateur du domaine créer des enregistrements DNS est un prérequis pour plusieurs attaques, notamment :
- Le relai NTLM WebDAV vers LDAP
- La CVE-2025-33073 patchée en juin 2025
Ces deux attaques permettent une élévation de privilèges à distance sur les postes.
Comme souvent en matière de durcissement AD, restreindre cette permission permet de se protéger entièrement ou partiellement contre des vulnérabilités actuelles et futures.
III. Identification de la configuration actuelle
La permission d'ajouter des enregistrements DNS est définie au niveau des ACL (contrôle d'accès) de la zone DNS. Voyons comment auditer la configuration actuelle.
Suivez ces étapes :
1 - Commencez par ouvrir la console dnsmgmt.msc (Gestionnaire DNS).
2 - Effectuez un clic droit sur la zone DNS concernée (ex : corp.local) > Propriétés.
3 - Cliquez sur l'onglet Sécurité.
4 - Désormais, vérifiez si le groupe Utilisateurs authentifiés ("Authenticated Users") dispose du droit Créer tous les objets enfants ("Create all child objects").
Si ce droit est présent, n’importe quel utilisateur peut créer un enregistrement DNS manuellement. Pas encore convaincu ? Regardez la capture ci-dessous où un enregistrement DNS est créé en utilisant l’outil dnstool.
IV. Restreindre l’ajout d’enregistrements DNS
Cette permission existe pour une raison : les ordinateurs du domaine utilisent les mises à jour dynamiques pour publier ou renouveler leurs enregistrements. Supprimer cette autorisation sans précaution peut donc perturber la connectivité.
L’objectif est donc de supprimer la permission pour les utilisateurs, mais de la réattribuer explicitement au groupe "Ordinateurs du domaine" (Domain Computers).
Suivez ces étapes :
1 - Ouvrez de nouveau la console dnsmgmt.msc (Gestionnaire DNS).
2 - Effectuez un clic droit sur la zone DNS > Propriétés, puis cliquez sur l'onglet Sécurité
3 - Supprimez le droit Créer tous les objets enfants pour Utilisateurs authentifiés.
4 - Cliquez sur Ajouter..., puis recherchez et ajoutez le groupe de sécurité Ordinateurs du domaine
Cocher la permission Créer tous les objets enfants pour ce groupe de sécurité. Comme ceci :
Vous pouvez valider, la configuration est terminée !
V. Vérification du bon fonctionnement
Une fois la modification appliquée, il faut :
- Vérifier qu’un utilisateur standard ne peut plus ajouter d’enregistrement DNS. Par exemple avec dnstool.py exécuté en tant qu’utilisateur standard de l’AD. Autrement dit, le test effectué précédemment ne devrait plus fonctionner !
- Vérifier qu’un ordinateur joint au domaine peut toujours s’enregistrer :
- Renommez une machine
- Exécutez
ipconfig /registerdnset/ou redémarrez le poste - Vérifiez dans la console DNS si le nouvel enregistrement apparaît
VI. Conclusion et remarques
Ce durcissement est très peu documenté en ligne, ce qui en fait un point de sécurité souvent négligé. Comme pour toute action de hardening AD :
- Il est essentiel de documenter le changement
- Il faut être capable de revenir rapidement en arrière en cas de dysfonctionnement
Enfin, gardez à l’esprit que cette mesure ne protège pas contre tout :
- Un attaquant ayant compromis une machine pourra toujours utiliser l'identité de celle-ci pour publier un enregistrement DNS malveillant
- Si votre MachineAccountQuota (MAQ) n’est pas à 0, un utilisateur pourra créer un compte machine et obtenir les mêmes droits. Si ce n’est pas fait, cet article vous expliquera comment changer cette autre configuration par défaut dangereuse
Belle initiative Alexis. Je trouve dommage que tu n’es pas profité de l’occasion pour creuser le sujet : en matière de cyber sécurité, le plus important est de comprendre le risque et de pouvoir l’évaluer afin d’adapter la réponse à son contexte personnel. J’aurai par exemple aimé en savoir plus sur les ACL (un rappel de ce que c’est), pourquoi cette configuration par défaut existe, comment maintenir un registering dynamique sans exposé le DNS (compte de service sur un dhcp ms par exemple) ou même un petit clin d’oeil au solution tierce qui permette de sortir le DNS du contrôleur de domaine (ce qui est justement notre souci). En tout cas, bon travail et merci d’avoir pris le temps de le partager !
Bonjour Loïc,
Merci pour ton commentaire. Ce n’est cependant pas le but de l’article de faire toute une présentation des concepts initiaux. Pour ce qui est des autres conseils de gestion, ils existent mais encore une fois le but de cette article est de montrer comment on peut faire un petit hardening sans trop se compliquer.
Ce sont néanmoins des suggestions intéressantes 🙂
Bonjour Alexis,
Très bonne article merci.
Le compte ordinateur aura donc le droit de modifier son compte si et seulement si il en est propriétaire.
Par contre si c’est le DHCP via son compte de service qui a créé l’enregistrement, le compte DHCP sera propriétaire de l’enregistrement et le compte ordinateur ne pourra pas mettre à jour son enregistrement ou son PTR.
(Erreur dans le journal de log DNS lors d’un ipconfig /registerdns).
Avez vous une idée comment palier à ce problème ?
Cordialement
Aurelien
Bonjour Aurélien,
Merci pour ton commentaire très utile. Dans ce cas il faudra sûrement aussi ajouter ce compte de service en lui donnant le droit de créer des objets enfants de la même manière qu’on ajoute les ordinateurs du domaine dans l’article.
Si tu as un retour suite à cela, ça me permettra de modifier l’article pour ajouter cette précision !
Bonjour, effectivement comme le dit Harden@D ça mérite peut être un article plus large sur la différence des mises à jour DNS dynamique vs mise à jour DHCP DNS et les usurpations / écrasement que ces fonctionnalités donnent aux hacker….
Un PC Windows récent n’a pas besoin que le DHCP mette à jour le DNS, il est même conseillé de désactiver cette fonctionnalité du DHCP, c’est surtout fait pour les linux/téléphones mais est-ce qu’on en a vraiment besoin…
Normalement votre PC Windows en se connectant va faire de lui même et de temps en temps (timeout/chache dns) un registerdns et vous verrez dans l’enregistrement DNS le nom du PC, si c’est le DHCP qui le fait c’est que le PC n’est pas arrivé à le faire et que vous avez un autre problème quelque part. Quel est l’erreur?
Cordialement
Bonjour, merci pour ces précisions !
Pour ma part, je n’ai jamais vu de client utiliser le DHCP pour effectuer les enregistrements DNS, c’est toujours les machines qui s’en chargent directement. Mais ça ne doit pas être si rare que ça comme vous êtes la deuxième personne à le mentionner 🙂
Je ne sais pas si j’en ferai un article, même si le sujet est intéressant. Si un autre auteur IT-Connect passe par là et souhaite s’y pencher, je lui laisse volontiers le soin d’approfondir ce point qui relève plus de l’administration système
Hello,
L’intérêt de l’inscription des enregistrements DNS par le DHCP sont pour les périphériques qui ne peuvent pas le faire d’eux-même, comme le dit @DIDI Abaric, un exemple de ces enregistrements « nécessaires » sont les imprimantes … Donc je confirme que ce n’est pas si rare de trouver des DHCP configurés pour réaliser les enregistrements A et PTR.
Bon article qui explique bien, certaines problématiques de configuration par défaut.
J’ajouterai un léger bémol, en tant qu’administrateur d’une machine Windows vous pourriez donc toujours faire n’importe quels enregistrements DNS, car votre machine disposera des permissions de le faire et que vous pouvez déclencher un script via PSEXEC (par exemple) … Mais c’est toujours mieux que de laisser cette permissions à tous les utilisateurs « authentifiés ».