Aller au contenu

LDAP et Active Directory

Drovio Server peut authentifier les utilisateurs auprès d'un annuaire LDAP ou d'un Active Directory Microsoft. Les comptes sont créés automatiquement à la première connexion, il n'y a donc rien à provisionner à la main. Le détail des champs est décrit dans la référence de configuration.

LDAP peut cohabiter avec les comptes locaux et avec le SSO. Il ne concerne que l'application Drovio, le client web ne demandant aucun compte.

Déroulement d'une connexion

Chaque connexion suit la séquence classique connexion, recherche, connexion :

  1. Drovio Server se connecte à l'annuaire avec le compte de service.
  2. Il recherche l'utilisateur sous base, à l'aide de search_filter, où {0} est remplacé par l'adresse e-mail saisie dans le formulaire.
  3. Il se connecte une seconde fois avec le nom distinctif de l'utilisateur et le mot de passe fourni. C'est cette seconde connexion qui authentifie.

Trois conséquences à garder en tête en écrivant votre filtre

  • La recherche porte sur tout le sous-arbre situé sous base.
  • Le filtre doit résoudre vers une entrée et une seule. S'il en trouve plusieurs, la connexion est refusée plutôt que de s'authentifier sur une correspondance arbitraire.
  • Les utilisateurs se connectent avec une adresse e-mail. La valeur est débarrassée de ses espaces et passée en minuscules, et elle doit être syntaxiquement valide : un simple sAMAccountName est rejeté avant même que l'annuaire soit contacté.

Seul le nom distinctif est relu depuis l'annuaire. Aucun attribut n'est récupéré, et le mécanisme de connexion est simple, si bien que Kerberos et les autres mécanismes SASL ne sont pas disponibles.

Configurer la connexion

Les réglages se trouvent sous Users dans le panneau d'administration, dans la section LDAP / Active Directory.

Champ du panneau Clé de configuration Exemple
Status enabled true
URL url ldaps://ldap.example.com:636
Service Account DN service_account_dn cn=drovio,ou=services,dc=example,dc=com
Service Account Password service_account_password
Base base ou=users,dc=example,dc=com
Search Filter search_filter voir ci-dessous
CA Certificate ca_certificate_path /etc/drovio-server/ldap-ca.pem

Le compte de service n'a besoin que du droit de rechercher dans le sous-arbre situé sous base, rien de plus.

(&(objectClass=inetOrgPerson)(mail={0}))

(&(objectClass=user)(mail={0}))

(&(objectClass=user)(userPrincipalName={0}))

La valeur livrée par défaut est (&(objectClass=*)(mail={0})). Elle fonctionne, mais restreindre la classe d'objet rend la recherche moins coûteuse et la contrainte d'unicité plus facile à satisfaire.

Les modifications prennent effet à la connexion suivante. Aucun redémarrage n'est nécessaire.

Il n'y a pas de bouton de test

Le panneau ne sait pas valider la configuration par lui-même. Enregistrez-la, faites tenter une connexion à un utilisateur, puis lisez le journal du serveur. Chaque échec y est consigné avec l'étape fautive, que le tableau de Dépannage ramène au champ à vérifier.

Se connecter en LDAPS

Utilisez ldaps:// sur le port 636. Le simple ldap:// fait circuler les identifiants en clair, et le serveur en avertit une fois dans le journal.

StartTLS n'est pas pris en charge. Les deux modes sont le clair sur ldap:// et le TLS implicite sur ldaps://.

ca_certificate_path désigne le certificat à considérer comme de confiance. Il accepte du PEM comme du DER, ainsi qu'un ensemble PEM contenant toute une chaîne. Vous pouvez y placer une autorité de certification ou directement le certificat de l'annuaire, ce qui permet de faire fonctionner un certificat auto-signé.

Le fichier remplace le magasin système, il ne le complète pas

Lorsque ca_certificate_path est renseigné, la connexion LDAP ne fait confiance qu'à ce que ce fichier contient. Un certificat d'annuaire émis par une autorité publique reconnue cesse d'être validé si sa chaîne n'y figure pas également. Laissez le réglage vide pour utiliser le magasin de confiance de Java.

