¿LDAP o LDAPS? Hardening con LDAP cifrado en tu Directorio Activo

Hoy os traigo una "pequeña" (esto lo escribí al principio) guía en la que aprenderemos a diferenciar LDAP, LDAPS y LDAP seguro. El objetivo final es que entendamos esas diferencias, las pongamos en práctica y, finalmente auditemos y preparemos nuestro entorno para aplicar uno de los controles CIS más importantes de AD:

2.3.5.4 Security Options: Domain controller: LDAP server signing requirements recommended state is Require signing

LDAP, LDAPS y LDAP Seguro

Empezamos con la cuestión: ¿qué diferencias hay entre LDAP, LDAPS y LDAP seguro? A decir verdad, en Internet podemos encontrarnos con explicaciones ambiguas y contradictorias, por lo que sólo trataré de resaltar esas diferencias:

• LDAP: Es el protocolo básico. Va por el puerto 389 y nos permitirá elegir entre ir firmado o no.

• LDAPS: Es una extensión de LDAP que permite cifrar las comunicaciones con un certificado TLS. Va por el puerto 636.

• LDAP Seguro: En ocasiones este término es referido como un sinónimo de LDAPS, mientras que en otras ocasiones se interpreta como el uso de LDAP con condiciones de seguridad (firma y sellado).

Ahora bien, ¿a qué se refiere el control CIS antes mencionado? Pues a LDAP cifrado... sería un poco el segundo concepto que hemos dado de LDAP Seguro. Para cumplir el control CIS se requiere de, o bien usar LDAPS, o bien de usar LDAP firmado. Por lo que si te preguntan: no, esto no significa que se tenga que usar obligatoriamente LDAPS en todo el dominio. LDAP seguirá siendo usado. Además, no se recomienda de cerrar puertos o tratar de bloquear LDAP, puesto que es contrario a la arquitectura de Active Directory.

Políticas para requerir LDAP firmado y/o sellado

AD cuenta con políticas para requerir LDAP firmado y/o sellado tanto para el servidor (DC) como para el cliente. Para el primero disponemos de dos distintas, mientras que para el lado cliente tenemos otras dos más.

Tanto para el lado de los Controladores de Dominio como para el lado del cliente, cabe destacar que desde Windows Server 2022 23H2, se ha sumado nuevas directivas de seguridad que, por defecto, fuerzan el firmado de LDAP en Windows Server 2022 23H2 y Windows Server 2025. Repasamos todas estas configuraciones:

1ª Política para DCs

• Ruta: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directiva: "Domain controller: LDAP server signing requirements"

• Valores: "Never", "Require Signing"

Clave de registro equivalente

• Ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

• Clave: LDAPServerIntegrity

• DWORD

• Valores: 1,2

Según el valor que elijamos, estos serán los comportamientos:

None (1)

Con este valor, se permiten las conexiones LDAP más inseguras:

• Simple Bind con LDAP (389).

• Bind con SASL sin firmar con LDAP (389).

Require Signing (2)

Con este valor, las conexiones anteriores quedan prohibidas, quedando usables el resto:

• Cualquier tipo de bind con LDAPS (636).

• Bind con SASL firmado con LDAP (389).

2ª política para DCs (WS2022 23H2 y WS2025)

• Ruta: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directiva: "Domain controller: LDAP server signing requirements Enforcement"

• Valores: "Disabled", "Enabled"

Clave de registro equivalente

• Ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

• Clave: LDAPServerEnforceIntegrity

• DWORD

• Valores: 0, 1

Según el valor que elijamos, estos serán los comportamientos:

Disabled (0)

Con este valor, la clave de registro LDAPServerIntegrity toma el control de las acciones.

Enabled (1)

Con este valor sólo se permiten las siguientes conexiones:

• Cualquier tipo de bind con LDAPS (636).

• Bind con SASL firmado con LDAP (389).

1ª política para clientes

• Ruta: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directiva: "Network security: LDAP client signing requirements"

• Valores: "None", "Negotiate Signing", "Require Signing"

Clave de registro equivalente

• Ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\

• Clave: LDAPClientIntegrity

• DWORD

• Valores: 0, 1, 2

Según el valor que elijamos, estos serán los comportamientos:

None (0)

Con este valor se permiten conexiones LDAP sin estar firmadas.

Negotiate Signing (1)

Con este valor se permite elegir al usuario si se realiza firma de LDAP o no, pero sólo en el caso de que use TLS (636). En caso contrario, la firma se hará obligatoria.

Require Signing (2)

Con este valor se obliga a firmar todas las conexiones LDAP, tanto sean con TLS como sino.

2ª política para clientes (WS2022 23H2, WS2025 y W11)

• Ruta: Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options

• Directiva: "Network security: LDAP client encryption requirements"

• Valores: "None", "Negotiate Sealing", "Require Sealing"

Clave de registro equivalente

• Ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\

• Clave: LDAPClientConfidentiality

• DWORD

• Valores: 0, 1, 2

None (0)

Con este valor se permiten conexiones LDAP sin estar selladas.

Negotiate Sealing (1)

Con este valor se permite elegir al usuario si se realiza sellado de LDAP o no, pero sólo en el caso de que use TLS (636). En caso contrario, el sellado y la firma serán obligatorios.

Require Sealing (2)

Con este valor se obliga a firmar y sellar todas las conexiones LDAP, tanto sean con TLS como sino.

Auditoría de LDAP

Tanto para realizar pruebas como para ver aquellos equipos que consumen LDAP de forma insegura, recomendamos modificar esta clave de registro en los Controladores de Dominio:

• Ruta: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

• Clave: 16 LDAP Interface Events

• DWORD

• Valor: 0x2 o más

Tras completar las pruebas/auditoría podemos revertir el valor al que teníamos antes.

Cómo comprobar la política

En un entorno de laboratorio podemos configurar las políticas y claves de registro y provocar errores con aquellas conexiones que no se ajusten a los estándares de seguridad que ya hemos descrito.

Para hacer estas pruebas necesitaremos:

• Varias máquinas. Nosotros hemos usado hasta 4 distintas, aunque según las pruebas que se quieran realizar, se puede disminuir el número hasta 1. Estas son las que usamos nosotros: DC con WS2025, DC con WS2022 21H2, Member server con rol de ADDS instalado y WS2025 y Member Server con rol de ADDS instalado y WS2019.

• Un certificado LDAPS válido en el DC. Desde una CA de Windows Server podemos usar la plantilla "Kerberos Authentication" para ello.

• Atender al orden marcado por las políticas de nuestro dominio. La Default Domain Controllers Policy tiene "Domain controller: LDAP server signing requirements" con valor None por defecto. Para pasar por encima de esto recomiendo poner una mayor prioridad a las políticas que vamos a crear.

• La clave de registro 16 LDAP Interface Events con valor 0x2 para mejorar la auditoría y obtener así eventos que correlacionen las acciones que realizamos con su resultado.

• Una herramienta de examinación de tráfico de red como Wireshark nos puede ser útil para observar el comportamiento real de LDAP.

Desde un cliente accederemos a ldp.exe y haremos el siguiente set de pruebas en cada uno de los próximos apartados:

• Simple Bind.

• Bind SASL con NTLM y sin marcar el check de encriptar tráfico.

• Bind SASL con NTLM y marcando el check de encriptar tráfico.

Cada prueba requiere de una nueva conexión (Connection/Disconnect) y que vayamos a través del puerto 389 sin SSL o del puerto 636 con SSL.

Pruebas en entorno de laboratorio

Para las pruebas estaremos modificando continuamente estas cuatro políticas:

• Domain controller: LDAP server signing requirements Enforcement (WS2022 23H2 o WS2025)

• Domain controller: LDAP server signing requirements

• Network security: LDAP client encryption requirements (WS2022 23H2, WS2025 o W11)

• Network security: LDAP client signing requirements

Tal y como resaltamos, hay dos políticas exclusivas de las nuevas versiones de Windows Server. Por otra parte, en el caso de las políticas de cliente se requiere de un reinicio de la máquina para su correcto funcionamiento.

Prueba 1: Modo inseguro

Empezaremos con las pruebas inseguras, por lo que pondremos todas las políticas con valor None y Disabled.

Estos deberían de ser los resultados en eventos y traza de red:

• LDAP con Simple Bind: En el DC tenemos el evento 2889 con binding type 1. En la traza de red se ve la contraseña en texto claro.

• LDAP con Bind SASL (NTLM) y tráfico sin encriptar: En el DC tenemos el evento 2889 con binding type 0. En la traza de red se ve el flag Negotiate Sign en valor 0.

• LDAP con NTLM y tráfico encriptado: En el DC no tenemos evento 2889. En la traza de red se ve el flag Negotiate Sign en valor 1.

• LDAPS con cualquier bind: En el DC no tenemos evento 2889. En la traza de red se ve todo encriptado con TLS.

En todos los casos el bind se permitirá y posteriormente nos dejaría realizar consultas LDAP.

Prueba 2: Require Signing en DCs

En esta ocasión la política de Domain Controller la dejamos con valor Require Signing (2). En WS2022 23H2 y WS2025 podemos optar por poner en Enabled (1) su política de Enforcement. Tras un gpupdate ya podemos ver sus efectos en las pruebas. Lo único en lo que diferirá con las pruebas anteriores es que ya no se nos permitirá:

• LDAP con Simple Bind

• LDAP con Bind SASL y tráfico sin encriptar.

En la salida de ldp.exe veremos errores como este:

