«Red no identificada»: soluciona NLA sin jugar a la ruleta del registro

Qué significa realmente “Red no identificada” (y qué no significa)

Windows no etiqueta una interfaz como “Red no identificada” porque le parezca misteriosa. Lo hace cuando el servicio Network Location Awareness (NLA, nombre del servicio NlaSvc) no puede asociar con suficiente confianza esa interfaz a una red conocida. El texto de la interfaz es difuso; el comportamiento subyacente no lo es.

Hay dos problemas distintos que la gente confunde:

• La red es desconocida: NLA no puede clasificar la red, así que Windows asigna la categoría “No identificada”. Eso normalmente fuerza el firewall al perfil Público (más restrictivo).
• La red está identificada pero mal perfila: NLA la identifica como una red, pero queda en Privada/Pública en lugar de Dominio. Ese es un modo de fallo distinto—a menudo es un problema de DNS/descubrimiento de DC, no de “red desconocida”.

“No identificada” no significa “sin conectividad IP”. Puedes tener una IP válida, hacer ping al gateway e incluso navegar por Internet y aun así aparecer como “No identificada”. A NLA le importan las señales de identidad (sufijo DNS, controladores de dominio, pistas 802.1X, características del gateway por defecto), no solo que los paquetes se transmitan.

Una distinción más que ahorra horas: la clasificación de NLA ocurre por interfaz. Un servidor con múltiples NICs (o un adaptador VPN) puede tener una interfaz en Dominio y otra como No identificada—y Windows tomará decisiones de firewall/perfil que te sorprenderán. El multihoming convierte lo “simple” en “odio esto”.

Cómo decide NLA: las señales y la lógica

NLA es un clasificador. Observa un conjunto de señales y luego elige una categoría y un perfil. No lo arreglas forzando la respuesta; lo arreglas haciendo que las señales sean consistentes y oportunas.

Las señales clave en las que confía NLA

• Datos proporcionados por DHCP: no solo una dirección IP, sino opciones como servidores DNS y sufijo de búsqueda/dominio (a menudo la opción 15). Las configuraciones estáticas pueden funcionar; las configuraciones estáticas descuidadas normalmente no.
• Configuración del cliente DNS: servidores DNS específicos por interfaz y listas de sufijos de búsqueda. Si el DNS apunta a “resolvers públicos” en una máquina unida al dominio, espera comportamiento extraño del perfil.
• Capacidad de alcanzar controladores de dominio: para el perfil Dominio, Windows quiere localizar un DC y validarlo. Eso suele hacerse vía registros SRV y la lógica del localizador de DC. Si el DNS está mal o bloqueado, la detección del perfil Dominio falla.
• Gateway por defecto y tabla de rutas: NLA espera un enrutamiento sensato. Ordenación extraña de métricas, múltiples rutas por defecto o gateways cautivos pueden confundirlo.
• Firma de red: Windows crea y guarda en caché una “firma” por red (piensa: huella del MAC del gateway, SSID, etc.). Cuando eso cambia abruptamente, NLA puede tratarla como nueva/desconocida.
• Servicios y temporización: NLA depende de otros servicios. Si esos servicios están deshabilitados, retrasados o rotos, NLA no puede hacer su trabajo al arrancar y puede caer en “No identificada” hasta más tarde (o para siempre).

Por qué los hacks del registro son tan tentadores—y tan costosos

Internet está lleno de consejos como “cambia Category a 1” bajo alguna clave de perfil de red. Eso no es resolver el problema; es reescribir la etiqueta de la interfaz dejando la causa subyacente intacta. Además te perjudica después cuando la red cambia, la caché de perfiles crece o la Directiva de Grupo espera un perfil Dominio que nunca llega.

Haz la reparación aburrida: restaura el comportamiento correcto de DNS/localizador de DC, asegura que las dependencias estén sanas y limpia firmas obsoletas solo cuando hayas demostrado que son la causa.

Una idea parafraseada de un referente en fiabilidad encaja aquí. Werner Vogels (idea parafraseada): Todo falla; diseña y opera sistemas asumiendo que fallarán, y recupéralos rápido cuando lo hagan.

Guía rápida de diagnóstico

Si vas contrarreloj, no te disperses. Sigue una secuencia estricta que reduzca rápidamente el dominio de fallo.

