« Réseau non identifié » : réparer NLA sans roulette du Registre

Ce que « Réseau non identifié » signifie réellement (et ce que ça n’est pas)

Windows n’appose pas « Réseau non identifié » sur une interface parce qu’il est d’humeur mystérieuse. Il le fait lorsque le service Network Location Awareness (NLA, nom du service NlaSvc) ne peut pas associer avec suffisamment de confiance cette interface à un réseau connu. Le libellé de l’interface est flou ; le comportement sous-jacent ne l’est pas.

Il y a deux problèmes distincts que l’on confond :

• Réseau inconnu : NLA ne peut pas classer le réseau, donc Windows attribue la catégorie « Non identifié ». Cela force généralement le pare-feu sur le profil Public (plus restrictif).
• Réseau identifié mais mal profilé : NLA l’identifie comme un réseau, mais il est en Private/Public au lieu de Domaine. C’est un mode de défaillance différent—souvent lié à DNS/locateur de DC, pas à un « réseau inconnu ».

« Non identifié » ne signifie pas « pas de connectivité IP ». Vous pouvez avoir une IP tout à fait valide, pinguer la passerelle, même naviguer sur Internet, et être quand même « Non identifié ». NLA s’intéresse aux signaux d’identité (suffixe DNS, contrôleurs de domaine, indices 802.1X, caractéristiques de la passerelle par défaut), pas seulement au fait que des paquets circulent.

Une distinction de plus qui fait gagner des heures : la classification NLA se fait par interface. Un serveur avec plusieurs NIC (ou un adaptateur VPN) peut avoir une interface en Domaine et une autre Non identifiée — et Windows prendra des décisions de pare-feu/profil qui vous surprendront. Le multihoming transforme le « simple » en « je déteste ça ».

Comment NLA décide : signaux et mode de calcul

NLA est un classificateur. Il observe un ensemble de signaux, puis choisit une catégorie et un profil. On ne le répare pas en forçant la réponse ; on le répare en rendant les signaux cohérents et disponibles à temps.

Les signaux principaux sur lesquels NLA s’appuie

• Données fournies par DHCP : pas seulement une adresse IP, mais des options comme les serveurs DNS et le suffixe de recherche de domaine (souvent option 15). Les configurations statiques peuvent fonctionner ; les configurations statiques négligées, généralement pas.
• Configuration du client DNS : serveurs DNS spécifiques à l’interface et listes de suffixes de recherche. Si le DNS pointe vers des résolveurs publics sur une machine jointe au domaine, attendez-vous à des comportements étranges de profil.
• Accessibilité des contrôleurs de domaine : pour un profil Domaine, Windows veut localiser un DC et le valider. C’est typiquement via des enregistrements SRV et la logique du locateur de DC. Si le DNS est incorrect ou bloqué, la détection du profil Domaine échoue.
• Passerelle par défaut et table de routage : NLA s’attend à un routage sensé. Un ordre de métriques étrange, plusieurs routes par défaut, ou des portails captifs peuvent le perturber.
• Signature réseau : Windows crée et met en cache une « signature » par réseau (pensez : empreinte de la MAC de la passerelle, SSID, etc.). Quand cela change brutalement, NLA peut le traiter comme un réseau nouveau/inconnu.
• Services et temporisation : NLA dépend d’autres services. Si ces services sont désactivés, retardés ou cassés, NLA ne peut pas faire son travail au démarrage et peut retomber sur « Non identifié » jusqu’à plus tard (ou pour toujours).

Pourquoi les hacks du Registre sont si tentants — et si coûteux

Internet regorge de conseils du type « changez Category en 1 » sous une clé de profil réseau. Ce n’est pas du dépannage ; c’est réécrire l’étiquette de l’interface tout en laissant la cause sous-jacente intacte. Cela vous brûlera aussi plus tard quand le réseau changera, que le cache de profils s’agrandira, ou que la GPO attendra un profil Domaine qui n’arrive jamais.

Faites la correction ennuyeuse : restaurez le bon comportement DNS/locateur DC, assurez-vous que les dépendances sont saines, et supprimez les signatures obsolètes seulement lorsque vous avez prouvé qu’elles sont la cause.

Une idée paraphrasée d’un poids lourd de la fiabilité s’applique bien ici. Werner Vogels (idée paraphrasée) : Tout tombe en panne ; concevez et exploitez les systèmes en partant du principe que cela arrivera, et récupérez rapidement quand c’est le cas.

Playbook de diagnostic rapide

