Problema

En entornos con controladores de dominio que también actúan como servidores DNS, es frecuente que una actualización del sistema operativo altere la interacción entre ambos servicios. El síntoma típico es que los usuarios reciben prompts de credenciales al intentar acceder a recursos compartidos, mientras que los administradores locales pueden iniciar sesión pero quedan bloqueados al abrir la consola DNS o ejecutar cmdlets de PowerShell relacionados con DNS. El servicio DNS sigue resolviendo nombres y los controladores de dominio aparecen “up”, pero la capa de autorización falla. Este patrón suele aparecer justo después de aplicar un paquete de actualización (por ejemplo, KB5122882) que incluye cambios en el código de DNS o en los componentes de seguridad de AD.

Causa

Varias causas pueden generar este tipo de bloqueo:

  1. Modificación de ACLs del objeto DNS
    Algunas actualizaciones reescriben los permisos predeterminados del contenedor MicrosoftDNS en AD, eliminando la membresía de Domain Admins o Enterprise Admins en la lista de control de acceso (ACL). Cuando la ACL está incompleta, los intentos de gestión a través de la MMC o PowerShell devuelven Access Denied.

  2. Cambios en la política de seguridad local
    Un paquete de seguridad puede activar la política Network security: Restrict NTLM: Outgoing NTLM traffic o endurecer la política Authentication Packages. El resultado es que los procesos del servidor DNS ya no pueden delegar credenciales hacia el controlador de dominio, provocando fallos de autenticación en operaciones que requieren Kerberos.

  3. Corruptela del almacén de componentes de DNS
    La actualización puede interrumpir la instalación del rol DNS, dejando archivos DLL o registros del sistema en estado inconsistente. En ese caso, el servicio sigue funcionando para consultas, pero la API de administración queda inutilizable.

  4. Problemas de replicación de AD
    Si la actualización se aplica solo a un controlador y la replicación falla, los cambios de ACL pueden quedar “a medias”, generando un estado donde algunos controladores aceptan la gestión y otros no.

  5. Vulnerabilidad CVE‑2026‑69813
    La referencia a Rapid7 indica que la actualización abordó una vulnerabilidad que involucraba código DNS. En algunos entornos, la mitigación introducida por el parche altera los permisos de objetos críticos para evitar la explotación, colapsando la administración legítima.

Solución

Una estrategia robusta combina diagnóstico rápido, reversión controlada y reparación de permisos. Los pasos siguientes funcionan tanto si el problema se originó por una actualización reciente como si la causa es una ACL corrupta.

1. Confirmar que la actualización es la culpable

wmic qfe list brief /format:table | findstr /i "KB5122882"

Si el paquete aparece en la lista y el fallo coincidió con su instalación, procede con el rollback; de lo contrario, salta al paso 3.

2. Desinstalar la actualización problemáica

dism /online /remove-package /packagename:KB5122882

Reinicia el servidor y verifica si la consola DNS vuelve a abrirse. Si el problema persiste, continúa.

3. Restaurar ACLs del contenedor DNS

Ejecuta desde un DC con privilegios de Enterprise Admin:

Import-Module ActiveDirectory
$dnsContainer = "CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com"
$adminSid = (Get-ADUser -Identity "Administrator").SID.Value
$acl = Get-ACL "AD:$dnsContainer"
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($adminSid,"GenericAll","Allow")
$acl.AddAccessRule($ace)
Set-ACL -Path "AD:$dnsContainer" -AclObject $acl

Reemplaza contoso.com por tu dominio. Este comando asegura que el administrador tenga control total sobre el contenedor DNS.

4. Verificar y, si es necesario, restablecer políticas de seguridad

Abre secpol.msc → Políticas locales → Opciones de seguridad. Busca:

  • Network security: Restrict NTLM: Outgoing NTLM traffic → Disabled (solo temporalmente para pruebas).
  • Network security: LAN Manager authentication level → Send NTLMv2 response only. Refuse LM & NTLM (valor recomendado).

