Habilitación de LDAPS con Microsoft PKI

LDAPS cifra el tráfico LDAP entre clientes y controladores de dominio encapsulando la comunicación LDAP estándar en TLS, utilizando un certificado de autenticación de servidor emitido por su infraestructura de clave pública (PKI) de Microsoft. Sin LDAPS, las conexiones LDAP simples envían nombres de usuario y contraseñas a través de la red en texto plano, visibles para cualquiera que realice una captura de paquetes.

Esto resulta especialmente arriesgado con una conexión LDAP simple, donde las credenciales viajan sin cifrar de extremo a extremo. La captura de un solo paquete en la red o un puerto de conmutador comprometido son suficientes para obtener las credenciales del dominio. LDAPS soluciona este problema al vincular un certificado al controlador de dominio y requerir TLS para la conexión.

Esta guía abarca todo el proceso: requisitos previos, instalación y configuración de AD LDS cuando sea necesario, emisión y vinculación de un certificado de autenticación de servidor desde su PKI de Microsoft, validación de la conexión LDAPS con ldp.exe, los errores más frecuentes que encuentran los administradores y cómo revertir los cambios de forma segura si algo falla.

Puntos Clave

• LDAPS requiere un certificado con la EKU de autenticación de servidor, emitido por una CA en la que confíe cada cliente, vinculado a cada controlador de dominio o instancia de AD LDS que necesite aceptar conexiones LDAP cifradas.
• El fallo más común tras habilitar LDAPS es un evento Schannel 36870 o 36872, causado por una cadena de certificados rota, un certificado caducado o permisos restrictivos en el almacén de claves de la máquina, y no por un cliente mal configurado.
• Antes de utilizar LDAPS en producción, valide cada implementación con ldp.exe a través del puerto 636 (o 50001 para AD LDS) y confirme la validez restante del certificado en lugar de asumir que seguirá funcionando.
• Trate el certificado LDAPS como cualquier otro activo PKI gestionado: realice un seguimiento de su caducidad, automatice su renovación y supervise los registros de eventos de Schannel y CAPI2, en lugar de descubrir fallos cuando una aplicación dependiente del directorio deja de funcionar.
• Según la encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, las empresas que dependen de procesos manuales de certificados registraron tiempos de inactividad relacionados con los certificados en el 45 % de los casos durante el último año, y el 37.5 % de esas interrupciones fueron causadas específicamente por un certificado caducado.

¿A quién debería importarle habilitar LDAPS?

La activación de LDAPS afecta a más personas que solo a quien ejecuta el asistente. A continuación, se detalla lo que cada equipo debería hacer con esta guía.

• Administradores de PKI Posea la plantilla de certificado, la política de emisión y la vinculación por controlador de dominio. Acción: audite esta semana la fecha de vencimiento de los certificados vinculados a cada controlador de dominio.
• Arquitectos de seguridad Decida si se debe implementar la vinculación y firma de canales LDAP en toda la organización una vez que LDAPS esté operativo. Acción: documente la política de implementación y un plan de despliegue gradual antes de activar la implementación estricta.
• Equipos de plataforma e identidad Gestionar diariamente los controladores de dominio y las instancias de AD LDS. Acción: programar la instalación del certificado en una ventana de mantenimiento y validarlo con ldp.exe antes de una implementación a gran escala.
• Cumplimiento y GRC Asigne el cifrado LDAPS al marco que requiera tráfico de directorio cifrado internamente. Acción: agregue el estado del certificado LDAPS a la siguiente lista de verificación de auditoría PKI.
• CISO Adoptar una perspectiva más amplia sobre la reducción del riesgo asociado a los certificados manuales en todo el entorno. Acción: realizar un seguimiento del estado de los certificados LDAPS como un elemento más dentro del mismo programa que aborda la tendencia generalizada en el sector hacia una menor duración de los certificados.

Requisitos previos

Debe haber una infraestructura de clave pública (PKI) de Microsoft funcional disponible y configurada. Al visualizar PKIView.msc, no debería aparecer ningún error.

Si necesita ayuda para implementar su propia infraestructura de clave pública (PKI), puede consultar este artículo para crear su propia PKI de dos niveles.

Además de una jerarquía PKI saludable, confirme cada uno de estos puntos antes de comenzar:

