Durante una migración de dominios es frecuente que los administradores se topen con registros aparentemente amenazantes en el Visor de eventos. Uno que genera especial inquietud es Schannel 36887 – alerta TLS fatal 48. A continuación encontrarás una guía exhaustiva para entenderlo, decidir si realmente requiere acción antes de terminar la migración de tu controlador de dominio Windows Server 2012 R2 hacia Windows Server 2022 y, en caso de ser necesario, corregirlo con seguridad.
¿Qué significa exactamente Schannel 36887 (TLS alerta 48)?
Schannel es el proveedor de seguridad que maneja TLS/SSL en Windows. El Event ID 36887 indica que el servidor recibió una alerta TLS fatal procedente del par de comunicación. El código 48 corresponde a unknown CA, es decir, el cliente no confía en la autoridad certificadora (CA) que emitió el certificado presentado por el servidor (o viceversa, dependiendo del sentido del flujo).
- La alerta no bloquea de forma automática el tráfico LDAP o Kerberos, pero puede abortar sesiones LDAPS, HTTPS, SMTP, RDP o de software de terceros que dependen de TLS.
- En DC de dominio, el evento se registra con mucha frecuencia cuando algún dispositivo de red, impresora, appliance o aplicación obsoleta intenta cifrar tráfico usando un certificado no confiable.
Por qué aparece con tanta frecuencia durante una migración de DC
Mientras conviven controladores de dominio con sistemas operativos distintos (2012 R2 y 2022) se desencadenan situaciones que favorecen la alerta 48:
- Cadenas de confianza incompletas: el DC antiguo puede carecer de la CA raíz o intermedia que usa un nuevo dispositivo (o viceversa).
- Cambios de ciphersuite: Windows Server 2022 y 2012 R2 no exponen exactamente las mismas suites TLS, lo que provoca renegociaciones o rechazos que activan Schannel.
- Aplicaciones heredadas: software legado —por ejemplo, MFPs o escáneres— suelen almacenar certificados autofirmados y conectarse siempre al “DC primario” (el antiguo), saturando su registro con 36887.
- Políticas de grupo en transición que aún no han llegado a todos los equipos, causando que algunos confíen en la nueva CA y otros no.
¿Puedo ignorar Schannel 36887 hasta que el nuevo DC esté operativo?
La respuesta corta es “normalmente sí”, pero conviene matizar. Emplea la siguiente matriz de decisión:
| Escenario | Impacto Funcional Observado | Recomendación |
|---|---|---|
| Solo eventos 36887, sin fallos de autenticación ni de aplicaciones | Nulo; todo el dominio funciona | Posponer la intervención hasta finalizar la migración |
| Impresoras o aplicaciones que ya no envían correos, escaneos o LDAPS | Moderado | Actualizar o reemitir certificado en el dispositivo afectado |
| Errores de inicio de sesión LDAPS/SmartCard o fallos de replicación AD | Alto | Corregir inmediatamente siguiendo la sección “Pasos de mitigación” |
Si el evento simplemente refleja intentos externos “ruidosos” —por ejemplo scanners de seguridad o bots de Internet que tantean tu puerto 443— lo prudente es registrar, documentar y dejar que el cambio de DC se complete. En la práctica, la mayor parte de los ambientes conviven meses con estos avisos sin ninguna consecuencia real.
Lista de verificación rápida antes de decidir
- Certificado del servicio LDAPS en el DC: vigente, clave de 2048 bits o más y firma SHA‑256
- Cadena de CA: disponible en el almacén Raíz de Confianza (
certlm.msc > Trusted Root Certification Authorities) - Fecha y hora del DC y de los clientes: correctas (
w32tm /query /status) - Registros de solicitud de validación de certificados intermedios: sin errores (Visor de eventos → Applications and Services Logs > Microsoft > Windows > CAPI2)
- Política de grupo “Allow only approved CAs”: deshabilitada, salvo que tengas un PKI rigoroso en producción
Pasos de mitigación (opcionales antes de migrar)
1. Identificar el cliente o servicio que dispara la alerta
reg add HKLM\System\CurrentControlSet\Control\SecurityProviders\Schannel /v EventLogging /t REG_DWORD /d 7 /f
Este comando eleva el nivel de detalle. Tras reproducir el evento, revierte el cambio (EventLogging a 1) para evitar saturar el log.
2. Comprobar el certificado servido por LDAPS o IIS
certutil -store -v MY
Verifica Subject, Issuer, fechas de validez y Enhanced Key Usage. Debe incluir Server Authentication (1.3.6.1.5.5.7.3.1).
3. Actualizar la cadena de confianza
- Importa la CA intermedia y raíz en Trusted Root Certification Authorities.
- Distribuye la CA mediante GPO: Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities.
- Fuerza la actualización con
gpupdate /forceo reinicia.
4. Alinea las suites TLS y deshabilita protocolos inseguros
En 2012 R2, TLS 1.2 está presente pero no siempre habilitado para todas las aplicaciones. Aplicar las siguientes claves facilita la compatibilidad con clientes modernos y reduce falsos positivos:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f
Reinicia para aplicar. Windows Server 2022 ya viene endurecido por defecto.
5. Parcheo acumulativo de seguridad y KB específicos
Instala cada CU disponible para ambos sistemas operativos, ya que Microsoft publica root cert updates y ajustes de Schannel dentro de estos paquetes.
Buenas prácticas TLS para Active Directory a largo plazo
- PKI Interna: disponer de una PKI corporativa evita que dispositivos generen certificados autofirmados y simplifica la renovación masiva.
- Validez corta: fija vigencias de 12 meses o menos; esto cumple bases de seguridad modernas y obliga a mantener la cadena actualizada.
- Cipher Suites: deshabilita RC4, 3DES y exporta nulidades; adopta
TLSECDHERSAWITHAES256GCM_SHA384o equivalentes. - Supervisión continua: usa scripts PowerShell para leer el visor de eventos y alertar en tiempo real si reaparece 36887; identifica la IP de origen con
Get-WinEvent -FilterHashtable @{LogName='System';Id=36887}. - Inventario de dispositivos: documenta qué equipos consumen LDAPS o RPC sobre TLS, de forma que migraciones futuras no te sorprendan.
Verificación posterior en Windows Server 2022
Una vez que 2022 asuma los roles FSMO y 2012 R2 sea retirado:
- Vuelve a activar temporalmente el nivel de EventLogging 7 en Schannel del nuevo DC.
- Abre el puerto 636 desde un cliente actualizado y ejecuta:
Test-NetConnection <DC2022> -Port 636
seguido de:ldp.exe→ Connect → Bind. - Comprueba que la alerta 48 no reaparece por al menos 24 horas.
- Desactiva el registro detallado para preservar recursos.
- Actualiza la documentación del dominio con la fecha en que el evento dejó de presentarse.
Preguntas frecuentes
¿Eliminar Schannel 36887 mejora el rendimiento? No. El evento es un síntoma, no la causa; la ganancia de CPU o memoria es insignificante. La única mejora observable puede ser un Visor de eventos menos saturado. ¿Puedo filtrar la alerta en el Visor de eventos? Sí, con una Custom View. Sin embargo, es mejor abordar la raíz del problema en lugar de ocultarlo para siempre. ¿Qué ocurre si forzamos SSL Offloading a un balanceador F5 o Citrix? El error puede migrar del DC al appliance. Asegúrate de que el balanceador confíe en tu CA y sostenga la sesión TLS sin renegociaciones inesperadas. ¿La alerta 48 se relaciona con LDAP signing? Indirectamente. Si habilitas LDAP signing sin configurar LDAPS adecuado, los clientes podrían intentar TLS sin cadena válida y activar el evento.
Conclusión
Schannel 36887 con código 48, aunque aparatoso, rara vez es crítico durante una migración de controladores de dominio. Evalúa si existe impacto real en la operación diaria. Si el error solo decora el Visor de eventos, puedes centrarte en terminar la transición a Windows Server 2022 y luego comprobar si persiste. Cuando sea necesario actuar, la clave está en certificados confiables, cadenas completas, suites TLS coherentes y un registro bien afinado. Con estas prácticas, tu infraestructura de Active Directory seguirá segura y libre de alertas intimidantes.