Si modificas alguna, ejecuta gpupdate /force y reinicia los servicios DNS/AD.

5. Reparar la instalación del rol DNS

dism /online /disable-feature /featurename:DNS-Server-Core
dism /online /enable-feature /featurename:DNS-Server-Core /all

Esto desinstala y reinstala el rol sin tocar la configuración de zona.

6. Forzar replicación y validar integridad de AD

repadmin /syncall /AdeP
dcdiag /test:DNS /v /c /d /e > C:\temp\dcdiag_dns.txt

Revisa el log en busca de errores de replicación o de permisos.

7. Si todo falla, usar el modo de reparación de AD (DSRM)

Arranca en modo de reparación de directorio, restaura desde backup o ejecuta ntdsutil para reparar el árbol de AD. Este paso es extremo y solo se recurre cuando los intentos anteriores no devuelven la operatividad.

Cuándo aplicar esta solución

  • Síntomas: prompts de credenciales en recursos compartidos, Access Denied al abrir DNS MMC o ejecutar Get-DnsServer*, pero consultas DNS siguen funcionando.
  • Entorno: controladores de dominio con rol DNS instalado, actualización reciente (últimos 24‑48 h).
  • Exclusiones: si la falla ocurre en un controlador que no recibió la actualización, o si los logs indican problemas de hardware/networking, la solución de rollback y ACL no será suficiente.

Código

# Verificar presencia del KB problemático
wmic qfe list brief /format:table | findstr /i "KB5122882"

# Desinstalar el KB
dism /online /remove-package /packagename:KB5122882

# Restaurar ACL del contenedor DNS
Import-Module ActiveDirectory
$dnsContainer = "CN=MicrosoftDNS,DC=DomainDnsZones,DC=contoso,DC=com"
$adminSid = (Get-ADUser -Identity "Administrator").SID.Value
$acl = Get-ACL "AD:$dnsContainer"
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($adminSid,"GenericAll","Allow")
$acl.AddAccessRule($ace)
Set-ACL -Path "AD:$dnsContainer" -AclObject $acl

# Reinstalar rol DNS
dism /online /disable-feature /featurename:DNS-Server-Core
dism /online /enable-feature /featurename:DNS-Server-Core /all

# Forzar replicación y diagnosticar DNS
repadmin /syncall /AdeP
dcdiag /test:DNS /v /c /d /e > C:\temp\dcdiag_dns.txt

Verificación

  1. Consola DNS: abre dnsmgmt.msc. Si carga sin error, la ACL está correcta.
  2. PowerShell: ejecuta Get-DnsServerZone. La salida debe listar todas las zonas sin AccessDenied.
  3. Acceso a recursos: prueba abrir una carpeta compartida o un mapeo de unidad. No debería aparecer el prompt de credenciales.
  4. Logs de eventos: revisa System y DNS Server en el Visor de eventos; ausencia de eventos 1008/1010 indica que el servicio está operando con permisos adecuados.
  5. Replicación: repadmin /showrepl debe reportar Success en todos los DC.

Notas adicionales

  • Siempre crea un punto de restauración o una copia de seguridad de AD antes de desinstalar paquetes críticos.
  • Si la actualización corrige una vulnerabilidad conocida (CVE‑2026‑69813), evalúa el riesgo de volver a aplicar el parche después de haber restaurado los permisos. En muchos casos, aplicar el parche y luego volver a asignar manualmente las ACL resuelve el conflicto sin dejar la vulnerabilidad sin cubrir.
  • Mantén un registro de los paquetes KB instalados en cada controlador; una tabla sencilla en un repositorio de documentación interna ayuda a correlacionar futuros incidentes con actualizaciones específicas.
  • Cuando modifiques políticas de seguridad, documenta el cambio y programa una revisión posterior para volver a los valores recomendados. Un ajuste temporal de NTLM puede abrir una brecha si se olvida revertirlo.