• Una CA emisora ​​accesible desde cada controlador de dominio o servidor AD LDS que necesite un certificado.
• Derechos de administrador empresarial en el dominio y derechos de administrador local en el servidor de destino.
• Una plantilla de certificado que admita la EKU de autenticación de servidor (el siguiente tutorial reproduce la plantilla de autenticación Kerberos predeterminada para esto).
• Acceso a la red desde clientes LDAP al puerto TCP 636, o al puerto TCP 50001 si utiliza AD LDS con puertos SSL predeterminados, no solo al puerto 389.
• Un plan de reversión y una ventana de mantenimiento, ya que vincular un certificado a un controlador de dominio nunca debe considerarse un cambio de riesgo cero.

Instalación de AD LDS

Este paso debe llevarse a cabo en el servidor LDAP o en los controladores de dominio que serán responsables de alojar el servicio LDAPS.

• Abra Administrador de servidores
• Desde manage, abierto Agregar funciones y funciones
• En Antes de comenzar, haga clic en Siguiente

• On Tipo de instalación, asegurar Instalación basada en roles o funcionesY haga clic en Siguiente

• On Selección de servidor, haga clic Siguiente.

• On Roles de servidor, haga clic Servicios de directorio ligero de Active DirectoryY haga clic en Agrega característicasY haga clic en Siguiente

• On Caracteristicas, haga clic Siguiente

• On AD SUD, haga clic Siguiente

• On Confirmación, haga clic Instale

• Después de la instalación, es necesario configurar AD LDS

Configuración de AD LDS

• Ejecutar AD SUD Asistente de configuración. Haga clic en Siguiente en la primera página.

• Asegúrese de que instancia única está seleccionado y haga clic en Siguiente

• Proporcione Nombre de instancia y Mareas Ideales para Lecciones Y haga clic en Siguiente

• Abandonar puertos predeterminados y hacer clic en Siguiente

Si AD LDS está instalado en el controlador de dominio, entonces el puerto LDAP sería 50000 y el puerto SSL sería 50001

• On Partición del directorio de aplicaciones, haga clic en Siguiente

• On Ubicaciones de archivos, haga clic Siguiente

• On Selección de cuenta de servicio, puedes dejarlo en el Cuenta de servicio de red, o elegir un cuenta preferida que puede controlar el servicio LDAPS

• On administradores de AD LDSdeja el administrador actual, o elige otra cuenta del dominio

• Elija todos los archivos LDF para ser importado y haga clic en Siguiente

• On Listo para instalar, haga clic Siguiente

• Después de la instalación, haga clic en Termine

Publicar un certificado que admita la autenticación del servidor

• Inicie sesión en la CA emisora ​​como administrador empresarial
• Asegúrese de estar en Administrador de servidores
• En el campo Accesorios menú, abrir Autoridad certificada

Expanda el árbol de la consola y haga clic con el botón derecho en Plantillas de certificado.

• Seleccionar Autenticación Kerberos (ya que proporciona autenticación del servidor). Haga clic derecho y seleccione Plantilla duplicadaAhora podemos personalizar la plantilla.

• CAMBIAR Nombre para mostrar de la plantilla y Nombre de la plantilla on General pestaña. Comprobar Publicar certificado en Active DirectoryEsto garantizará que el certificado aparezca cuando inscribamos controladores de dominio usando esa plantilla.

• On Manejo de solicitudesverificar Permitir que se exporte la clave privada.

• En la Pestaña de seguridadproporcionar Permisos de inscripción a los usuarios apropiados

• Haga clic en Aplicar

Emitir el Certificado en la CA Emisora

• Inicie sesión en la CA emisora ​​como administrador empresarial
• Asegúrese de estar en Administrador de servidores
• En el campo Accesorios menú, abrir Autoridad certificada

Expanda el árbol de la consola y haga clic en Plantillas de certificado.

En la barra de menú, haga clic en Acción > Nuevo > Plantilla de certificado para emitir.

• Elija el Certificado LDAPS

• Haga clic en OK y ahora debería aparecer en Plantillas de certificado

Solicitar un certificado para la autenticación del servidor

• Inicie sesión en el servidor LDAP o en el controlador de dominio.
• Tipo ganar+R y correr MMC
• Haga clic en Archivo y hacer clic en Añadir / quitar complemento

• Seleccione Certificados y haga clic en Agregar

• Elija una cuenta de computadora

• Si se siguen los pasos en LDAPServer donde está instalado AD LDS, haga clic en Equipo local o elija Otro equipo y elija dónde se debe instalar.

• Ampliar la opción árbol de consola, y dentro Personal, haga clic Certificados

• Haga clic derecho en Certificados y hacer clic en Todas las tareas y seleccione Solicitar nuevo certificado