Primero: confirma qué piensa Windows sobre el perfil

• ¿La interfaz está “No identificada”? ¿O está “Identificada” pero atascada en Público/Privado?
• ¿Esto ocurre en una NIC, en un adaptador VPN o en todas las interfaces?

Segundo: valida la sanidad de IP y enrutamiento

• ¿Dirección IP, subred, gateway por defecto y servidores DNS correctos?
• ¿Hay exactamente una ruta por defecto donde la esperas?

Tercero: valida DNS y descubrimiento de controladores de dominio

• ¿La máquina puede resolver el dominio AD y los registros SRV de DC usando sus servidores DNS configurados?
• ¿Puede alcanzar los DCs en los puertos requeridos (DNS, LDAP, Kerberos, etc.)?

Cuarto: comprueba que NLA y sus dependencias estén en ejecución y no rotas por políticas

• ¿Está NlaSvc en ejecución?
• ¿Están Dnscache, Dhcp, Netlogon saludables?
• ¿Algo está puesto en Disabled “por endurecimiento” sin entender el alcance del impacto?

Quinto: solo entonces considera firmas de red obsoletas

• ¿El gateway cambió, se cambió la NIC, se movió la VM o se reconstruyó el vSwitch del hipervisor?
• Si la respuesta es sí, limpia los perfiles/firmas obsoletas de forma controlada (no edits aleatorios del registro).

Broma #1: Si “arreglas” NLA borrando claves aleatorias del registro, no has resuelto un problema—has adoptado uno.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas están ordenadas para que puedas parar cuando encuentres la pistola humeante. Los comandos se muestran con un prompt estilo Linux porque esto es un artículo, no una tesis de UX; ejecuta los comandos de Windows en PowerShell o CMD según corresponda.

Tarea 1: Ver el perfil de red actual por interfaz

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

Qué significa: NLA clasificó ambas interfaces como Públicas. Una está literalmente “No identificada”. Observa el alias e índice de la interfaz.

Decisión: Céntrate en la interfaz que debería ser Dominio (normalmente la NIC principal). Si un vEthernet o adaptador VPN está “No identificado”, aún puede influir en el comportamiento del firewall dependiendo del orden de enlace—no lo ignores.

Tarea 2: Comprobar si Windows piensa que la máquina está unida al dominio y a qué dominio

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

Qué significa: ParteDelDominio es True. Bien. Si es falso, el perfil Dominio nunca ocurrirá.

Decisión: Si no está unido al dominio, deja de perseguir a NLA. Arregla la unión/confianza primero.

Tarea 3: Validar direccionamiento IP, gateway y DNS en la interfaz afectada

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

Qué significa: El sufijo parece de dominio, pero los servidores DNS son resolvers públicos. Eso rompe el descubrimiento de DC y puede forzar el perfil Público.

Decisión: Cambia los servidores DNS a DNS integrados con AD (normalmente los DCs) o corrige los resolvers internos que puedan responder a registros SRV de AD.

Tarea 4: Confirmar que la tabla de rutas no sea un espectáculo de horror

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
===========================================================================

Qué significa: Dos rutas por defecto. La métrica menor gana (métrica 5), por lo que el tráfico sale por 10.99.0.1. Si esa red no puede llegar a DC/DNS, NLA puede fallar en la clasificación.

Decisión: Elimina el gateway por defecto no intencionado, ajusta métricas de interfaz o añade rutas específicas para que el tráfico de dominio/DC use la ruta correcta.

Tarea 5: Comprobar la salud del servicio NLA

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

Qué significa: El servicio está en ejecución. Si está detenido/deshabilitado, has encontrado al culpable.

Decisión: Si está deshabilitado, vuelve a habilitarlo. Si no arranca, inspecciona dependencias y los registros de eventos antes de reiniciar todo a ciegas.