Si vous êtes pressé, ne vous égarez pas. Suivez une séquence serrée qui réduit rapidement le domaine de la panne.

Première étape : confirmez ce que Windows pense du profil

• L’interface est-elle « Non identifiée » ? Ou est-elle « Identifiée » mais bloquée en Public/Private ?
• Cela se produit-il sur une seule NIC, un adaptateur VPN ou toutes les interfaces ?

Deuxième étape : validez la cohérence IP et le routage

• Adresse IP, sous-réseau, passerelle par défaut et serveurs DNS corrects ?
• Y a-t-il exactement une route par défaut là où vous l’attendez ?

Troisième étape : validez DNS et découverte des contrôleurs de domaine

• La machine peut-elle résoudre le domaine AD et les enregistrements SRV du DC en utilisant ses serveurs DNS configurés ?
• Peut-elle atteindre les DC sur les ports requis (DNS, LDAP, Kerberos, etc.) ?

Quatrième étape : vérifiez que NLA et ses dépendances fonctionnent et ne sont pas cassés par une stratégie

• Le service NlaSvc est-il en cours d’exécution ?
• Dnscache, Dhcp, Netlogon sont-ils sains ?
• Quelque chose est-il réglé sur Disabled « pour durcir » sans comprendre l’ampleur de l’impact ?

Cinquième étape : pensez aux signatures réseau obsolètes seulement après

• La passerelle a-t-elle changé, la NIC a-t-elle été remplacée, la VM déplacée, ou le vSwitch reconstruit ?
• Si oui, effacez les profils/signatures obsolètes de façon contrôlée (pas d’éditions aléatoires du Registre).

Blague #1 : Si vous « réparez » NLA en supprimant des clés aléatoires du Registre, vous n’avez pas résolu un problème — vous en avez adopté un.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches sont ordonnées pour que vous puissiez vous arrêter quand vous trouvez la fumée. Les commandes sont montrées avec un prompt de style Linux parce que c’est un article, pas une thèse UX ; exécutez les commandes Windows dans PowerShell ou CMD selon le cas.

Task 1: See the current network profile per interface

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -AutoSize"
Name             InterfaceAlias  InterfaceIndex NetworkCategory IPv4Connectivity IPv6Connectivity
----             --------------  -------------- --------------- ---------------- ----------------
Network          Ethernet0       12             Public          Internet         NoTraffic
Unidentified net vEthernet (NIC) 25             Public          LocalNetwork     NoTraffic

Ce que cela signifie : NLA a classé les deux interfaces en Public. L’une est littéralement « Non identifiée ». Notez l’alias d’interface et l’index.

Décision : Concentrez-vous sur l’interface qui devrait être Domaine (généralement la NIC primaire). Si un vEthernet ou un adaptateur VPN est « Non identifié », il peut quand même influencer le comportement du pare-feu selon l’ordre de liaison — ne l’ignorez pas.

Task 2: Check whether Windows thinks the machine is domain-joined and which domain

cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance Win32_ComputerSystem) | Select-Object PartOfDomain, Domain"
PartOfDomain Domain
------------ ------
True         corp.example.com

Ce que cela signifie : L’ordinateur est joint au domaine. Bien. Si c’est False, le profil Domaine n’arrivera jamais.

Décision : Si la machine n’est pas jointe, arrêtez de courir après NLA. Corrigez d’abord l’adhésion/confiance au domaine.

Task 3: Validate IP addressing, gateway, DNS on the affected interface

cr0x@server:~$ ipconfig /all
Windows IP Configuration

Ethernet adapter Ethernet0:
   Connection-specific DNS Suffix  . : corp.example.com
   Description . . . . . . . . . . : Intel(R) Ethernet
   Physical Address. . . . . . . . : 00-15-5D-01-02-03
   DHCP Enabled. . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . : 10.20.30.40(Preferred)
   Subnet Mask . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . : 10.20.30.1
   DNS Servers . . . . . . . . . . : 8.8.8.8
                                       1.1.1.1

Ce que cela signifie : Le suffixe ressemble à un domaine, mais les serveurs DNS sont des résolveurs publics. Cela casse la découverte des DC et peut forcer le profil Public.

Décision : Changez les serveurs DNS pour des serveurs intégrés AD (généralement les DC) ou des résolveurs internes corrects qui peuvent répondre aux enregistrements SRV AD.

Task 4: Confirm the route table isn’t a horror show