0 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 0)
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NTLM (4230)); // v.3
{NtAuthIdentity: User='adrian'; Pwd=<unavailable>; domain = 'lab1.local'}
Error <8>: ldap_bind_s() failed: Strong Authentication Required.
Server error: 00002028: LdapErr: DSID-0C090343, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v65f4
Error 0x2028 A more secure authentication method is required for this server.

Este bloqueo nos impedirá proseguir con consultas LDAP; el bind no es válido.

Prueba 3: Negotiate/Require Signing en cliente

Volvemos a poner la política de Domain Controller con valor None (1) y/o Disabled (0) y modificamos la del lado cliente para poner el valor Negotiate Signing (1). Reiniciamos el cliente. Los resultados ahora son ligeramente distintos:

• LDAP con Simple Bind: En el DC tenemos el evento 2889 con binding type 1. En la traza de red se ve la contraseña en texto claro.

• LDAP con Bind SASL (NTLM) y tráfico sin encriptar: En el DC no tenemos evento 2889. En la traza de red se ve el flag Negotiate Sign en valor 1.

En el caso del Simple Bind, se vuelve a permitir incluso sin encriptar. Por la parte de SASL, a pesar de que no marcamos el check de cifrar tráfico tras el bind, la política nos obliga a hacerlo. En este estado da lo mismo que la marquemos a que no; el SO siempre firmará LDAP.

Si en la política pusiésemos Require Signing (2), a priori la prueba seguiría dándonos el mismo resultado. La diferencia estaría en el caso de usar LDAPS, pero para ver las diferencias tendríamos que descifrar el tráfico TLS. Si no marcásemos el check "Encrypt traffic after bind" y viésemos la traza, observaríamos que con Negotiate Signing se nos haría caso (Negotiate Sign con valor 0), mientras que con Require Signing no (Negotiate Sign con valor 1).

Prueba 4: Negotiate/Require Sealing en cliente (WS2022 23H2, WS2025 o W11)

Volviendo a poner la política de Signing en None, en los nuevos Sistemas Operativos de Microsoft tenemos la posibilidad de comprobar un nuevo comportamiento con la política de “client encryption requirements”. Si la marcamos con Negotiate Sealing o Require Sealing, apreciaremos esta diferencia en la traza de red:

• LDAP con Bind SASL (NTLM) y tráfico sin encriptar: En el DC no tenemos evento 2889. En la traza de red se ve los flags Negotiate Sign y Negotiate Seal en valor 1.

En otras palabras, esta política añade una capa más de seguridad, forzando el firmado de LDAP al igual que hace la anterior, pero también forzando el sellado de LDAP.

Cómo seguir el proceso de hardening en un entorno de producción

Forzar el uso de LDAP firmado es poco menos que un imperativo legal. Microsoft ha lanzado nuevos productos como Windows 11 y Windows Server 2025 donde por defecto las comunicaciones LDAP sin firmar y sin encriptar desaparecen. Hace falta modificar varias políticas para mantener la compatibilidad, y probablemente en un futuro Microsoft fuerce a que se use LDAP firmado o encriptado.

Ahora bien, todo cambio lleva un proceso. En un inicio recomendamos auditar los eventos 2889 y aplicar las políticas de hardening del lado cliente en todos aquellos equipos que no reportan comunicaciones LDAP inseguras.

Para los equipos que sí provocan eventos 2889, deberemos contactar con sus responsables (tenemos nombre, IP y cuenta usada) para revisar dónde se usa LDAP sin cifrar, así como determinar un plazo razonable para retirarlo. Probablemente nos encontremos con aplicaciones que no funcionen sin esta mejora de seguridad. En este sentido tocará valorar el desembolso económico que supondrá ir migrándolas, de cara a tener terminada la migración en X fecha. El motivo económico puede suponer un retraso en el hardening, pero nunca debería de ser un impedimento… ¿o acaso pensamos en mantener una vulnerabilidad grave dentro de 10 años?

Si siguen apareciendo eventos 2889 y no somos capaces de identificar por qué, siempre se puede optar por una aplicación granulada de las políticas de Controladores de Dominio. También se puede aplicar por un tiempo prudencial (por ejemplo, 8 horas) para ver si hay un impacto, avisando a los responsables de las máquinas a que estén atentos a los problemas que puedan reportarse. El objetivo final tiene que ser que todas las máquinas del dominio tengan “Require Signing” + “Require Sealing”, mientras que los DCs tengan “Require Signing” así como la política de forzado en “Enabled”.

Fuentes de interés

How to enable LDAP signing - Windows Server | Microsoft Learn

2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows (KB4520412) - Microsoft Support

AD and LDS diagnostic event logging - Windows Server | Microsoft Learn

LDAP Channel Binding and LDAP Signing Requirements - Server 2025 updates | Microsoft Community Hub

Active Directory Hardening Series - Part 3 – Enforcing LDAP Signing | Microsoft Community Hub