Tarea 6: Comprobar servicios dependientes clave (cliente DNS, 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

Qué significa: Si Dnscache está deshabilitado, obtendrás comportamiento DNS extraño. Si Dhcp está deshabilitado pero dependes de DHCP, espera una configuración parcial. Si Netlogon está roto, la detección del perfil Dominio suele fallar.

Decisión: Restaura tipos de inicio sensatos (normalmente Automatic). Si una base de endurecimiento los deshabilitó, revierte o enmienda correctamente la política.

Tarea 7: Verificar que DNS pueda resolver el dominio AD y los registros SRV del localizador de DC

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

Qué significa: Estás consultando al servidor DNS equivocado. Los resolvers públicos no contendrán tus registros SRV internos.

Decisión: Corrige la configuración de servidores DNS. Luego vuelve a probar hasta que los registros SRV resuelvan a tus DCs.

Tarea 8: Validar el localizador de DC desde la perspectiva de la máquina

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

Qué significa: La máquina no puede encontrar un DC para el dominio (comúnmente DNS mal configurado, enrutamiento o puertos bloqueados).

Decisión: Arregla DNS y enrutamiento primero. Si DNS es correcto, comprueba reglas de firewall entre este host y los DCs.

Tarea 9: Inspeccionar el estado de los perfiles del firewall de Windows

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

Qué significa: Todos los perfiles están habilitados; eso es normal. El problema es qué perfil está activo en la NIC.

Decisión: No “arregles” esto deshabilitando el firewall. Arregla la detección del perfil para que las reglas correctas se apliquen.

Tarea 10: Confirmar qué perfil de firewall se aplica a cada interfaz

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

Qué significa: La interfaz vEthernet tiene menor métrica y puede ser preferida para tráfico saliente, incluidas consultas DNS.

Decisión: Si una interfaz de gestión/vSwitch/vNIC está robando prioridad de la ruta por defecto, corrige las métricas o quita su gateway.

Tarea 11: Revisar los registros de eventos por errores de clasificación de NLA

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

Qué significa: NLA no puede recuperar el estado de autenticación de dominio. A menudo se relaciona con Netlogon/descubrimiento de DC o DNS.

Decisión: Trata esto como un síntoma; resuelve la causa upstream (alcanzabilidad DNS/DC), no el registro en sí.

Tarea 12: Forzar el registro DNS y refrescar la ubicación de red (empujones seguros)

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.

Qué significa: Has limpiado la caché del resolvedor e iniciado el registro DNS dinámico.

Decisión: Usa esto después de corregir servidores/sufijos DNS. No arreglará enrutamiento roto o resolvedores erróneos, pero ayuda tras corregir las entradas.

Tarea 13: Renovar DHCP (cuando DHCP está en juego)

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

Qué significa: Si DHCP estaba entregando DNS/sufijo incorrecto, esto obtendrá las opciones actualizadas.

Decisión: Si la renovación sigue dando DNS públicos o sufijo en blanco, arregla las opciones del ámbito DHCP o las reservas.

Tarea 14: Comprobar si un proxy/adaptador VPN está envenenando el 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}

Qué significa: La interfaz VPN tiene su propio servidor DNS. Si el enrutamiento prefiere la VPN, el descubrimiento de DC puede torcerse.

Decisión: Corrige el diseño de split DNS/split tunnel, ajusta métricas o asegura que el DNS de la VPN pueda resolver registros AD internamente.

Tarea 15: Probar conectividad básica a DNS y puertos de DC

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

Qué significa: DNS accesible; LDAP accesible. Si esto falla, NLA puede no demostrar “Red de dominio”.

Decisión: Si está bloqueado, arregla ACLs de red, reglas de firewall del host o rutas erróneas. No esperes que NLA clasifique mágicamente un dominio al que no puede llegar.

Tarea 16: Confirmar el perfil de nuevo tras las correcciones

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

Qué significa: La interfaz principal ahora es DomainAuthenticated. La secundaria sigue en Público, lo cual puede estar bien si es un vSwitch privado o un enlace aislado.

Decisión: Valida que los servicios requeridos funcionen ahora (monitorización, WinRM, SMB, backup). Si funcionan, deja de tocar cosas.

Tres mini-historias corporativas desde el terreno

1) El incidente causado por una suposición errónea: “Es solo una etiqueta”

Una empresa mediana tenía un conjunto de nodos de aplicación Windows detrás de un balanceador de carga. Noche de parches rutinarios. Un nodo volvió con “Red no identificada”. El ingeniero de guardia se encogió de hombros—el balanceador seguía marcando bien la salud y la aplicación respondía localmente.