cr0x@server:~$ route print
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.20.30.1     10.20.30.40     25
          0.0.0.0          0.0.0.0      10.99.0.1      10.99.0.20      5
===========================================================================

Ce que cela signifie : Deux routes par défaut. La métrique la plus basse gagne (métrique 5), donc le trafic sort via 10.99.0.1. Si ce réseau ne peut pas atteindre DC/DNS, NLA peut échouer à classifier.

Décision : Supprimez la passerelle par défaut non voulue, ajustez les métriques d’interface, ou ajoutez des routes spécifiques pour que le trafic domaine/DC utilise le bon chemin.

Task 5: Check NLA service health

cr0x@server:~$ powershell -NoProfile -Command "Get-Service NlaSvc | Format-List Status,StartType,Name,DisplayName"
Status    : Running
StartType : Automatic
Name      : NlaSvc
DisplayName : Network Location Awareness

Ce que cela signifie : Le service tourne. S’il est arrêté/désactivé, vous avez trouvé le coupable.

Décision : S’il est Disabled, réactivez-le. S’il ne démarre pas, inspectez les dépendances et les journaux d’événements avant de redémarrer tout sans raison.

Task 6: Check key dependency services (DNS client, DHCP, Netlogon)

cr0x@server:~$ powershell -NoProfile -Command "Get-Service Dnscache,Dhcp,Netlogon | Format-Table -AutoSize Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
Dnscache Running Automatic
Dhcp     Running Automatic
Netlogon Running Automatic

Ce que cela signifie : Si Dnscache est désactivé, vous avez un comportement DNS étrange. Si Dhcp est désactivé mais que vous dépendez de DHCP, attendez-vous à une configuration partielle. Si Netlogon est cassé, la détection du profil Domaine échoue souvent.

Décision : Restaurez des types de démarrage raisonnables (généralement Automatic). Si une baseline de durcissement les a désactivés, revenez en arrière ou adaptez-la correctement.

Task 7: Verify DNS can resolve the AD domain and DC locator SRV records

cr0x@server:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com
Server:  one.one.one.one
Address: 1.1.1.1

*** one.one.one.one can't find _ldap._tcp.dc._msdcs.corp.example.com: NXDOMAIN

Ce que cela signifie : Vous interrogez le mauvais serveur DNS. Les résolveurs publics n’hébergeront pas vos enregistrements SRV internes.

Décision : Corrigez la configuration des serveurs DNS. Puis retestez jusqu’à ce que les enregistrements SRV résolvent vers vos DC.

Task 8: Validate the DC locator from the machine’s perspective

cr0x@server:~$ nltest /dsgetdc:corp.example.com
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Ce que cela signifie : La machine ne trouve pas de DC pour le domaine (typiquement DNS mal configuré, routage ou ports bloqués).

Décision : Corrigez DNS et routage en premier. Si le DNS est correct, vérifiez les règles de pare-feu entre cet hôte et les DC.

Task 9: Inspect the Windows Firewall profile state

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallProfile | Format-Table -AutoSize Name,Enabled,DefaultInboundAction,DefaultOutboundAction"
Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain  True    Block                Allow
Private True    Block                Allow
Public  True    Block                Allow

Ce que cela signifie : Tous les profils sont activés ; c’est normal. Le problème est quel profil est actif sur la NIC.

Décision : Ne « corrigez » pas cela en désactivant le pare-feu. Réparez la détection de profil afin que les règles appropriées s’appliquent.

Task 10: Confirm which firewall profile is applied to each interface

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface | Sort-Object -Property InterfaceMetric | Select-Object -First 6 InterfaceAlias,AddressFamily,InterfaceMetric,ConnectionState | Format-Table -AutoSize"
InterfaceAlias      AddressFamily InterfaceMetric ConnectionState
--------------      ------------- -------------- ---------------
Ethernet0           IPv4          25             Connected
vEthernet (NIC)     IPv4          5              Connected

Ce que cela signifie : L’interface vEthernet a une métrique plus basse et peut être préférée pour le trafic sortant, y compris les requêtes DNS.

Décision : Si une interface de gestion/vSwitch/vNIC vole la priorité de la route par défaut, corrigez les métriques ou retirez sa passerelle.

Task 11: Check event logs for NLA classification errors

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-NlaSvc/Operational' -MaxEvents 12 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-List"
TimeCreated : 2/5/2026 9:12:11 AM
Id          : 4002
LevelDisplayName : Warning
Message     : NLA failed to retrieve the domain authentication status. Error: 0x54b