• Siga las instrucciones, elija la plantilla LDAPS que emitimos anteriormente e instálela.
• Una vez instalado haga clic en Finalizar

• Abra el certificado y en Pestaña de detalles, navegue a Uso mejorado de claves para asegurar Autenticación de Servidor está presente.

Validando la conexión LDAPS

• Inicie sesión en el servidor LDAP como administrador empresarial
• Tipo ganar+R y correr ldp.exe
• En el menú superior, haga clic en Conexiones y luego haga clic en Conectar

• En el servidor, proporcione el nombre de dominio, asegúrese de que SSL esté marcado y se proporcione el puerto adecuado y haga clic en Aceptar

• No debería aparecer ningún error. Si la conexión no se pudo realizar correctamente, podría aparecer el siguiente resultado.

Errores comunes y cómo solucionarlos

Estos son los errores con los que se encuentran con mayor frecuencia los administradores al habilitar LDAPS, y cuáles son sus causas.

Evento Schannel 36870 o 36872 (Problema con el certificado o la clave)

Ambos eventos apuntan a un problema con el certificado del servidor en sí, no con la configuración LDAP. Cinco causas explican casi todas las ocurrencias: ACL incorrectas en la carpeta MachineKeys que impiden que la cuenta del sistema lea la clave privada, una comprobación de revocación de certificado que falla porque el controlador de dominio no puede acceder a un respondedor CRL u OCSP, una cadena de certificados rota porque la CA raíz no está en el almacén de raíces de confianza, un certificado con un nombre alternativo del sujeto faltante o incorrecto que no coincide con el nombre DNS del controlador de dominio, o un certificado caducado. Ejecutar certutil -v -verify -urlfetch <cert.cer> bajo el contexto del sistema (usando psexec -s) para confirmar cuál de las cinco opciones se aplica.

ldp.exe muestra "No se puede abrir la conexión" o "Se produjo un error local".

Esto casi siempre significa que el puerto 636, o el puerto SSL de AD LDS (50001 por defecto), no está activo o está bloqueado por un firewall, o que aún no hay ningún certificado válido asociado al servidor. Confirme que el certificado aparece en el almacén personal del equipo con autenticación de servidor en su configuración de uso de clave mejorada antes de solucionar problemas de la ruta de red.

Certificado sin autenticación de servidor EKU

Si la plantilla del certificado se duplicó a partir de una que no sea la autenticación Kerberos, o si se editó el uso extendido de la clave durante la personalización, Schannel no ofrecerá el certificado para LDAPS, incluso si está correctamente vinculado. Vuelva a emitirlo a partir de una plantilla que incluya la autenticación del servidor en su uso extendido de la clave.

Cadena de certificados rota en el cliente

LDAPS falla en el lado del cliente cuando la raíz de la CA emisora ​​no se encuentra en el almacén de Autoridades de Certificación Raíz de Confianza de esa máquina. Esto es común en clientes que no pertenecen a un dominio, servidores intermedios y aplicaciones de terceros que realizan conexiones LDAP. Distribuya explícitamente la raíz y los certificados intermedios a esas máquinas en lugar de asumir que la confianza del dominio los cubre.

Fallos en la recuperación de CRL u OCSP

Los controladores de dominio validan el estado de revocación del certificado LDAPS como parte del protocolo de enlace TLS. Si un punto de distribución de CRL o un respondedor OCSP no está disponible, se encuentra detrás de un proxy de autenticación que la cuenta del sistema no puede atravesar o está fuera de línea, la validación del certificado falla aunque el certificado en sí sea válido. Habilite el registro CAPI2 para confirmar que esta sea la causa antes de asumir que el certificado es defectuoso.

Pasos de retroceso

Si LDAPS provoca una interrupción o daña una aplicación dependiente, revierta los cambios deliberadamente en lugar de deshabilitar un control de seguridad como solución rápida.

• Compruebe si el certificado anterior sigue disponible, ya sea exportado como copia de seguridad o presente pero reemplazado. De ser así, vuelva a vincularlo en el almacén personal del equipo en lugar de dejar el servidor sin un certificado de autenticación de servidor válido.
• Si no existe ningún certificado previo, elimine el certificado recién emitido del almacén Personal y vuelva a configurar el controlador de dominio para que solo admita LDAP hasta que se disponga de un certificado corregido para su reemisión.
• Si el problema se debe a la vinculación del canal LDAP o a la aplicación de la firma recientemente habilitada, restablezca el valor del registro correspondiente a su configuración anterior, menos estricta, solo el tiempo necesario para corregir el cliente o la aplicación heredada que causa el fallo; luego, vuelva a habilitar la aplicación. No deje la aplicación permanentemente relajada como solución.
• Vuelva a validar con ldp.exe después de cada paso de reversión y documente la causa raíz antes de intentar el cambio nuevamente.
• No desactive la comprobación de revocación de certificados para solucionar un fallo de CRL u OCSP. En su lugar, corrija la conectividad con el punto final de revocación, ya que deshabilitar la comprobación de revocación elimina el control que LDAPS debería proporcionar.