A la mañana, los errores de clientes aumentaron. No fue catastrófico, solo una lluvia de fallos feos. El nodo podía aceptar tráfico entrante, pero no alcanzaba su servicio de licencias ni un par de APIs internas. El perfil del firewall era Público y las reglas de salida para esos destinos internos estaban limitadas al Dominio.

La suposición errónea fue que “Red no identificada” era cosmética. No lo era. Cambió la política efectiva del firewall y silenciosamente alteró los permisos de salida. La monitorización no lo detectó porque el nodo seguía respondiendo a comprobaciones TCP básicas; la lógica del negocio fallaba después.

Lo “arreglaron” rápidamente forzando el perfil a Privado mediante un cambio en el registro. Funcionó hasta el siguiente reinicio, luego revirtió. Ahí fue cuando finalmente comprobaron el DNS: los servidores DNS del nodo los había puesto un script de aprovisionamiento a resolvers públicos como “medida temporal”. Lo temporal duró meses, como suele ocurrir.

Una vez que los servidores DNS apuntaron al DNS de AD y el localizador de DC funcionó, el nodo arrancó consistentemente como DomainAuthenticated. Sin ediciones en el registro. La acción de seguimiento fue incluso mejor: añadieron una comprobación en el arranque en su gestión de configuración que falla la construcción si la interfaz primaria no es DomainAuthenticated tras un periodo de gracia.

2) La optimización que salió mal: “Deshabilitar servicios para arrancar más rápido”

Una organización financiera estaba apretando sus baselines. Alguien tuvo la idea de deshabilitar servicios “no esenciales” para reducir el tiempo de arranque y la superficie de ataque. La lista incluía Cliente DHCP en servidores porque “los servidores son estáticos”. También incluyeron Network Location Awareness porque “no necesitamos esa interfaz”.

La mayoría de servidores no lo notaron de inmediato. Las IPs estáticas seguían funcionando; el mundo siguió girando. Luego un cluster de hosts Hyper-V empezó a reportar fallos intermitentes: las VMs invitadas a veces arrancaban en el perfil de firewall equivocado, agentes de gestión no podían conectarse y scripts de migración en vivo fallaban en modos que parecían problemas de Kerberos.

La causa raíz fue la temporización. NLA no estaba para clasificar, y Cliente DHCP estaba deshabilitado aunque algunas interfaces aún dependían de DHCP (especialmente adaptadores virtuales creados por herramientas). Además, Netlogon tenía un arranque retrasado porque la máquina no podía clasificar y priorizar confiablemente la conectividad de red durante el arranque.

La “optimización” ahorró unos segundos en el arranque y costó horas de dolor operativo, además de interrupciones intermitentes difíciles de correlacionar. La solución fue aburrida: restaurar los tipos de inicio por defecto para servicios de red esenciales y luego endurecer usando reglas de firewall y segmentación adecuada, no arrancando la fontanería.

Mantuvieron una parte de la intención original: documentaron qué servicios son realmente seguros para deshabilitar en su entorno. NLA y Cliente DHCP no estaban en la lista.

3) La práctica aburrida pero correcta que salvó el día: “Demuestra DNS antes de tocar nada”

Una compañía global operaba un entorno híbrido: AD on-prem, cargas en la nube y múltiples soluciones VPN. “Red no identificada” apareció en un conjunto de VMs Windows tras un cambio de red. Mesa de ayuda lo escaló como un problema de firewall porque el perfil era Público.

El SRE de guardia no empezó con políticas. Empezó con evidencia: Get-NetConnectionProfile, ipconfig /all, luego nslookup -type=SRV para los registros SRV de AD. Falló de inmediato. Los servidores DNS eran correctos, pero la consulta SRV agotó el tiempo. Eso lo redujo a alcanzabilidad, no a configuración.

Después ejecutaron Test-NetConnection hacia DNS y hacia los DCs en 53/389/88. El puerto 53 estaba bloqueado desde esa subred hacia la subred de DC por una nueva ACL destinada a limitar “charla servidor-a-servidor”. Nadie había incluido “DNS no es charla” en la revisión del cambio.

