Cómo configurar la autenticación de AD con LDAP a través de proxy con TLS / SSL

Tanto Active Directory (AD) como OpenLDAP juegan un papel importante en la empresa. De hecho, dentro de la misma empresa, encontrará el grupo UNIX que usa OpenLDAP y los administradores de LAN y Windows que usan AD. Sin embargo, la mayoría de las personas no pueden acceder por completo al esquema de AD a través de OpenLDAP. En este artículo, consideraremos cómo configurar la autenticación de Active Directory con LDAP sobre proxy con seguridad de la capa de transporte / SSL.

OpenLDAP y AD pueden coexistir pacíficamente; la clave es encontrar la mejor manera de permitir que las operaciones LDAP crucen los límites entre las implementaciones de AD y OpenLDAP. Una forma de hacer que esto suceda es configurar la autenticación de Active Directory con LDAP sobre TLS / SSL. Nuestro principal objetivo es integrar nuestro LDAP con Active Directory. Incluiremos algunos esquemas en el archivo de configuración principal y agregaremos los parámetros requeridos.

Antes de empezar

Antes de continuar, definamos la terminología. Primero, un servidor LDAP es en realidad lo que se conoce como Agente de servicio de directorio (DSA). En segundo lugar, un DSA administra parte o la totalidad de un árbol de información de directorio (DIT). Se pueden implementar varios DSA para administrar un DIT completo, así como para permitir la replicación y alta disponibilidad. La parte del DIT que administra un DSA se conoce como partición o base de datos. Usaremos el término base de datos.

Asegúrese de que OpenLDAP esté en funcionamiento

El proceso del servidor OpenLDAP se denomina slapd, que significa «demonio LDAP independiente». Proporciona casi toda la funcionalidad del servidor OpenLDAP, incluida la capacidad de aceptar conexiones de clientes LDAP, procesar consultas y actualizaciones e implementar las ACL que restringen el acceso a información confidencial dentro del directorio.

Consideremos que ya ha instalado y configurado OpenLDAP.

De acuerdo con la configuración anterior, slapd administra una base de datos para el árbol de directorios dc = example, dc = com.

Asegúrese de que el servicio slapd se esté ejecutando.

service slapd status

Ahora, probaremos que nuestras entradas (de la misma configuración de muestra proporcionada en este artículo) se cargaron correctamente mediante el comando ldapsearch.

ldapsearch -LLL -x -h localhost -b 'dc=example,dc=com'

La opción -x especifica que ldapsearch debe usar autenticación simple en lugar de Autenticación simple y capa de seguridad (SASL). Con una autenticación simple, el cliente LDAP envía las credenciales en texto sin formato. Incluso si usa LDAP sobre SSL (LDAPS) o LDAP StartTLS, seguirá usando autenticación simple, pero el túnel que se usa para la comunicación está encriptado (y es mucho más seguro).

De vuelta al comando ldapsearch. Realiza una consulta para encontrar todas las entradas debajo de la raíz del árbol. Como se esperaba, ldapsearch devuelve todas las entradas que importamos originalmente a través de ldapadd como en el ejemplo proporcionado.

Integración con Active Directory

Hemos visto fácilmente las entradas de OpenLDAP usando el comando ldapsearch en nuestro cliente local, pero ¿qué pasa con la visualización de las entradas que se administran en Active Directory? Para que eso suceda, debe dirigir OpenLDAP a Active Directory.

Asegúrese de que todos los módulos necesarios estén incluidos en el archivo slapd.conf:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema

El siguiente paso es habilitar el proxy openLDAP como Active Directory, navegue hasta el final de slapd.conf y agregue las siguientes líneas:

database ldap
subordinate
rebind-as-user yes
uri "ldaps://ad-dc.example.com"
suffix "DC=corp,DC=ad,DC=com"
chase-referrals yes
idassert-bind bindmethod=simple
binddn="CN=ad-username,DC=corp,DC=ad,DC=com"
credentials="password"
tls_cacert=/etc/openldap/certs/certificate_file

base de datos ldap – definió un nuevo back-end usando slapd-ldap, que será nuestro servicio de proxy.

subordinar – sin esta palabra clave, slapd busca solo en la base de datos especificada por la base de búsqueda (por ejemplo, si dc = example, dc = com fuera la base de búsqueda especificada, entonces cn = users, dc = example, dc = com nunca se examinaría porque es una base de datos slapd diferente).

volver a vincular como usuario – Esta opción le dice a slapd que se vincule al Agente de servicio de directorio remoto con las credenciales proporcionadas por el cliente. Tenga en cuenta que las credenciales deben ser válidas en AD.

URI – Esto especifica el servidor LDAP remoto, que en este caso es el controlador de dominio AD.

referencias de persecución – Esta opción especifica que slapd perseguirá cualquier referencia automáticamente.

idassert-bind – Este parámetro se utiliza para vincularse al servidor remoto y, opcionalmente, autorizar otra identidad.

método de unión – Esta declaración se usa para definir qué método usa el proxy para vincularse al servidor remoto con la identidad administrativa dada.

En este caso usamos sencillo ya que se recomienda encarecidamente que TLS se utilice junto con un enlace simple. El enlace simple requiere parámetros adicionales:

binddn = «CN = ad-username, DC = corp, DC = ad, DC = com«se utiliza para especificar un DN de enlace;
credentials = «contraseña» se utiliza para especificar las credenciales de enlace;

tls_cacert – El certificado de la autoridad certificadora de seguridad de la capa de transporte define la ruta y el nombre de archivo del certificado que permite al cliente verificar el certificado del servidor LDAP. Este archivo se puede obtener del proveedor del certificado X.509 o, en caso de autofirmado, se puede copiar del servidor LDAP.

Ok, ahora los clientes serán autorizados como «CN = ad-username, DC = corp, DC = ad, DC = com«incluso si realmente se conectaron de forma anónima al proxy.

Ahora, reinicie el servicio slapd y ejecute ldapsearch nuevamente

ldapsearch -v -H "ldaps://ad-dc.example.com:636/" -b "DC=corp,DC=ad,DC=com" -s sub -D "CN=ad-username,DC=corp,DC=ad,DC=com" -w "password"

Si el comando falla, asegúrese de que:
1. Puede comunicarse con ldaps: //ad-dc.example.com: 636
2. Vincular con las credenciales proporcionadas por el cliente (lado de Active Directory)

Conclusión

Ahora debería poder adjuntar Active Directory a cualquier parte de su directorio OpenLDAP. Puede autenticar a sus usuarios de AD en aplicaciones LDAP que usan OpenLDAP o incluso proporcionar acceso a múltiples AD en su red si aún no forman parte de un bosque más grande.