Guía de referencia rápida: Requisitos previos, validación, errores y reversión paso a paso.

Utilice esta tabla como una lista de verificación práctica durante todo el proceso de implementación, desde el diseño de la plantilla hasta la validación.

Requisito previo	Comando / Configuración	Verificación de validación	Error común	Rollback	Propietario
Jerarquía PKI saludable	Ejecute PKIView.msc en cada CA	No se muestran iconos de error en PKIView.	Cadena rota o un intermediario revocado	Corrija la jerarquía antes de continuar; este paso no tiene retroceso propio.	Administrador de la infraestructura de clave pública (KPI)
Plantilla de certificado de autenticación de servidor	Duplique la plantilla de autenticación Kerberos; habilite “Publicar certificado en Active Directory”.	La plantilla aparece en la consola de plantillas de certificados con el EKU correcto.	Plantilla sin la EKU de autenticación del servidor	Elimine la plantilla de “Plantillas de certificados para emitir”.	Administrador de la infraestructura de clave pública (KPI)
Plantilla emitida por la CA	Consola de la Autoridad de Certificación > Acción > Nuevo > Plantilla de certificado para emitir	La plantilla aparece en la lista de la CA emisora.	La plantilla no es visible para el servidor solicitante (permisos de inscripción).	Haga clic con el botón derecho en la plantilla > Todas las tareas > No emitir	Administrador de la infraestructura de clave pública (KPI)
Certificado solicitado y vinculado en el servidor	mmc > Certificados (Cuenta de equipo) > Solicitar nuevo certificado	El certificado aparece en el almacén personal con autenticación de servidor en el uso mejorado de claves.	Evento Schannel 36870 o 36872 (problema de ACL, cadena, SAN o caducidad)	Elimine el certificado del almacén personal; restaure el certificado anterior si existía alguno.	Equipo de Plataforma/Identidad
Conectividad LDAPS validada	ldp.exe > Conexión > Conectar (SSL activado, puerto 636 o 50001)	Se conecta sin cuadro de diálogo de error.	“No se puede abrir la conexión” (puerto bloqueado o certificado no vinculado)	Revierte la regla del firewall o vuelve a vincular el certificado anterior.	Equipo de Plataforma/Identidad, con el Equipo de Red
Aplicación de la vinculación de canales/firma LDAP (refuerzo de seguridad opcional)	Establezca el valor del registro LdapEnforceChannelBinding	Los clientes LDAP heredados aún se autentican después de la aplicación de la normativa.	Las aplicaciones heredadas fallan bajo estricta aplicación de la ley.	Restablecer temporalmente la aplicación a un valor permisivo mientras se corrige la aplicación del cliente.	Arquitecto de seguridad

Cómo se conecta la habilitación de LDAPS con la gestión del ciclo de vida de los certificados

El certificado LDAPS asociado a un controlador de dominio no es un caso especial. Se trata de un certificado renovable de corta duración que caducará, requerirá rotación y, finalmente, deberá reemitirse con una nueva plantilla o algoritmo. Considerarlo una tarea de configuración única es precisamente el patrón manual que provoca interrupciones relacionadas con certificados en otras partes del entorno: la encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, reveló que el 45 % de las empresas experimentaron tiempo de inactividad relacionado con certificados el año anterior, y que el 37.5 % de esos incidentes fueron causados ​​específicamente por un certificado caducado. La pérdida silenciosa del certificado LDAPS de un controlador de dominio representa el mismo modo de fallo, pero con un impacto mucho mayor, ya que todas las aplicaciones y rutas de inicio de sesión dependientes de LDAP detrás de ese controlador de dominio se ven afectadas simultáneamente.