Revirtieron la ACL y luego la volvieron a aplicar con permisos explícitos para DNS. NLA volvió a DomainAuthenticated sin reinicios. Sin ediciones del registro, sin reinicios de servicios, sin “prueba encender/apagar”. Solo una prueba metódica de que la máquina no podía alcanzar la fuente de identidad que usa para decidir el perfil.

Esa práctica—demostrar DNS y alcanzabilidad antes de trastear—suena aburrida. Aburrido es bueno. Aburrido es cómo salvas fines de semana.

Errores comunes: síntoma → causa raíz → solución

1) “Red no identificada” tras reinicio en un servidor unido al dominio

Síntoma: La NIC primaria pasa a No identificada; el firewall cambia a Público; RDP/WinRM/SMB dejan de coincidir.

Causa raíz: Servidores DNS que no apuntan al DNS de AD, o DC inaccesible durante el arranque por enrutamiento/ACLs. NLA no puede confirmar el estado de autenticación de dominio.

Solución: Corrige la lista de servidores DNS y el sufijo; valida búsquedas SRV y nltest /dsgetdc. Luego asegura que los puertos hacia los DCs sean alcanzables.

2) El perfil Dominio nunca aparece, pero la red está “identificada” (Privada/Pública)

Síntoma: La red muestra un nombre amistoso, no “No identificada”, pero está atascada en Privada.

Causa raíz: La máquina está unida al dominio pero no puede localizar un DC desde esa interfaz, a menudo porque la ruta/DNS preferida va por una interfaz secundaria (VPN, vEthernet, NIC de respaldo).

Solución: Elimina gateways por defecto extra; corrige métricas de interfaz; asegura que el descubrimiento de DC use la NIC y los servidores DNS previstos.

3) Solo las guests de Hyper-V muestran “No identificada” en ciertos vSwitches

Síntoma: VMs en un vSwitch específico arrancan en No identificada; otras están bien.

Causa raíz: Ese vSwitch carece de DHCP y la imagen de VM espera DHCP, o el vSwitch no tiene camino a DNS/DC. A veces el MAC spoofing/políticas de seguridad causan rarezas.

Solución: Asegura que el uplink del vSwitch tenga VLAN/tagging correcto; verifica relay DHCP; valida la alcanzabilidad DNS desde ese segmento de red.

4) “No identificada” aparece después de clonar o desplegar desde plantilla

Síntoma: Servidor recién desplegado muestra No identificada hasta que alguien togglea la NIC o reinicia.

Causa raíz: La plantilla tiene firmas de red obsoletas y/o condiciones de carrera en el primer arranque (drivers, servicios, GPO). El registro DNS también puede retrasarse.

Solución: Corrige la plantilla: drivers de NIC correctos, no incluir DNS públicos, asegurar que servicios clave estén habilitados e incluir una validación post-provisión que espere a DomainAuthenticated antes de declarar éxito.

5) Usuarios VPN: la red corporativa queda No identificada cuando la VPN está activa

Síntoma: La LAN pasa a Público tras conectar la VPN; servicios internos fallan.

Causa raíz: La VPN empuja servidores DNS y rutas que se prefieren, pero su DNS no resuelve AD correctamente, o la VPN bloquea puertos de DC.

Solución: Corrige el diseño de split-tunnel/split-DNS. Asegura que el DNS de la VPN pueda resolver registros SRV de AD o excluye esas consultas a resolvers internos alcanzables vía VPN.

6) Alguien “lo arregló” deshabilitando el perfil del firewall

Síntoma: Las cosas vuelven a funcionar; el equipo de seguridad entra en pánico; auditoría lo marca.

Causa raíz: Tratar el síntoma (tráfico bloqueado) en lugar de la causa (perfil equivocado debido a entradas de NLA).

Solución: Vuelve a habilitar el firewall, luego arregla la clasificación de NLA reparando DNS/descubrimiento de DC y enrutamiento. Añade reglas específicas si realmente hace falta un caso especial.

Broma #2: El firewall de Windows es como un cinturón de seguridad—molesto solo cuando estás haciendo algo que probablemente no deberías.

Listas de verificación / plan paso a paso (primero correcciones seguras)

Fase 0: Decide cómo debe ser lo “correcto”

