Active Directory : le pare-feu est en profil « Public » au démarrage des contrôleurs de domaine, que faire ?

I. Présentation

Cet article décrit une solution de contournement pour corriger le problème de profil de connexion identifié comme « public » au niveau du pare-feu d'un contrôleur de domaine, après redémarrage.

Il s'agit d'un problème fréquemment rencontré en environnement Active Directory. À partir du Gestionnaire de serveur, vous pouvez constater l'état suivant : Pare-feu Microsoft Defender - Public : Actif. Cependant, la connexion devrait être de type "Domaine" (Réseau avec domaine).

Certains pourraient arguer que cela n'est pas bien grave, qu'après tout le serveur peut se trouver lui-même. Oui… Et non. Le problème avec le profil de réseau public, c'est qu'il va "brouiller" l'écoute de certains services et que, si en apparence tout semble bien se comporter, dans les faits, le service est devenu bancal.

Par exemple, vous auriez l'impression que la promotion d'un contrôleur de domaine s'est bien déroulé ou que vos réplications sont toutes fonctionnelles… Et soixante jours plus tard, c'est la catastrophe... Or tout le monde n'a pas la compétence technique pour résoudre ces problèmes de fond - lorsqu'une personne expérimentée vous identifiera la panne en 1 minute ou 2 (pour la remise en route, c'est une autre histoire qui dépend de la précocité de la détection de l'incident... Et de Gérard). Voilà pourquoi il est crucial que notre profil de réseau soit bien déclaré sur Domaine (DomainAuthenticated).

Par ailleurs, le profil actif a également un impact sur les règles de pare-feu actives. Chaque règle de pare-feu peut être activée sur un ou plusieurs profils. Ainsi, certains flux autorisés uniquement sur le profil "Domaine" pourraient être bloqués si le serveur bascule en mode "Public".

II. Description du problème

Le problème a été constaté sur des contrôleurs de domaine Windows Server 2019 et ultérieur. Il pouvait alors être « corrigé » en ajoutant une dépendance au service « DNS Server » (DNS) sur le service « Network Location Awarness » (NLASVC) via une manipulation de la base de registre. Toutefois, les tests sur Windows Server 2025 ont rendu cette approche inefficace.

Ce qui a changé...

Un article du 15 janvier 2025 sur le site de Microsoft explique les modifications qui ont été apportées à la détection du type de réseau par les systèmes Windows 11 (et donc Windows Server 2025 par extension) : on y apprend que le service historique qui assurait la découverte, NlaSvc, est remplacé par un nouveau service appelé Network List Manager (netprofm.exe) :

Je vous invite d’ailleurs à aller lire l’article explicatif de Microsoft qui est riche d’enseignement :

• Domain-joined machines can't detect the domain profile

Comment expliquer ce problème récurrent ?

Pour identifier si le système est intégré à un réseau de domaine Active Directory, le service envoie une requête au serveur DNS du client au travers de la fonction DsGetDcName - fonction qui retrouve le nom du contrôleur de domaine - puis tente une connexion LDAP pour s’assurer que le système peut s’authentifier auprès de ce dernier.

En cas de succès, le profil de réseau sera basculé sur DomainAuthenticated – et c’est là notre drame ! Lorsque la requête est réalisée, le service DNS n’a pas terminé de charger les zones depuis les partitions DomainDNSZones et ForestDNSZones, rendant caduc le test et bloquant le processus de découverte automatique. Le problème se poserait également si le service ADDS n’était pas opérationnel au moment de la demande de bind réalisé par le client (cas très particulier du contrôleur de domaine unique).

III. Comment contourner ce problème ?

Les manipulations par la base de registre, proposées dans les articles de références du support Microsoft, ne fonctionnent pas avec Windows Server 2025. En revanche, le fait de changer une information sur la configuration réseau, de désactiver puis réactiver la carte réseau ou encore de redémarrer l’interface réseau permet de basculer dans le profil DomainAuthenticated (Réseau avec domaine).

La solution présentée ici permet d’automatiser le redémarrage de l’interface réseau dès que le service DNS a terminé son chargement.

A. Un script PowerShell en guise de solution

Pour des raisons de commodité dans l’organisation des scripts et également pour protéger par défaut ces derniers contre la manipulation par des utilisateurs non-administrateurs, les scripts exécutés via des tâches planifiées sont rangés dans le répertoire Users - Attention à ne pas nommer le dossier avec un compte existant dans votre domaine.

Le script sera donc positionné à l'emplacement suivant :

C:\Users\Scripts

Le script Invoke-DomainAuthenticatedProfileFix.ps1 présenté ci-dessous redémarrera toutes les cartes réseaux du système. Une seule ligne suffit pour accomplir cette tâche. Si votre système dispose de plusieurs interfaces, n’hésitez pas à l’adapter.

Get-NetAdapter | Restart-NetAdapter

Désormais, vous devez exécuter ce script à l'aide d'une tâche planifiée.

B. Création de la tâche planifiée

À partir du Planificateur de tâches de Windows, vous devez créer une nouvelle tâche planifiée. Celle-ci peut être distribuée sur plusieurs serveurs à l'aide d'une stratégie de groupe.

La tâche planifiée est déclarée avec les valeurs suivantes sur les contrôleurs de domaine.

• Nom : Fix DomainAuthenticated Profile
• Description : Run a command to force rediscovery.
• Compte : System
• Exécution : avec les plus hauts privilèges
• Configuré pour : Windows Server 2025

Puis, vous devez configurer un nouveau déclencheur sur un évènement. Ici, nous allons déclencher la tâche lorsqu'un événement avec l'ID 2 sera détecté dans le journal DNS Server de la machine locale.

Enfin, basculez dans l'onglet suivant pour ajouter une nouvelle action de type "Démarrer un programme". Dans le cas présent, la tâche planifiée devra exécuter le programme powershell.exe et vous devez spécifier la valeur suivante en tant qu'argument :

-ExecutionPolicy Bypass -NonInteractive -WindowStyle Hidden -File Invoke-DomainAuthenticatedProfileFix.ps1

Vous devez aussi spécifier Démarrer dans avec la valeur C:\Users\Scripts sinon PowerShell ne pourra pas trouver le script.

Vous pouvez valider la création de la tâche. Vous ne devriez plus avoir ce problème sur vos contrôleurs de domaine Active Directory. Suite à l'exécution de la tâche, nous obtenons bien le résultat attendu.

IV. Conclusion

En suivant ces quelques étapes et en exécutant une simple ligne PowerShell sur vos contrôleurs de domaine, vous pouvez contourner ce problème récurrent. Ainsi, les firewalls de vos serveurs seront bien connectés à un réseau avec domaine, conformément à ce qu'on peut s'attendre.

Loïc VEIRMAN Spécialiste Active Directory

Auteur de Harden AD et Hello My DIR! - Spécialiste Active Directory depuis un temps certain. Également CEO de MSSec à mes heures perdues, j'aide les clients de l'entreprise à améliorer leur posture de sécurité.

Voir la bio complète