Ce que cela signifie : NLA ne peut pas récupérer le statut d’authentification du domaine. Cela renvoie souvent à Netlogon/découverte DC ou DNS.

Décision : Traitez cela comme un symptôme ; résolvez la cause en amont (DNS/atteignabilité des DC), pas le journal lui-même.

Task 12: Force DNS registration and refresh network location (safe nudges)

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.

cr0x@server:~$ ipconfig /registerdns
Windows IP Configuration
Registration of the DNS resource records for all adapters of this computer has been initiated.

Ce que cela signifie : Vous avez vidé le cache du résolveur et lancé l’enregistrement DNS dynamique.

Décision : Utilisez cela après avoir corrigé les serveurs/suffixes DNS. Cela ne réparera pas le routage cassé ou les résolveurs erronés, mais aide après correction des entrées.

Task 13: Renew DHCP (when DHCP is in play)

cr0x@server:~$ ipconfig /renew
Windows IP Configuration
Renewing Ethernet adapter Ethernet0...
Ethernet adapter Ethernet0 has been renewed.

Ce que cela signifie : Si le DHCP livrait de mauvais DNS/suffixe, cette commande récupère les options mises à jour.

Décision : Si le renouvellement donne encore des DNS publics ou un suffixe vide, corrigez les options de scope DHCP ou les réservations.

Task 14: Check if a proxy/VPN adapter is poisoning DNS

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress | Format-Table -AutoSize InterfaceAlias,AddressFamily,ServerAddresses"
InterfaceAlias        AddressFamily ServerAddresses
--------------        ------------- --------------
Ethernet0             IPv4          {10.20.30.10, 10.20.30.11}
CorpVPN               IPv4          {172.16.1.53}

Ce que cela signifie : L’interface VPN a son propre serveur DNS. Si le routage préfère le VPN, la découverte DC peut partir en vrille.

Décision : Corrigez le split DNS/split-tunnel, ajustez les métriques, ou assurez-vous que le DNS du VPN peut résoudre correctement les enregistrements AD internes.

Task 15: Test basic reachability to DNS and DC ports

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 10.20.30.10 -Port 53"
ComputerName     : 10.20.30.10
RemoteAddress    : 10.20.30.10
RemotePort       : 53
InterfaceAlias   : Ethernet0
TcpTestSucceeded : True

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection dc01.corp.example.com -Port 389"
ComputerName     : dc01.corp.example.com
RemoteAddress    : 10.20.30.10
RemotePort       : 389
InterfaceAlias   : Ethernet0
TcpTestSucceeded : True

Ce que cela signifie : DNS accessible ; LDAP accessible. Si ces tests échouent, NLA ne prouvera pas le profil « Domaine ».

Décision : Si les ports sont bloqués, corrigez les ACL réseau, les règles de pare-feu hôte, ou les routes erronées. N’attendez pas que NLA classe automatiquement un domaine qu’elle ne peut pas atteindre.

Task 16: Confirm the profile again after corrections

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-Table -AutoSize InterfaceAlias,Name,NetworkCategory"
InterfaceAlias      Name     NetworkCategory
--------------      ----     ---------------
Ethernet0           Network  DomainAuthenticated
vEthernet (NIC)     Network  Public

Ce que cela signifie : L’interface principale est maintenant DomainAuthenticated. La secondaire reste Public, ce qui peut être acceptable si c’est un vSwitch privé ou un lien isolé.

Décision : Validez que les services requis fonctionnent maintenant (supervision, WinRM, SMB, sauvegarde). Si c’est le cas, arrêtez de toucher aux réglages.

Trois mini-récits d’entreprise tirés du terrain

1) L’incident causé par une mauvaise hypothèse : « Ce n’est qu’une étiquette »

Une entreprise de taille moyenne avait des nœuds d’application Windows Server derrière un équilibreur de charge. Nuit de patch régulière. Un nœud est revenu avec « Réseau non identifié ». L’ingénieur d’astreinte a haussé les épaules — le check de santé du load balancer passait toujours, et l’application répondait localement.

Le matin, les erreurs clients ont grimpé. Pas catastrophique, juste une pluie de pannes laides. Le nœud acceptait le trafic entrant, mais ne pouvait joindre son service de licences et quelques API internes. Le profil du pare-feu était Public, et les règles sortantes pour ces destinations internes étaient limitées au Domaine.