• ¿Qué interfaz debería ser DomainAuthenticated?
• ¿Se supone que este host esté unido al dominio? (A veces los servidores no lo están, por diseño.)
• ¿Qué servidores DNS debe usar?
• ¿En qué segmento de red/VLAN está y puede alcanzar DCs desde ahí?

Fase 1: Verifica y corrige la configuración (sin reinicios aún)

1. Ejecuta Get-NetConnectionProfile e identifica la interfaz afectada.
2. Ejecuta ipconfig /all y confirma que servidores DNS y sufijo son correctos para el dominio.
3. Ejecuta route print; elimina gateways por defecto no intencionados y errores obvios de métricas.
4. Ejecuta nslookup -type=SRV _ldap._tcp.dc._msdcs.<domain> usando los servidores DNS configurados (implícitamente). Si falla, arregla DNS.
5. Ejecuta nltest /dsgetdc:<domain>. Si falla, trátalo como DNS/enrutamiento/firewall hasta demostrar lo contrario.

Fase 2: Demuestra alcanzabilidad a las fuentes de identidad

1. Test-NetConnection a servidores DNS en el puerto 53.
2. Test-NetConnection a un DC en los puertos 88 (Kerberos) y 389 (LDAP). (También podrías necesitar 445/464 según el entorno.)
3. Si está bloqueado, arregla ACLs de red o reglas de firewall del host. No eludas; enruta con intención.

Fase 3: Empuja al sistema (perturbación mínima)

1. ipconfig /flushdns y ipconfig /registerdns tras correcciones DNS.
2. Si usas DHCP, ipconfig /renew después de arreglar opciones del ámbito.
3. Revisa Get-NetConnectionProfile. Si pasa a DomainAuthenticated, detente.

Fase 4: Comprobaciones a nivel de servicio (reinicios dirigidos, no “reinicia todo”)

1. Asegura que NlaSvc, Dnscache, Dhcp, Netlogon estén Running y con tipos de inicio sanos.
2. Si un servicio está atascado, usa los registros de eventos para entender por qué antes de reiniciarlo.
3. Sólo reinicia si necesitas validar problemas de orden de arranque o si la herramienta de configuración lo requiere.

Fase 5: Limpieza controlada (solo si tienes evidencia)

• Si el problema empezó tras un cambio en gateway/NIC/vSwitch y todo lo demás es correcto, borra perfiles de red obsoletos usando herramientas y políticas soportadas cuando sea posible.
• Evita eliminar claves del registro como primer movimiento. Si debes tocar el registro por una razón conocida y documentada, hazlo mediante control de cambios y con rollback.

Datos interesantes y contexto histórico (lo que explica las rarezas actuales)

1. NLA existe desde la era XP/Server 2003 como una API para que las aplicaciones respondan a cambios de red; en versiones posteriores de Windows se ató fuertemente a los perfiles de firewall.
2. Los perfiles de firewall de Windows (Dominio/Privado/Público) se volvieron operativamente centrales con Vista/Server 2008, cuando el firewall maduró hacia una postura activada por defecto en muchos entornos.
3. DomainAuthenticated no es solo “Dominio”; indica que Windows validó la conectividad de dominio, típicamente vía localizador de DC y estado de autenticación, no simplemente una coincidencia de sufijo DNS.
4. AD depende en gran medida de los registros SRV DNS para localizar controladores de dominio y servicios. Si tu DNS no responde consultas SRV, no tienes “AD algo roto”—tienes AD roto.
5. El multihoming siempre ha sido complejo en Windows; más interfaces significan más rutas, más listas de servidores DNS y más posibilidades de que la interfaz “incorrecta” gane durante el arranque.
6. La movilidad de VMs hizo las firmas de red más volátiles; migraciones en caliente, reconstrucciones de vSwitch y cambios de NIC virtual pueden alterar los identificadores que Windows usa para huellas de red.
7. Las opciones DHCP importan incluso en entornos “estáticos”; muchas organizaciones dependen silenciosamente de DHCP para sufijos DNS, servidores de tiempo o asignación consistente de servidores DNS.
8. Las baselines de seguridad a menudo exceden deshabilitando servicios “no usados”. Los servicios de red centrales rara vez están sin usar; simplemente se subestiman hasta que faltan.
9. “Red no identificada” suele ser una historia de DNS disfrazada de problema de firewall. La interfaz te apunta a “red”, pero la solución vive en la resolución de nombres y el descubrimiento de DC.