Las plataformas de gestión del ciclo de vida de los certificados, como CertSecure Manager, solucionan este problema al detectar todos los certificados vinculados a los controladores de dominio y las instancias de AD LDS, realizar un seguimiento centralizado de la caducidad y automatizar la renovación antes de que un administrador tenga que detectar un error de Schannel. Si ya está modernizando las operaciones de certificados en otras partes del entorno, vea cómo la modernización de PKI y la gestión del ciclo de vida de los certificados (CLM) funcionan conjuntamente y cómo una hoja de ruta combinada de PKI y CLM contempla precisamente este tipo de certificados internos no públicos.

LDAPS en entornos PKI en la nube, híbridos y con múltiples autoridades de certificación

Los controladores de dominio alojados en Azure, AWS o en un entorno híbrido de Active Directory aún necesitan un certificado emitido por una CA en la que confíe cada cliente que se conecta, lo cual se complica a medida que los controladores de dominio se extienden por regiones y límites de red. Las jerarquías de múltiples CA, donde cada CA emisora ​​regional publica su propia plantilla de autenticación de servidor, requieren que cada plantilla y cada CA emisora ​​se conecten a la misma raíz de confianza; de lo contrario, los clientes de una región no superarán la validación LDAPS contra un controlador de dominio en otra.

Para las organizaciones que gestionan controladores de dominio en varias regiones o proveedores de nube, centralizar la emisión de certificados mediante un modelo PKI-as-a-Service elimina la necesidad de replicar manualmente la configuración de plantillas y la confianza en las CA en cada sitio, y proporciona a cada CA emisora ​​en una jerarquía de múltiples CA una política coherente que aplicar.

Cómo medir el éxito y qué auditar periódicamente

Un despliegue exitoso de LDAPS no se limita a que “se haya conectado una sola vez”. Realice auditorías periódicas, no solo durante la configuración inicial:

• Fechas de vencimiento de certificados en cada controlador de dominio y enlace LDAPS de instancia de AD LDS, con alertas mucho antes del vencimiento.
• Registros de eventos de Schannel y CAPI2 para fallos de TLS o validación de certificados, no solo fallos de conexión directos.
• Accesibilidad a CRL y OCSP desde cada controlador de dominio, incluso a través de cualquier proxy en la ruta.
• ¿Qué clientes o aplicaciones siguen recurriendo al enlace simple no cifrado en el puerto 389 después de que LDAPS esté disponible?
• Si la vinculación del canal LDAP y la aplicación de la firma están configuradas según lo previsto, y qué clientes heredados dejarían de funcionar si se endureciera dicha aplicación.

Un inventario de activos criptográficos como CBOM Secure extiende esta misma disciplina más allá de los certificados LDAPS a cada clave, certificado y algoritmo del entorno, de modo que no se descubre nada por primera vez durante una interrupción del servicio.

A largo plazo, trate la plantilla de certificado de autenticación de servidor del mismo modo que cualquier perfil de certificado que se enfrente a una eventual transición de algoritmo. El NIST finalizó sus tres primeros estándares de criptografía postcuántica, FIPS 203, FIPS 204 y FIPS 205, el 13 de agosto de 2024. Las plantillas PKI internas utilizadas para infraestructuras como los controladores de dominio son precisamente el tipo de perfil de certificado de larga duración y fácil de olvidar que requiere un plan de criptoagilidad antes de que dicha transición llegue a los sistemas internos. El Centro de Excelencia PQC de Encryption Consulting y una evaluación de preparación para PQC son el lugar idóneo para elaborar esa hoja de ruta de criptoagilidad.

La opinión de Encryption Consulting

La mayoría de las interrupciones de LDAPS que observamos no se deben a un concepto mal entendido. Se deben a un certificado que se emitió una sola vez, funcionó correctamente y nunca se revisó hasta que caducó o el registro CAPI2 comenzó a llenarse de errores de revocación. La solución no consiste en una revisión puntual, ya que los pasos anteriores son suficientes. Se trata de asegurarse de que este certificado sea visible en el sistema que ya realiza el seguimiento de la caducidad de certificados para el resto de la infraestructura de clave pública (PKI), en lugar de que solo exista en la memoria de quien lo configuró. Si administra más de unos pocos controladores de dominio, esto significa una herramienta de gestión del ciclo de vida, no una hoja de cálculo que alguien olvida abrir.

Conclusión

Siguiendo los pasos anteriores, se habilita LDAPS y se protegen adecuadamente las credenciales utilizadas en su entorno PKI, así como cualquier otra aplicación que pueda aprovechar el cifrado LDAP. Trate el certificado que acaba de emitir como un activo gestionado desde el primer día: realice un seguimiento de su vencimiento, esté atento a los errores de Schannel y CAPI2, y tenga a mano el plan de reversión en lugar de improvisar uno durante una interrupción del servicio.