La mauvaise hypothèse était que « Réseau non identifié » était cosmétique. Ce n’était pas le cas. Cela a modifié la politique effective du pare-feu et changé silencieusement les egress autorisés. La supervision ne l’a pas détecté car le nœud répondait toujours aux checks TCP de base ; la logique métier échouait plus loin.

Ils l’ont « réparé » rapidement en forçant le profil en Private via une modification du Registre. Ça a marché jusqu’au redémarrage suivant, puis ça a revert. C’est là qu’ils ont enfin vérifié le DNS : les serveurs DNS du nœud avaient été configurés par un script de provisioning sur des résolveurs publics comme « mesure temporaire ». Le temporaire a duré des mois, comme toujours.

Une fois les serveurs DNS pointés vers le DNS AD et le locateur DC réparé, le nœud est revenu systématiquement DomainAuthenticated. Aucun edit du Registre. L’action de suivi a même été meilleure : ils ont ajouté un contrôle de santé au démarrage dans leur gestion de configuration qui échoue si l’interface primaire n’est pas DomainAuthenticated après une période de grâce.

2) L’optimisation qui a mal tourné : « Désactiver des services pour démarrer plus vite »

Une organisation finance resserrait ses baselines. Quelqu’un a eu l’idée ingénieuse de désactiver des services « non essentiels » pour réduire le temps de démarrage et la surface d’attaque. La liste incluait le client DHCP sur les serveurs car « les serveurs sont statiques ». Elle incluait aussi Network Location Awareness parce que « on n’a pas besoin de cette UI ».

La plupart des serveurs n’ont pas remarqué immédiatement. Les IP statiques continuaient de fonctionner ; le monde tournait. Puis un cluster d’hôtes Hyper-V a commencé à signaler des échecs intermittents : des VM invitées démarraient parfois avec le mauvais profil de pare-feu, les agents de management ne pouvaient plus se connecter, et les scripts de migration à chaud échouaient de manières ressemblant à des problèmes Kerberos.

La cause racine était le timing. NLA n’était pas présent pour classifier, et le client DHCP était désactivé alors que certaines interfaces dépendaient encore de DHCP (surtout les adaptateurs virtuels créés par des outils). De plus, Netlogon démarrait en retard parce que la machine ne pouvait pas classer et prioriser la connectivité réseau au démarrage.

L’« optimisation » a économisé quelques secondes au démarrage et coûté des heures de douleur opérationnelle, plus des pannes intermittentes difficiles à corréler. La réparation a été ennuyeuse : restaurer les types de démarrage par défaut pour les services réseau de base, puis durcir en utilisant des règles de pare-feu et une segmentation appropriée, pas en supprimant la plomberie.

Ils ont conservé une partie de l’intention initiale : documenter quels services sont réellement sûrs à désactiver dans leur environnement. NLA et DHCP Client n’en faisaient pas partie.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation : « Prouver le DNS avant de toucher quoi que ce soit »

Une société globale gérait un environnement hybride : AD on-prem, workloads cloud, plusieurs solutions VPN. « Réseau non identifié » est apparu sur un ensemble de VM Windows Server après un changement réseau. Le helpdesk l’a escaladé comme un problème de pare-feu puisque le profil était Public.

L’SRE d’astreinte n’a pas commencé par la politique. Il a commencé par des preuves : Get-NetConnectionProfile, ipconfig /all, puis nslookup -type=SRV pour les enregistrements SRV AD. Cela a échoué immédiatement. Les serveurs DNS étaient corrects, mais la requête SRV a expiré. Cela a orienté l’enquête vers l’atteignabilité, pas la configuration.

Ensuite ils ont exécuté Test-NetConnection vers les DNS et les DC sur 53/389/88. Le port 53 était bloqué depuis ce sous-réseau vers le sous-réseau des DC à cause d’une nouvelle ACL visant à limiter le « bavardage serveur-à-serveur ». Personne n’avait inclus « DNS n’est pas du bavardage » dans la revue de la demande de changement.

Ils ont rollbacké l’ACL, puis la réappliquée avec des autorisations DNS explicites. NLA est revenue à DomainAuthenticated sans aucun reboot. Pas d’édition du Registre, pas de redémarrage de services, pas de « essayez d’éteindre et rallumer ». Juste une preuve méthodique que la machine ne pouvait pas atteindre la source d’identité qu’elle utilise pour décider du profil.

Cette pratique — prouver DNS et l’atteignabilité avant de tripoter — semble ennuyeuse. L’ennui, c’est bien. L’ennui, c’est ce qui sauve vos weekends.

