Comment configurer l'authentification LDAP externe pour Zimbra

Quelles sont les modifications apportées à l'authentification LDAP externe dans Zimbra ?

L'authentification LDAP externe permet à Zimbra de vérifier le mot de passe d'un utilisateur auprès d'un autre annuaire plutôt que celui stocké dans son annuaire LDAP interne. Le guide de l'administrateur de Zimbra Daffodil (v10) indique que l'authentification LDAP externe est configurée par domaine et que cette méthode tente de se connecter à l'annuaire spécifié avec les informations d'identification de l'utilisateur. Si la connexion réussit, le mot de passe est considéré comme valide.

Cela ne convertit pas automatiquement un annuaire LDAP externe en base de données de comptes Zimbra. Zimbra conserve les données de compte spécifiques à Zimbra dans son propre annuaire. Le guide v10 précise que les utilisateurs doivent généralement exister à la fois dans Zimbra et dans l'annuaire externe, sauf si vous configurez séparément l'approvisionnement automatique.

Pour la documentation produit actuelle, consultez le Guide de l'administrateur Zimbra Daffodil v10 et le Guide de configuration Zimbra v10 .

Liste de contrôle pour une planification rapide

• Confirmez le domaine Zimbra que vous souhaitez modifier, par exemple example.com.
• Vérifiez que les mêmes utilisateurs existent déjà dans Zimbra, ou prévoyez un provisionnement automatique séparé.
• Connaître le nom d'hôte LDAP externe, le port, la méthode TLS et la chaîne de certificats.
• Sachez comment un nom d'utilisateur Zimbra correspond à un DN utilisateur dans LDAP.
• Si le DN ne peut pas être construit directement à partir du nom de connexion, préparez une base de recherche, un filtre de recherche et un compte de recherche à privilèges minimaux.
• Gardez une session d'administrateur Zimbra ouverte pendant les tests afin de pouvoir revenir rapidement en arrière.

Choisissez d'abord la méthode de mappage appropriée.

Le guide de configuration v10 actuel définit toujours les attributs search-base, search-bind, search-filter et external-DN par compte. Les anciens documents officiels du Zimbra Tech Center expliquent comment ces correspondances sont utilisées en pratique. Ces documents étant antérieurs à Daffodil, considérez-les comme un contexte opérationnel et vérifiez les détails par rapport à votre version installée avant d'effectuer une migration importante. Consultez les notes LDAP externes du Zimbra Tech Center .

Étape 1 : Enregistrez les paramètres d’authentification du domaine actuel

Exécutez les commandes d'administration en tant zimbraqu'utilisateur du système d'exploitation. Avant toute modification, notez les valeurs de domaine existantes :

su - zimbra

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

Enregistrez la sortie dans votre enregistrement de modifications. Le guide de configuration v10 répertorie les valeurs valides pour zimbraAuthMech, notamment zimbra, ldap, ad, et Kerberos ou des mécanismes personnalisés. Pour ce guide, le mécanisme cible est ldap.

Étape 2 : Vérifiez la connectivité réseau et le protocole TLS avant de modifier Zimbra.

Ne procédez pas au dépannage des mappages d'authentification tant que la connectivité de base n'est pas vérifiée. Depuis le serveur Zimbra, confirmez la résolution DNS et l'accessibilité du point de terminaison LDAP. Pour LDAPS, vous pouvez examiner la chaîne de certificats avec OpenSSL :

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

Pour un annuaire utilisant LDAP standard et StartTLS, testez le point de terminaison compatible StartTLS avec un client LDAP adapté à votre système d'exploitation. Si StartTLS ldapsearchest installé, une vérification du compte de recherche peut ressembler à ceci :

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

Le guide de l'administrateur de Zimbra v10 indique qu'un ldaps:point de terminaison doit posséder un certificat de serveur LDAP approuvé par Zimbra. Ne contournez pas la validation du certificat pour réussir le test. Installez l'autorité de certification ou la chaîne de certificats appropriée conformément à la procédure de configuration du magasin de certificats de confiance pour votre version de Zimbra.

Étape 3 : Configurer un modèle de liaison directe DN lorsque les DN des utilisateurs sont prévisibles

Voici le modèle le plus simple. Supposons que l'annuaire externe stocke les utilisateurs sous le nom « username » uid=alice,ou=people,dc=example,dc=netet que l'identifiant Zimbra soit « username » alice@example.com. Configurez le domaine comme suit :

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"

Le guide de l'administrateur décrit zimbraAuthLdapBindDnune chaîne de format permettant de déterminer le DN utilisé pour la liaison externe. La documentation officielle du Centre technique Zimbra décrit les valeurs de substitution courantes, notamment %upour la partie locale du nom d'utilisateur et %npour le nom d'utilisateur complet.

N’utilisez un modèle DN que s’il identifie de manière déterministe l’objet d’annuaire approprié. Si les utilisateurs se trouvent dans différentes unités organisationnelles ou si leur DN n’est pas dérivé de leur nom d’utilisateur, utilisez plutôt le modèle de filtre de recherche.

Étape 4 : Utiliser le mappage de filtre de recherche lorsque le DN ne peut pas être construit directement

Le mappage des filtres de recherche permet à Zimbra de localiser d'abord l'entrée utilisateur, puis de s'authentifier à l'aide du DN renvoyé. Le guide de configuration v10 définit les attributs de domaine requis pour la recherche.

Une configuration typique de type OpenLDAP est :

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"

Pour éviter d'enregistrer directement le mot de passe d'un répertoire dans l'historique du shell, stockez-le d'abord dans une variable temporaire du shell :

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