Preguntas frecuentes

1) ¿Por qué “Red no identificada” fuerza el perfil Público del firewall?

Porque Windows asume que redes desconocidas son hostiles. Público es la opción más segura por defecto. Si NLA no puede probar que es tu dominio o una red privada conocida, actúa a la defensiva.

2) ¿Puedo simplemente poner la red en Privado y listo?

Puedes, pero estás tratando el síntoma y podrías romper reglas de firewall y expectativas de GPO orientadas al dominio. Arregla por qué está no identificada—normalmente alcanzabilidad DNS/DC o prioridad de enrutamiento.

3) ¿Cuál es la causa más común en servidores unidos al dominio?

Servidores DNS incorrectos. Resolvers públicos, ajustes “temporales” de DNS o una NIC/VPN secundaria ganando precedencia DNS arruinarán el descubrimiento de DC y la clasificación de NLA.

4) Si puedo hacer ping al DC, ¿por qué NLA no detecta el dominio?

Ping demuestra alcanzabilidad ICMP, no resolución SRV ni puertos TCP/UDP requeridos (53/88/389/etc.). NLA se basa en señales de nivel superior más allá de “puedo hacer ping”.

5) ¿Necesito reiniciar después de arreglar DNS?

A menudo no. Tras corregir servidores/sufijos DNS y rutas, vacía la caché DNS, renueva DHCP si aplica y vuelve a comprobar el perfil. Reinicia solo si el problema es el orden de arranque real.

6) ¿Por qué ocurre esto después de mover una VM a un nuevo host?

Las entradas de firma de red pueden cambiar (vSwitch, visibilidad del MAC del gateway, identificadores del adaptador). Si la VM además cae en un segmento que no puede alcanzar DNS/DC, la clasificación falla de inmediato.

7) ¿Cómo sé si esto es una falla de NLA o simplemente reglas de firewall faltantes?

Revisa Get-NetConnectionProfile. Si la interfaz aparece Pública/No identificada cuando debería ser DomainAuthenticated, arregla las entradas de NLA. Si es DomainAuthenticated y el tráfico sigue bloqueado, entonces es un problema de política de firewall.

8) ¿Por qué algunos servidores muestran DomainAuthenticated pero aún se comportan como Públicos?

Generalmente porque el tráfico fluye por otra interfaz distinta a la que crees (métricas/ruta por defecto), o porque las reglas están limitadas al perfil/ interfaz incorrecta. Verifica rutas y métricas de interfaz activas.

9) ¿Deshabilitar NLA es una medida de endurecimiento válida?

No. Rompe la clasificación de red y puede conducir a comportamientos impredecibles del firewall. Endurece definiendo políticas de firewall, segmentando redes y controlando servicios con intención—no deshabilitando el clasificador.

10) ¿Y si no estoy en un dominio en absoluto?

Entonces “DomainAuthenticated” es irrelevante. Tu objetivo se convierte en: asegurar que la interfaz esté correctamente identificada y configurada como Privada/Pública según tu política, y garantizar que DNS/enrutamiento sean correctos para ese entorno.

Conclusión: próximos pasos que puedes hacer hoy

Deja de tirar los dados con el registro. “Red no identificada” es un problema de diagnóstico disfrazado de problema de interfaz. Trátalo como lo haría un SRE: verifica señales, demuestra dependencias y cambia una variable a la vez.

1. Audita la configuración de servidores DNS en los hosts afectados. Si un servidor unido al dominio apunta a DNS públicos, corrígelo primero.
2. Elimina gateways por defecto extra y limpia métricas de interfaz para que la NIC prevista gane.
3. Demuestra el descubrimiento de AD con búsquedas SRV y nltest. Si fallan, no es “red misteriosa”, es una ruta de identidad rota.
4. Valida la alcanzabilidad a DNS y a puertos de DC desde la interfaz preferida del host.
5. Fija la práctica aburrida: añade una comprobación post-arranque que alerte cuando la interfaz primaria no sea DomainAuthenticated dentro de un periodo razonable.

Si haces una sola cosa: haz que DNS vuelva a ser aburrido. A NLA le encanta lo aburrido. A tu rotación de guardia también.