Erreurs courantes : symptôme → cause racine → correctif

1) « Réseau non identifié » après un redémarrage sur un serveur joint au domaine

Symptôme : La NIC primaire devient Non identifiée ; le pare-feu bascule en Public ; les règles RDP/WinRM/SMB ne correspondent plus.

Cause racine : Les serveurs DNS ne pointent pas vers le DNS AD, ou les DC sont inatteignables au démarrage à cause du routage/ACL. NLA ne peut pas confirmer le statut d’authentification du domaine.

Correctif : Corrigez la liste de serveurs DNS et le suffixe ; validez les recherches SRV et nltest /dsgetdc. Puis assurez-vous que les ports vers les DC sont atteignables.

2) Le profil Domaine n’apparaît jamais, mais le réseau est « identifié » (Private/Public)

Symptôme : Le réseau affiche un nom convivial, pas « Non identifié », mais il est coincé en Private.

Cause racine : La machine est jointe au domaine mais ne peut pas localiser un DC depuis cette interface, souvent parce que la route préférée/DNS passe par une interface secondaire (VPN, vEthernet, NIC de secours).

Correctif : Supprimez les passerelles par défaut supplémentaires ; corrigez les métriques d’interface ; assurez-vous que la découverte DC utilise la NIC et les serveurs DNS prévus.

3) Seules les VM Hyper-V affichent « Non identifié » sur certains vSwitch

Symptôme : Les VM sur un vSwitch spécifique démarrent en Non identifié ; les autres sont OK.

Cause racine : Ce réseau vSwitch manque de DHCP et l’image VM attend DHCP, ou le vSwitch n’a pas de chemin vers DNS/DC. Parfois la falsification de MAC/politiques de sécurité provoquent des bizarreries.

Correctif : Assurez-vous que l’uplink du vSwitch a le bon VLAN/tagging ; vérifiez le relais DHCP ; validez l’atteignabilité DNS depuis ce segment réseau.

4) « Non identifié » apparaît après clonage ou déploiement depuis un template

Symptôme : Un serveur fraîchement déployé affiche Non identifié jusqu’à ce que quelqu’un bascule manuellement la NIC ou redémarre.

Cause racine : Le template contient des signatures réseau obsolètes et/ou des conditions de course au premier démarrage (drivers, services, GPO). L’enregistrement DNS peut aussi être en retard.

Correctif : Corrigez le template : drivers NIC corrects, ne pas livrer des DNS publics, activer les services de base, et inclure une validation post-provisionnement qui attend DomainAuthenticated avant de déclarer la réussite.

5) Utilisateurs VPN : le réseau d’entreprise devient Non identifié lorsque le VPN est actif

Symptôme : Le LAN bascule en Public après la connexion VPN ; les services internes cassent.

Cause racine : Le VPN pousse des serveurs DNS et des routes qui deviennent préférés, mais son DNS ne peut pas résoudre AD correctement, ou le VPN bloque les ports DC.

Correctif : Corrigez la conception du split-tunnel/split-DNS. Assurez-vous que le DNS du VPN peut résoudre les enregistrements SRV AD ou excluez ces requêtes vers des résolveurs internes accessibles via le VPN.

6) Quelqu’un « l’a réparé » en désactivant le profil de pare-feu

Symptôme : Les choses refonctionnent ; l’équipe sécurité panique ; l’audit le signale.

Cause racine : Traitement du symptôme (trafic bloqué) plutôt que de la cause (mauvais profil dû aux entrées NLA).

Correctif : Réactivez le pare-feu, puis réparez la classification NLA en corrigeant la découverte DNS/DC et le routage. Ajoutez des règles ciblées si un cas spécial le nécessite vraiment.

Blague #2 : Le pare-feu Windows est comme une ceinture de sécurité — il est seulement agaçant quand vous faites probablement quelque chose que vous ne devriez pas.

Listes de contrôle / plan étape par étape (corrections sûres d’abord)

Phase 0 : Décidez de ce que « correct » signifie

• Quelle interface doit être DomainAuthenticated ?
• Cet hôte doit-il être joint au domaine ? (Les serveurs ne le sont parfois pas, par conception.)
• Quels serveurs DNS doit-il utiliser ?
• Sur quel segment réseau/VLAN se trouve-t-il, et peut-il atteindre les DC depuis là ?

Phase 1 : Vérifiez et corrigez la configuration (pas de redémarrages pour l’instant)