Si necesita ayuda con su entorno PKI, no dude en enviarnos un correo electrónico a [email protected].

Preguntas frecuentes

¿Cuál es la principal conclusión al habilitar LDAPS con Microsoft PKI?

LDAPS reemplaza las conexiones LDAP simples sin cifrar con una conexión protegida por TLS, utilizando un certificado de autenticación de servidor emitido por su infraestructura de clave pública (PKI) de Microsoft y vinculado a cada controlador de dominio o instancia de AD LDS. Una vez vinculado, ese certificado requiere la misma gestión continua que cualquier otro certificado en su entorno.

¿Por qué es importante esto para los equipos de PKI empresariales?

Las conexiones LDAP simples sin cifrar envían credenciales de dominio en texto plano, y el tráfico de directorio afecta a casi todas las aplicaciones que dependen de la identidad en una empresa. Los equipos de PKI que omiten LDAPS dejan una amplia y conocida vulnerabilidad de credenciales en toda la red, que una simple captura de paquetes puede aprovechar.

¿Qué riesgos aumentan si este tema se aborda manualmente?

La gestión manual implica que la caducidad del certificado LDAPS no se registra en ningún sitio, salvo en la memoria institucional; las plantillas varían entre los controladores de dominio; las claves privadas no se marcan de forma consistente como exportables para su copia de seguridad; y nadie supervisa los registros de Schannel o CAPI2 hasta que una interrupción obliga a solucionar el problema.

¿Qué equipos deberían asumir la responsabilidad de este cambio?

Los administradores de PKI son responsables de la plantilla y la emisión de certificados. Los equipos de plataforma o identidad gestionan la vinculación del controlador de dominio y el funcionamiento diario. Los arquitectos de seguridad deciden sobre la vinculación del canal y la aplicación de la firma LDAP. Los responsables de cumplimiento y los CISO realizan el seguimiento como parte del programa general de gestión de riesgos de certificados.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

El certificado LDAPS es un activo más que requiere detección, seguimiento de vencimiento y renovación automatizada. Las herramientas de gestión del ciclo de vida de los certificados, como CertSecure Manager, aplican la misma automatización a los certificados de controlador de dominio que a los certificados TLS públicos, lo que elimina la brecha que deja la emisión manual y única.

¿Cómo deberían las organizaciones medir el éxito?

El éxito se define por la ausencia total de interrupciones no planificadas de LDAPS, que cada controlador de dominio posea un certificado válido con la EKU de autenticación de servidor correcta mucho antes de su vencimiento, que la validación de ldp.exe se complete sin errores de Schannel o CAPI2, y que la vinculación de canales o la firma LDAP se apliquen sin afectar a los clientes heredados.

¿Qué se debe auditar o supervisar periódicamente?

Audite la caducidad del certificado en cada enlace LDAPS, los eventos Schannel en el rango 36870 a 36888, la accesibilidad CRL y OCSP desde cada controlador de dominio, qué clientes aún recurren al puerto 389 sin cifrar y si la aplicación del enlace de canal coincide con su política documentada.

¿Cómo afecta este tema a las infraestructuras de clave pública (PKI) en la nube, híbridas o con múltiples autoridades de certificación (CA)?

En implementaciones híbridas o en la nube, los controladores de dominio aún necesitan un certificado de una CA en la que confíe cada cliente, lo cual es más difícil de garantizar entre regiones y límites de red. Las jerarquías de múltiples CA requieren que la plantilla de cada CA emisora ​​regional se encadene a la misma raíz de confianza; de lo contrario, la validación LDAPS fallará para los clientes ubicados en una región diferente a la del controlador de dominio.

¿Qué requisitos previos son necesarios antes de la implementación?

Necesitas una jerarquía PKI saludable sin errores en PKIView.msc, una CA emisora ​​accesible desde cada servidor de destino, derechos de administrador empresarial, una plantilla de certificado que contenga la EKU de autenticación de servidor y acceso de red abierto al puerto 636 (o 50001 para AD LDS).

¿Qué errores comunes deben tener en cuenta los administradores?

Esté atento a los eventos Schannel 36870 y 36872 debido a un certificado defectuoso, ACL de clave, cadena, SAN o problema de caducidad; fallos de conexión de ldp.exe debido a un puerto bloqueado o un certificado faltante; un certificado al que le falta la EKU de autenticación del servidor; una cadena de confianza rota en el cliente; y fallos de recuperación de CRL u OCSP durante el protocolo de enlace TLS.