Problema

En entornos con controladores de dominio (DC) antiguos, es frecuente encontrarse con configuraciones de LDAP sin firma. La ausencia de LDAP signing expone a ataques de “man‑in‑the‑middle” y, a la vez, bloquea la instalación de versiones más recientes de Windows Server que exigen la firma por defecto. Cuando se planifica una migración de DC –por ejemplo, de Windows Server 2012 a una versión más moderna– el ingeniero debe decidir si habilitar LDAP signing antes de mover los roles, después de la migración o en ambos momentos. Además, surge la cuestión de dónde alojar los servicios de certificación (ADCS) una vez que el servidor VPN que los hospedaba será retirado.

Causa

  1. Controladores legacy sin LDAP signing – versiones de Windows Server anteriores permiten LDAP sin firma de forma predeterminada. Si nunca se cambió la política, la comunicación LDAP sigue sin firmarse.
  2. Política de seguridad de dominio desactualizada – la directiva de grupo (GPO) que controla “Domain controller: LDAP server signing requirements” suele quedar en “None”.
  3. Dependencias de servicios – ADCS, NPS o VPN a menudo se instalan en DC por conveniencia, pero esa práctica complica la migración porque los roles críticos quedan acoplados.
  4. Falta de pruebas de compatibilidad – aplicaciones que todavía usan LDAP sin firma pueden romperse al habilitar la firma sin validar primero la compatibilidad.

Solución

1. Habilitar LDAP signing antes de la migración

  • Ventaja: Detectas aplicaciones incompatibles mientras el entorno sigue operativo.

  • Procedimiento:

    1. Crea una GPO nueva o modifica la existente:
      Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Domain controller: LDAP server signing requirements y ponla en Require signing.
    2. Fuerza la actualización de políticas en todos los DC con gpupdate /force.
    3. Verifica que los controladores acepten la nueva política revisando el registro: 
      reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity
      El valor debe ser 2 (Require signing).

  • Prueba de ruptura: Usa una cuenta de prueba para ejecutar un bind LDAP sin firma desde un cliente que no soporte firma. El intento debe fallar, confirmando que la política está activa.

2. Migrar los controladores de dominio con método side‑by‑side

  1. Preparación:
    • Ejecuta dcdiag /v y repadmin /replsummary para asegurar salud del AD.
    • Respaldar System State de cada DC.
  2. Despliegue de nuevos servidores (Windows Server 2022 o versión soportada):
    • Instala el rol Active Directory Domain Services pero no promuevas todavía.
    • Asegúrate de que la zona DNS del dominio se replica automáticamente.
  3. Promoción:
    • Usa Install-ADDSDomainController con los parámetros habituales.
    • Verifica que la replicación funcione (repadmin /showrepl).
  4. Descomisión de los viejos DC:
    • Transferir los FSMO a los nuevos controladores (Move-ADDirectoryServerOperationMasterRole).
    • Demote los antiguos con Uninstall-ADDSDomainController.

3. Reubicar AD Certificate Services

  • Opción recomendada: Instalar ADCS en un servidor dedicado que no sea DC.
    • Evita cargar servicios de emisión de certificados en controladores, reduciendo la superficie de ataque y simplificando futuros upgrades.
  • Si no hay hardware disponible:
    • Instala ADCS en uno de los nuevos DC, pero habilita la característica Enterprise PKI y configura la autoridad de certificación como Enterprise Subordinate CA para que pueda ser movida fácilmente después.

4. Post‑migración y ajustes finales

  • Revisa la GPO de LDAP signing en los nuevos DC y asegúrate de que la política se replica.
  • Actualiza los clientes VPN para que apunten al nuevo servidor de certificados.
  • Elimina roles sobrantes (DHCP, DNS) de los DC si se van a mover a servidores especializados.

Cuándo aplicar esta solución

  • Se detecta LDAP signing deshabilitado y se planea una actualización de DC a una versión que lo requiera.
  • Hay al menos un DC con Windows Server 2012 o anterior y la política de firma no está forzada.
  • Se pretende separar servicios de infraestructura (ADCS, DHCP, DNS) de los controladores por motivos de seguridad o escalabilidad.
  • No se dispone de un servidor dedicado para ADCS: la solución permite usar un DC temporalmente sin bloquear la migración.

No aplicar si todas las aplicaciones críticas usan librerías LDAP que no soportan firma y no pueden ser actualizadas; en ese caso, habilitar LDAP signing antes de la migración provocaría interrupciones graves. En tales casos, pospone la firma hasta después de la migración y planifica una fase de modernización de aplicaciones.

Código

# Habilitar LDAP signing mediante registro (alternativa a GPO)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity /t REG_DWORD /d 2 /f

# Forzar actualización de políticas en todos los DC
gpupdate /force

# Promover nuevo DC (ejemplo con PowerShell)
Install-ADDSDomainController `
    -DomainName "contoso.com" `
    -SiteName "Default-First-Site-Name" `
    -InstallDns:$true `
    -Credential (Get-Credential) `
    -SafeModeAdministratorPassword (Read-Host -AsSecureString "SafeModePwd") `
    -NoGlobalCatalog:$false `
    -Force:$true

# Transferir roles FSMO a nuevo DC
Move-ADDirectoryServerOperationMasterRole -Identity "NewDC01" -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Verificación

  1. LDAP signing activo:
    • En un cliente, ejecuta ldapsearch -x -H ldap://dc01.contoso.com -b "dc=contoso,dc=com" sin la opción -ZZ. El comando debe fallar con “strong(er) authentication required”.
  2. Replicación saludable:
    • repadmin /replsummary debe mostrar cero errores y latencia mínima.
  3. ADCS funcional:
    • Desde una máquina cliente, solicita un certificado con certreq -new request.inf cert.req. La emisión debe completarse sin errores.
  4. Servicios auxiliares:
    • Verifica que DHCP y DNS respondan correctamente mediante ipconfig /renew y nslookup.

Notas adicionales

  • Backup antes de cualquier cambio: Un System State backup permite restaurar rápidamente si la firma rompe alguna aplicación crítica.
  • Monitoreo de eventos: Busca los IDs 2887 (LDAP signing) y 1644 (replicación) en el visor de eventos de los DC.
  • Documenta la ubicación de ADCS: Si decides instalarlo en un DC, anota claramente que es una solución temporal; planifica su migración a un servidor dedicado antes de la siguiente actualización mayor.
  • Pruebas de carga: Después de la migración, ejecuta pruebas de autenticación simultánea (por ejemplo, con LoadGen) para confirmar que la firma no introduce cuellos de botella.
  • Política de contraseñas y Kerberos: Aprovecha la ventana de migración para revisar otras configuraciones de seguridad (por ejemplo, Kerberos armoring).

Con este enfoque, la firma LDAP queda garantizada antes de tocar la arquitectura del dominio, los controladores nuevos asumen los roles críticos sin interrupciones y los servicios de certificación quedan aislados para futuros cambios. La combinación de pruebas tempranas, migración side‑by‑side y separación de roles minimiza los riesgos y mantiene la infraestructura lista para los requerimientos de seguridad actuales.