1. Exécutez Get-NetConnectionProfile et identifiez l’interface affectée.
2. Exécutez ipconfig /all et confirmez que les serveurs DNS et le suffixe sont corrects pour le domaine.
3. Exécutez route print ; supprimez les passerelles par défaut non voulues et les erreurs de métrique évidentes.
4. Exécutez nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain> en utilisant les serveurs DNS configurés (implicitement). Corrigez le DNS si ça échoue.
5. Exécutez nltest /dsgetdc:<domain>. Si ça échoue, traitez cela comme un problème DNS/routage/pare-feu jusqu’à preuve du contraire.

Phase 2 : Prouvez l’atteignabilité vers les sources d’identité

1. Test-NetConnection vers les serveurs DNS sur le port 53.
2. Test-NetConnection vers un DC sur les ports 88 (Kerberos) et 389 (LDAP). (Vous pourriez aussi avoir besoin des ports 445/464 selon l’environnement.)
3. Si c’est bloqué, corrigez les ACL réseau ou les règles de pare-feu hôte. Ne contournez pas ; corrigez avec intention.

Phase 3 : Poussez le système (nudges à impact minimal)

1. ipconfig /flushdns et ipconfig /registerdns après les corrections DNS.
2. Si vous êtes en DHCP, ipconfig /renew après correction des options de scope.
3. Revérifiez Get-NetConnectionProfile. Si cela devient DomainAuthenticated, arrêtez.

Phase 4 : Vérifications au niveau des services (redémarrages ciblés, pas « redémarrer tout »)

1. Assurez-vous que NlaSvc, Dnscache, Dhcp, Netlogon sont Running et configurés avec des types de démarrage raisonnables.
2. Si un service est bloqué, utilisez les journaux d’événements pour comprendre pourquoi avant de le redémarrer.
3. Redémarrez uniquement si vous devez valider des problèmes d’ordre de démarrage ou si votre outil de configuration l’exige.

Phase 5 : Nettoyage contrôlé (uniquement si vous avez des preuves)

• Si le problème a commencé après un changement de passerelle/NIC/vSwitch et que tout le reste est correct, effacez les profils réseau obsolètes en utilisant des outils et des politiques supportés quand c’est possible.
• Évitez de supprimer des clés du Registre comme premier réflexe. Si vous devez toucher au Registre pour une raison connue et documentée, faites-le via un contrôle de changement et avec possibilité de retour arrière.

Faits intéressants et contexte historique (les éléments qui expliquent les bizarreries d’aujourd’hui)

1. NLA existe depuis l’ère XP/Server 2003 comme API pour que les applications réagissent aux changements réseau ; les versions ultérieures de Windows l’ont fortement liée aux profils de pare-feu.
2. Les profils de pare-feu Windows (Domaine/Private/Public) sont devenus centraux opérationnellement avec Vista/Server 2008, lorsque le pare-feu est devenu activé par défaut dans de nombreux environnements.
3. DomainAuthenticated n’est pas juste « Domaine » ; cela indique que Windows a validé la connectivité au domaine, typiquement via le locateur DC et le statut d’authentification, pas seulement un suffixe DNS.
4. AD dépend fortement des enregistrements SRV DNS pour localiser les contrôleurs de domaine et services. Si votre DNS ne peut pas répondre aux requêtes SRV, vous n’avez pas un AD « un peu cassé » — vous avez un AD cassé.
5. Le multihoming a toujours été délicat sur Windows ; plus d’interfaces signifie plus de routes, plus de listes de serveurs DNS, et plus de chances pour la « mauvaise » interface de gagner au démarrage.
6. La mobilité des VM rend les signatures réseau plus volatiles ; la migration à chaud, la reconstruction de vSwitch et les changements d’adaptateur virtuel peuvent modifier les identifiants utilisés par Windows pour fingerprint un réseau.
7. Les options DHCP comptent même dans les environnements « statiques » ; beaucoup d’organisations comptent silencieusement sur le DHCP pour le suffixe DNS/liste de recherche, les serveurs temps, ou l’attribution cohérente des serveurs DNS.
8. Les baselines de sécurité dépassent souvent les limites en désactivant des services « inutilisés ». Les services réseau de base sont rarement inutiles ; ils sont juste sous-estimés jusqu’à ce qu’ils manquent.
9. « Réseau non identifié » est souvent une histoire DNS déguisée en problème de pare-feu. L’interface vous pointe vers « réseau », mais la correction vit dans la résolution de noms et la découverte des DC.

FAQ

