Cómo configurar la autenticación LDAP externa para Zimbra

¿Qué cambios introduce la autenticación LDAP externa en Zimbra?

La autenticación LDAP externa permite a Zimbra verificar la contraseña de un usuario con otro directorio en lugar de la contraseña almacenada en el LDAP interno de Zimbra. La Guía del administrador de Zimbra Daffodil (v10) indica que la autenticación LDAP externa se configura por dominio y que el método externo intenta conectarse al directorio especificado con las credenciales de usuario proporcionadas. Si la conexión es exitosa, la contraseña se considera válida.

Esto no convierte automáticamente un directorio LDAP externo en la base de datos de cuentas de Zimbra. Zimbra sigue almacenando los datos de cuenta específicos de Zimbra en su propio directorio. La guía de la versión 10 indica explícitamente que, por lo general, los usuarios deben existir tanto en Zimbra como en el directorio externo, a menos que se configure el aprovisionamiento automático por separado.

Para consultar la documentación actual del producto, vea la Guía del administrador de Zimbra Daffodil v10 y la Guía de configuración de Zimbra v10 .

Lista de verificación para una planificación rápida

• Confirme el dominio de Zimbra que desea cambiar, por ejemplo example.com.
• Confirme que los mismos usuarios ya existen en Zimbra, o bien, planifique el aprovisionamiento automático por separado.
• Conozca el nombre de host LDAP externo, el puerto, el método TLS y la cadena de certificados.
• Sepa cómo se asigna un nombre de inicio de sesión de Zimbra a un DN de usuario en LDAP.
• Si el DN no se puede construir directamente a partir del nombre de inicio de sesión, prepare una base de búsqueda, un filtro de búsqueda y una cuenta de búsqueda con privilegios mínimos.
• Mantén abierta una sesión de administrador de Zimbra durante las pruebas para poder revertir los cambios rápidamente.

Primero, elige el método de mapeo correcto.

La guía de configuración v10 actual aún define los atributos search-base, search-bind, search-filter y external-DN por cuenta. El material oficial anterior del Centro de Tecnología de Zimbra explica cómo se utilizan estas asignaciones en la práctica. Dado que dicho material es anterior a Daffodil, considérelo como información de referencia operativa y verifique los detalles con la versión instalada antes de realizar una migración importante. Consulte las notas oficiales del Centro de Tecnología de Zimbra sobre LDAP externo .

Paso 1: Registre la configuración actual de autenticación de dominio.

Ejecute los comandos administrativos como zimbrausuario del sistema operativo. Antes de realizar cualquier cambio, capture los valores de dominio existentes:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

Guarde el resultado en su registro de cambios. La Guía de configuración v10 enumera valores válidos para zimbraAuthMech, incluidos zimbra, ldap, ad, y Kerberos o mecanismos personalizados. Para esta guía, el mecanismo de destino es ldap.

Paso 2: Verifique la accesibilidad de la red y TLS antes de cambiar Zimbra.

No solucione problemas de asignación de autenticación hasta que se confirme que la conectividad básica funciona. Desde el servidor Zimbra, confirme la resolución DNS y que el punto final LDAP sea accesible. Para LDAPS, puede inspeccionar la cadena de certificados con OpenSSL.

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

Para un directorio que utiliza LDAP estándar más StartTLS, pruebe el punto final compatible con StartTLS con un cliente LDAP adecuado para su sistema operativo. Si ldapsearchestá instalado, una comprobación de la cuenta de búsqueda puede tener este aspecto:

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

La guía del administrador de Zimbra v10 indica que un ldaps:punto final requiere que el certificado del servidor LDAP sea de confianza para Zimbra. No omita la validación del certificado solo para que la prueba pase. Instale la CA o la cadena de certificados adecuada según el procedimiento de almacén de confianza para su versión específica de Zimbra.

Paso 3: Configure una plantilla de enlace directo DN cuando los DN de usuario sean predecibles.

Este es el patrón más simple. Supongamos que el directorio externo almacena los usuarios como uid=alice,ou=people,dc=example,dc=nety el inicio de sesión de Zimbra es alice@example.com. Configure el dominio de esta manera:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

La Guía del administrador describe zimbraAuthLdapBindDncomo una cadena de formato utilizada para determinar el DN utilizado para el enlace externo. La documentación oficial del Centro de tecnología de Zimbra describe valores de sustitución comunes, como %upara la parte local del nombre de inicio de sesión y %npara el nombre de inicio de sesión completo.

Utilice una plantilla DN solo cuando identifique de forma determinista el objeto de directorio correcto. Si los usuarios se encuentran en diferentes unidades organizativas o su DN no se deriva del nombre de inicio de sesión, utilice el patrón de filtro de búsqueda.

Paso 4: Utilice la asignación de filtros de búsqueda cuando el DN no se pueda construir directamente.

El mapeo de filtros de búsqueda permite a Zimbra localizar primero la entrada del usuario y luego autenticarse contra el DN devuelto. La Guía de configuración v10 define los atributos de dominio necesarios relacionados con la búsqueda.

Una configuración típica al estilo OpenLDAP es:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

Para evitar guardar la contraseña de un directorio directamente en el historial de la consola, primero guárdela en una variable temporal de la consola:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

La cuenta de búsqueda solo debe tener el acceso de lectura necesario para encontrar usuarios en la base configurada. No necesita privilegios amplios de administración de directorios.