Le compte de recherche ne doit disposer que des droits de lecture nécessaires pour trouver les utilisateurs de la base configurée. Il n'a pas besoin de privilèges d'administration d'annuaire étendus.

Pour Active Directory, un filtre peut utiliser `@SWITCH` sAMAccountNameou userPrincipalName`@SWITCH`, selon votre convention de connexion. Zimbra propose également un mécanisme d'authentification Active Directory externe ; privilégiez donc le mécanisme spécifique à AD lorsqu'il correspond mieux à votre déploiement, plutôt que d'imposer systématiquement des paramètres LDAP génériques à tous les environnements AD.

Étape 5 : Vérifier ce que Zimbra a réellement stocké

Relisez les attributs du domaine après la modification :

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

Vérifiez l'absence d'erreurs de guillemets, d'un DN de base incorrect, d'un nom d'hôte inattendu ou d'une ancienne configuration résiduelle. Ne mentionnez pas le mot de passe de recherche dans la documentation, les captures d'écran, les tickets ou les transcriptions de la session.

Étape 6 : Tester auprès d’un utilisateur contrôlé avant le déploiement à grande échelle

Choisissez un compte de test non administrateur existant à la fois dans Zimbra et dans l'annuaire externe. Testez délibérément les cas suivants :

• Le mot de passe LDAP externe correct permet la connexion à Zimbra.
• Un mot de passe LDAP externe incorrect est rejeté.
• Un compte d'annuaire désactivé ou verrouillé se comporte conformément à votre politique d'annuaire.
• Un compte Zimbra inexistant ne peut pas se connecter sauf si l'approvisionnement automatique a été configuré.
• Une panne du serveur LDAP ou du réseau produit le comportement attendu.

Le dernier test est important car zimbraAuthFallbackToLocalil s'agit d'une option de domaine distincte. La documentation v10 indique que sa valeur par défaut est désactivée FALSE. Activer le basculement peut s'avérer utile pour une migration soigneusement planifiée, mais cela peut également contredire l'idée que la désactivation ou la modification d'un mot de passe dans l'annuaire externe bloque immédiatement l'accès si un ancien mot de passe Zimbra local reste valide. Considérez le basculement comme une décision de politique de sécurité, et non comme une simple option de dépannage.

Étape 7 : Déterminez si vous avez également besoin de l’approvisionnement automatique

L'authentification externe et la création de comptes sont deux fonctions distinctes. Si les nouveaux utilisateurs de l'annuaire doivent recevoir automatiquement un compte Zimbra, configurez l'approvisionnement automatique Zimbra séparément. Le guide de l'administrateur v10 décrit les modes EAGER, LAZY et MANUAL, ainsi que leurs zimbraAutoProv*attributs respectifs.

N’utilisez pas aveuglément les paramètres d’authentification pour l’approvisionnement automatique. Ce dernier dispose d’options distinctes pour l’URL, la liaison, la base de recherche, le filtrage, le mappage des noms de compte et le mappage des attributs. Commencez par sécuriser l’authentification externe pour un utilisateur existant ; concevez ensuite l’approvisionnement.

Modèles de défaillance courants et points à vérifier

Plan de retour en arrière

Si la configuration du répertoire externe empêche l'authentification normale des utilisateurs, rétablissez l'authentification interne Zimbra du domaine à l'aide d'une session d'administrateur déjà ouverte :

zmprov md example.com zimbraAuthMech zimbra

Vérifiez ensuite la valeur :

zmprov gd example.com zimbraAuthMech

Ne supprimez pas les attributs LDAP externes lors d'une restauration d'urgence, sauf raison valable. Leur conservation facilite l'analyse des erreurs et la reprise de l'opération après correction du mappage ou du problème TLS.

Résumé de référence pratique

• zimbraAuthMech: sélectionne le mécanisme d'authentification pour le domaine.
• zimbraAuthLdapURL: point de terminaison LDAP externe ; à utiliser ldaps:pour LDAP sur SSL.
• zimbraAuthLdapBindDn: format utilisé pour construire le DN utilisateur pour la liaison directe.
• zimbraAuthLdapSearchBase: sous-arbre dans lequel Zimbra recherche l'utilisateur externe.
• zimbraAuthLdapSearchFilterFiltre LDAP utilisé pour localiser l'utilisateur.
• zimbraAuthLdapSearchBindDnet zimbraAuthLdapSearchBindPassword: les informations d'identification utilisées pour la recherche lorsque la recherche anonyme n'est pas appropriée.
• zimbraAuthLdapExternalDn: mappage DN externe explicite pour un seul compte Zimbra.
• zimbraAuthFallbackToLocal: détermine si Zimbra utilise l'authentification locale en cas d'échec de l'authentification externe.

Liste de contrôle de validation finale

• Le point de terminaison LDAP externe est accessible depuis le serveur de messagerie Zimbra.
• La validation du certificat TLS réussit sans recourir à des solutions de contournement non sécurisées.
• Le modèle bind-DN ​​ou le filtre de recherche choisi associe une connexion à une seule entrée d'annuaire.
• L'utilisateur de test existe dans Zimbra ou l'approvisionnement automatique est configuré intentionnellement.
• Les tests de mots de passe corrects et incorrects se comportent comme prévu.
• Le comportement de repli correspond à votre politique de sécurité.
• Les paramètres de domaine d'origine et la commande de restauration sont documentés.

Pour les modifications en production, privilégiez un déploiement progressif avec un domaine de test ou un petit groupe d'utilisateurs. L'authentification LDAP externe est simple lorsque le mappage des identités est prévisible ; les échecs les plus complexes proviennent du mappage DN, de la confiance accordée aux certificats ou d'une confusion entre l'authentification et la création de comptes.