1) Pourquoi « Réseau non identifié » force-t-il le profil de pare-feu Public ?

Parce que Windows suppose que les réseaux inconnus sont hostiles. Public est la valeur par défaut la plus sûre. Si NLA ne peut pas prouver que c’est votre domaine ou un réseau privé connu, elle joue la défense.

2) Puis-je simplement définir le réseau en Private et passer à autre chose ?

Vous pouvez, mais vous traitez le symptôme et vous risquez de casser des règles de pare-feu scindées par domaine et des attentes de GPO. Réparez pourquoi il est non identifié — généralement la portée DNS/connexion DC ou la priorité de routage.

3) Quelle est la cause la plus fréquente sur les serveurs joints au domaine ?

Mauvais serveurs DNS. Des résolveurs publics, des paramètres DNS « temporaires », ou une interface secondaire/VPN qui gagne la priorité DNS vont casser la découverte DC et la classification NLA.

4) Si je peux pinguer le DC, pourquoi NLA ne peut-elle pas détecter le domaine ?

Ping prouve la portée ICMP, pas la résolution SRV DNS ou les ports TCP/UDP requis (53/88/389/etc.). NLA s’appuie sur des signaux de plus haut niveau que « est-ce que je peux pinguer ».

5) Dois-je redémarrer après avoir corrigé le DNS ?

Souvent non. Après correction des serveurs/suffixes et des routes, videz le cache DNS, renouvelez le DHCP si applicable, et revérifiez le profil. Redémarrez seulement si l’ordre de démarrage au boot est le vrai problème.

6) Pourquoi cela arrive-t-il après avoir déplacé une VM sur un nouvel hôte ?

Les entrées de signature réseau peuvent changer (vSwitch, visibilité MAC de la passerelle, identifiants d’adaptateur). Si la VM se retrouve aussi sur un segment qui ne peut pas joindre DNS/DC, la classification échoue immédiatement.

7) Comment savoir si c’est une panne NLA ou juste des règles de pare-feu manquantes ?

Vérifiez Get-NetConnectionProfile. Si l’interface est Public/Non identifiée alors qu’elle devrait être DomainAuthenticated, réparez les entrées NLA. Si elle est DomainAuthenticated et que le trafic est toujours bloqué, c’est alors un problème de politique de pare-feu.

8) Pourquoi certains serveurs affichent DomainAuthenticated mais se comportent comme s’ils étaient en Public ?

Généralement parce que le trafic emprunte une interface différente de celle que vous pensez (métriques/route par défaut), ou parce que les règles sont ciblées sur la mauvaise interface/profil. Vérifiez les routes et les métriques d’interface actives.

9) Désactiver NLA est-ce une mesure de durcissement valide ?

Non. Cela casse la classification réseau et peut entraîner un comportement de pare-feu imprévisible. Durcissez en définissant des politiques de pare-feu, en segmentant les réseaux et en contrôlant les services de façon intentionnelle — pas en désactivant le classificateur.

10) Et si je ne suis pas du tout sur un domaine ?

Alors « DomainAuthenticated » est sans objet. Votre objectif devient : s’assurer que l’interface est correctement identifiée et réglée en Private/Public selon votre politique, et garantir que DNS/routage sont corrects pour cet environnement.

Conclusion : prochaines étapes à faire aujourd’hui

Arrêtez de jouer aux dés dans le Registre. « Réseau non identifié » est un problème de diagnostic déguisé en problème d’interface utilisateur. Traitez-le comme un SRE : vérifiez les signaux, prouvez les dépendances, et changez une variable à la fois.

1. Auditez les paramètres des serveurs DNS sur les hôtes affectés. Si un serveur joint au domaine pointe vers un DNS public, corrigez-le en priorité.
2. Éliminez les gateways par défaut supplémentaires et nettoyez les métriques d’interface afin que la NIC prévue l’emporte.
3. Prouvez la découverte AD avec des recherches SRV et nltest. Si ça échoue, ce n’est pas un « réseau mystère », c’est un chemin d’identité cassé.
4. Validez l’atteignabilité vers les ports DNS et DC depuis l’interface préférée réelle de l’hôte.
5. Verrouillez la pratique ennuyeuse : ajoutez une vérification post-démarrage qui alerte si l’interface primaire n’est pas DomainAuthenticated dans un délai raisonnable.

Si vous ne faites qu’une chose : rendez le DNS de nouveau ennuyeux. NLA adore l’ennui. Votre rotation d’astreinte aussi.