Para Active Directory, un filtro podría usar sAMAccountNameo userPrincipalName, según su convención de inicio de sesión. Zimbra también proporciona un mecanismo de autenticación externo de Active Directory, así que utilice el mecanismo específico de AD cuando se ajuste mejor a su implementación en lugar de forzar todos los entornos de AD a través de configuraciones LDAP genéricas.

Paso 5: Verificar qué información almacenó realmente Zimbra

Lee los atributos del dominio después del cambio:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

Verifique si hay errores de comillas, un DN base incorrecto, un nombre de host inesperado o una asignación antigua que haya quedado de un intento anterior. No imprima la contraseña de búsqueda-bind en la documentación, capturas de pantalla, tickets o transcripciones de la consola.

Paso 6: Realice una prueba con un usuario controlado antes de la implementación a gran escala.

Elija una cuenta de prueba que no sea de administrador y que exista tanto en Zimbra como en el directorio externo. Pruebe estos casos deliberadamente:

• La contraseña LDAP externa correcta permite iniciar sesión en Zimbra.
• Se rechaza una contraseña LDAP externa incorrecta.
• Una cuenta de directorio deshabilitada o bloqueada se comporta de acuerdo con la política de directorio.
• Una cuenta de Zimbra inexistente no puede iniciar sesión a menos que se haya configurado el aprovisionamiento automático.
• Un fallo en el servidor LDAP o en la red produce el comportamiento de fallo esperado.

La última prueba es importante porque zimbraAuthFallbackToLocales una opción de dominio independiente. La documentación de la versión 10 indica que su valor predeterminado es FALSE. Habilitar la opción de reserva puede ser útil para una migración cuidadosamente planificada, pero también puede contradecir la expectativa de que deshabilitar o cambiar una contraseña en el directorio externo bloquee inmediatamente el acceso si una contraseña antigua de Zimbra local sigue siendo válida. Considere la opción de reserva como una decisión de política de seguridad, no como una solución de problemas genérica.

Paso 7: Decide si también necesitas el aprovisionamiento automático.

La autenticación externa y el aprovisionamiento de cuentas son funciones distintas. Si los nuevos usuarios del directorio deben recibir cuentas de Zimbra automáticamente, configure el aprovisionamiento automático de Zimbra por separado. La Guía del administrador de la versión 10 actual documenta los modos EAGER, LAZY y MANUAL, así como sus respectivos zimbraAutoProv*atributos.

No reutilice indiscriminadamente la configuración de autenticación para el aprovisionamiento automático. El aprovisionamiento automático cuenta con opciones independientes para URL, enlace, base de búsqueda, filtro, asignación de nombre de cuenta y asignación de atributos. Primero, establezca la autenticación externa como confiable para un usuario existente; luego, diseñe el aprovisionamiento como un segundo cambio.

Patrones de fallos comunes y qué comprobar

Plan de reversión

Si la configuración del directorio externo impide la autenticación normal del usuario, vuelva a cambiar el dominio a la autenticación interna de Zimbra utilizando una sesión de administrador que ya esté abierta:

zmprov md example.com zimbraAuthMech zimbra

Luego verifique el valor:

zmprov gd example.com zimbraAuthMech

No elimine los atributos LDAP externos durante una reversión de emergencia a menos que tenga un motivo para hacerlo. Mantenerlos facilita la inspección de lo que falló y permite volver a intentarlo después de corregir el problema de asignación o TLS.

Resumen de referencia práctica

• zimbraAuthMech: selecciona el mecanismo de autenticación para el dominio.
• zimbraAuthLdapURL: punto final LDAP externo; úselo ldaps:para LDAP sobre SSL.
• zimbraAuthLdapBindDn: formato utilizado para construir el DN de usuario para la vinculación directa.
• zimbraAuthLdapSearchBase: subárbol en el que Zimbra busca al usuario externo.
• zimbraAuthLdapSearchFilter: Filtro LDAP utilizado para localizar al usuario.
• zimbraAuthLdapSearchBindDny zimbraAuthLdapSearchBindPassword: credenciales utilizadas para la búsqueda cuando la búsqueda anónima no es apropiada.
• zimbraAuthLdapExternalDn: Asignación explícita de DN externo para una única cuenta de Zimbra.
• zimbraAuthFallbackToLocal: controla si Zimbra recurre a la autenticación local en caso de que falle la autenticación externa.

Lista de verificación de validación final

• Se puede acceder al punto final LDAP externo desde el servidor de buzones de Zimbra.
• La validación del certificado TLS se realiza correctamente sin necesidad de soluciones alternativas inseguras.
• La plantilla bind-DN ​​o el filtro de búsqueda seleccionado asigna un inicio de sesión a una única entrada de directorio.
• El usuario de prueba existe en Zimbra o el aprovisionamiento automático está configurado intencionalmente.
• Las pruebas de contraseñas correctas e incorrectas se comportan como se espera.
• El comportamiento de reserva se ajusta a su política de seguridad.
• La configuración original del dominio y el comando de reversión están documentados.

Para cambios en producción, es preferible un despliegue gradual con un dominio de prueba o un grupo pequeño de usuarios. La autenticación LDAP externa es sencilla cuando la asignación de identidades es predecible; la mayoría de los fallos más difíciles se deben a la asignación de nombres distintivos (DN), la confianza en los certificados o la confusión entre la autenticación y el aprovisionamiento de cuentas.