Le certificat doit par ailleurs correspondre à l'hôte indiqué dans url, et le réglage n'est lu que pour les URL en ldaps://. Le renseigner à côté d'une URL en ldap:// reste sans effet.

Création automatique des comptes

À la première connexion réussie, Drovio Server crée le compte :

Champ du compte Valeur
E-mail L'adresse saisie dans le formulaire
Nom d'utilisateur La partie locale de cette adresse, jane.doe@example.com donnant jane.doe

Aucun attribut d'annuaire n'est repris, contrairement à SAML et OIDC qui disposent de leurs propres réglages email_attribute et username_attribute. Les utilisateurs peuvent changer leur nom d'utilisateur ensuite, et les connexions suivantes laissent cette modification intacte.

Aucun mot de passe n'est jamais stocké pour un compte LDAP, et aucun e-mail de vérification n'est envoyé. Les changements de mot de passe, les réinitialisations et la politique de mot de passe restent entièrement du ressort de votre annuaire : le panneau d'administration n'offre aucune édition d'identifiants pour ces comptes.

Vérifiez votre pool de licences avant d'ouvrir LDAP à un large annuaire

La création de compte suit users.license_allocation comme n'importe quel autre compte. Si aucune place n'est libre, le compte est tout de même créé, simplement sans licence. L'utilisateur en est averti dans l'application Drovio et le journal du serveur consigne :

Could not automatically allocate a license: no more free license left...

Restreindre l'accès à un groupe ou à une unité d'organisation

Il n'existe aucun réglage dédié, et il n'en faut pas. Les deux champs existants suffisent :

  • Par sous-arbre. Faites pointer base sur la branche qui contient les utilisateurs autorisés, par exemple OU=Drovio Users,DC=example,DC=com. Tout ce qui est en dehors devient invisible à la recherche.

  • Par appartenance à un groupe. Ajoutez une clause au filtre :

    (&(objectClass=user)(mail={0})(memberOf=CN=Drovio,OU=Groups,DC=example,DC=com))

    Sous Active Directory, utilisez la règle de correspondance memberOf:1.2.840.113556.1.4.1941:= plutôt que memberOf pour inclure les groupes imbriqués.

Le contrôle a lieu à chaque connexion. Retirer quelqu'un du groupe le bloque donc immédiatement. Gardez à l'esprit que le filtre doit toujours correspondre à une entrée et une seule.

Combiner avec les autres méthodes de connexion

Combinaison Comportement
LDAP et comptes locaux L'annuaire est interrogé en premier. S'il rejette les identifiants, les mêmes e-mail et mot de passe sont ensuite essayés sur le compte local
LDAP et SAML Pris en charge, ils empruntent des chemins distincts
LDAP et OIDC Pris en charge, ils empruntent des chemins distincts

Pour imposer l'authentification par le seul annuaire, désactivez users.auth.local.

Révoquer un accès

Supprimer ou désactiver le compte dans l'annuaire bloque la connexion dès la tentative suivante. Ce que cela ne fait pas, c'est supprimer quoi que ce soit côté Drovio : il n'existe aucune tâche de réconciliation. La fiche de l'utilisateur et sa place de licence subsistent toutes deux, si users.license_allocation est désactivé ou réglé en mode new_user.

Pour libérer la place, supprimez l'utilisateur depuis l'onglet Users du panneau d'administration, ou activez users.remove_inactive pour que les comptes inutilisés soient nettoyés périodiquement.

Limites d'exploitation

Quelques comportements sont figés et méritent d'être connus au moment de dimensionner le déploiement ou d'ouvrir le pare-feu :

Comportement Valeur
Connexions par authentification Deux, une pour le compte de service et une pour l'utilisateur. Elles ne sont pas mutualisées
Délai de connexion 30 secondes
Délai de lecture 60 secondes
Renvois Ignorés

Les renvois ignorés comptent dans une forêt Active Directory multi-domaines : les utilisateurs dont le compte réside dans un domaine autre que celui indiqué dans url ne sont pas trouvés. Faites plutôt pointer Drovio Server vers un catalogue global, en ldaps:// sur le port 3269, ou déployez un serveur par domaine. Le catalogue global n'expose qu'une partie des attributs, ce qui suffit ici puisque seul le nom distinctif est utilisé.