Skip to main content
Cette fonctionnalité est développée par yu-i-i/overleaf-cep. Nous proposons ici une documentation pour vous aider à la configurer.
Overleaf utilise la bibliothèque passport-ldapauth, qui est relativement ancienne ; la compatibilité LDAP ne peut donc pas être entièrement garantie. Avec certains fournisseurs d’identité LDAP (par exemple https://goauthentik.io/), des échecs de connexion peuvent survenir. C’est pourquoi, dans la mesure du possible, il est recommandé de privilégier les méthodes OAuth/SAML. Pour goauthentik, suivez le Guide pas à pas avec goauthentik ci-dessous, qui a été testé.

​
Qu’est-ce que LDAP ?

LDAP est un protocole d’authentification utilisé pour la vérification d’identité externe. Overleaf Server Pro fournit dans l’interface web un formulaire de connexion LDAP dédié, distinct de la méthode d’authentification standard. Lorsqu’un utilisateur soumet son nom d’utilisateur et son mot de passe LDAP, le backend d’Overleaf vérifie les identifiants auprès du serveur LDAP configuré, par exemple ldap://ldap:10389.

Un exemple de LDAP dans Server Pro

​
Configuration

En interne, le LDAP d’Overleaf utilise la bibliothèque passport-ldapauth. La plupart de ces options de configuration sont transmises à l’objet de configuration server, qui sert à configurer passport-ldapauth. Si vous rencontrez des difficultés pour configurer LDAP, il est utile de lire le README de passport-ldapauth pour comprendre la configuration attendue. La variable d’environnement EXTERNAL_AUTH est requise pour activer le module d’authentification LDAP. Elle indique quelles méthodes d’authentification externes sont activées. Sa valeur est une liste. Si la liste contient ldap, l’authentification LDAP est activée. Par exemple : EXTERNAL_AUTH=ldap saml Contrairement à Overleaf CEP, dans notre édition ayaka-notes, l’authentification LDAP est limitée à une pure méthode d’authentification, disponible à l’adresse http://your-overleaf.com/ldap/login. Lorsque la méthode d’authentification LDAP est utilisée et qu’un utilisateur saisit un username et un password dans le formulaire de connexion, le processus suivant est tenté :
  1. Un utilisateur LDAP est recherché dans l’annuaire LDAP à l’aide du filtre défini par OVERLEAF_LDAP_SEARCH_FILTER, puis authentifié.
  2. Si l’authentification réussit, la base de données des utilisateurs d’Overleaf est consultée pour trouver un utilisateur dont l’adresse e-mail principale correspond à celle de l’utilisateur LDAP authentifié :
    • Si un utilisateur correspondant est trouvé, le champ hashedPassword de cet utilisateur est supprimé (s’il existe). Cela garantit que l’utilisateur ne pourra plus se connecter qu’au moyen de l’authentification LDAP.
    • Si aucun utilisateur correspondant n’est trouvé, un nouvel utilisateur Overleaf est créé à partir de l’e-mail, du prénom et du nom récupérés depuis le serveur LDAP.
Pour les utilisateurs qui se connectent via LDAP, nous ne stockons pas de mots de passe hachés dans la base de données MongoDB d’Overleaf (et supprimons ceux qui existent).

​
Variables d’environnement

  • OVERLEAF_LDAP_URL (obligatoire)
    • URL du serveur LDAP.
      • Exemple : ldaps://ldap.example.com:636 (LDAP sur SSL)
      • Exemple : ldap://ldap.example.com:389 (non chiffré ou STARTTLS, si configuré).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Nom d’affichage du service d’identité LDAP, utilisé sur la page de connexion.
    • Valeur par défaut : Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • L’attribut e-mail renvoyé par le serveur LDAP, par défaut mail. Chaque utilisateur LDAP doit avoir au moins une adresse e-mail. Si plusieurs adresses sont fournies, seule la première est utilisée.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Le nom de la propriété contenant le prénom de l’utilisateur utilisé dans l’application, généralement givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Le nom de la propriété contenant le nom de famille de l’utilisateur utilisé dans l’application, généralement sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Le nom de la propriété contenant le nom complet de l’utilisateur, généralement cn. Si l’une des deux variables précédentes n’est pas définie, le prénom et/ou le nom de l’utilisateur sont extraits de cette variable. Sinon, elle n’est pas utilisée.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Le texte indicatif du formulaire de connexion, par défaut Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Si la valeur est true, les champs first_name et last_name de l’utilisateur LDAP sont mis à jour à la connexion, et le formulaire des informations utilisateur de la page /user/settings est désactivé pour les utilisateurs LDAP. Sinon, les informations ne sont récupérées qu’à la première connexion.
  • OVERLEAF_LDAP_BIND_DN
    • Le nom distinctif (DN) de l’utilisateur LDAP à utiliser pour la connexion LDAP (cet utilisateur doit pouvoir rechercher/lister les comptes sur le serveur LDAP), par exemple cn=ldap_reader,dc=example,dc=com. S’il n’est pas défini, une liaison anonyme est utilisée.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Mot de passe de OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Propriété de l’utilisateur utilisée pour la liaison avec le client, par défaut dn.
  • OVERLEAF_LDAP_SEARCH_BASE (obligatoire)
    • Le DN de base à partir duquel rechercher les utilisateurs. Par exemple, ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • Filtre de recherche LDAP permettant de trouver un utilisateur. Utilisez le littéral ‘{{username}}’ pour que le nom d’utilisateur fourni soit interpolé dans la recherche LDAP.
      • Exemple : (|(uid={{username}})(mail={{username}})) (l’utilisateur peut se connecter avec son e-mail ou son identifiant).
      • Exemple : (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • La portée de la recherche peut être base, one ou sub (par défaut).
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • Tableau JSON des attributs à récupérer depuis le serveur LDAP, par exemple ["uid", "mail", "givenName", "sn"]. Par défaut, tous les attributs sont récupérés.
  • OVERLEAF_LDAP_STARTTLS
    • Si la valeur est true, LDAP sur TLS est utilisé.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Chemin du fichier contenant le certificat de l’autorité de certification (CA) utilisé pour vérifier le certificat SSL/TLS du serveur LDAP. S’il y a plusieurs certificats, il peut s’agir d’un tableau JSON de chemins vers les certificats. Les fichiers doivent être accessibles au conteneur Docker.
      • Exemple (un certificat) : /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Exemple (plusieurs certificats) : ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Si la valeur est true, le certificat du serveur est vérifié par rapport à la liste des CA fournies.
  • OVERLEAF_LDAP_CACHE
    • Si la valeur est true, jusqu’à 100 identifiants à la fois seront mis en cache pendant 5 minutes.
  • OVERLEAF_LDAP_TIMEOUT
    • Durée pendant laquelle le client laisse les opérations s’exécuter avant expiration, en ms (par défaut : Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Durée pendant laquelle le client attend avant l’expiration des connexions TCP, en ms (par défaut : valeur par défaut du système d’exploitation).
  • OVERLEAF_LDAP_IS_ADMIN_ATT et OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Lorsque ces deux variables d’environnement sont définies, le processus de connexion définit user.isAdmin = true si le profil LDAP contient l’attribut spécifié par OVERLEAF_LDAP_IS_ADMIN_ATT et que sa valeur correspond à OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE ou est un tableau contenant OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE ; sinon, user.isAdmin est défini sur false. Si l’une de ces variables n’est pas définie, le statut d’administrateur n’est défini sur true que lors de la création de l’utilisateur administrateur dans Launchpad.
Les cinq variables suivantes servent à configurer la manière dont les contacts des utilisateurs sont récupérés depuis le serveur LDAP.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Le filtre utilisé pour rechercher, sur le serveur LDAP, les utilisateurs à charger dans les contacts. Le marqueur ‘{{userProperty}}’ dans le filtre est remplacé par la valeur de la propriété spécifiée par OVERLEAF_LDAP_CONTACTS_PROPERTY de l’utilisateur LDAP qui lance la recherche. S’il n’est pas défini, aucun utilisateur n’est récupéré depuis le serveur LDAP dans les contacts.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Indique le DN de base à partir duquel commencer la recherche des contacts. Par défaut : OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • La portée de la recherche peut être base, one ou sub (par défaut).
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Indique la propriété de l’objet utilisateur qui remplacera le marqueur ‘{{userProperty}}’ dans OVERLEAF_LDAP_CONTACTS_FILTER.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Indique la valeur de OVERLEAF_LDAP_CONTACTS_PROPERTY si la recherche est lancée par un utilisateur non LDAP. Si cette variable n’est pas définie, le filtre résultant ne correspondra à rien. La valeur * peut être utilisée comme caractère générique.
L’exemple ci-dessus charge dans les contacts de l’utilisateur LDAP actuel tous les utilisateurs LDAP ayant le même gid UNIX. Les utilisateurs non LDAP auront dans leurs contacts tous les utilisateurs LDAP ayant le gid=1000 UNIX.

​
Guide pas à pas avec goauthentik

Ce guide décrit une configuration testée avec goauthentik. Les exemples utilisent le Base DN dc=example,dc=com ; remplacez-le par le vôtre.
1

Créer un compte de liaison (bind)

Overleaf se connecte d’abord à l’annuaire avec son propre compte pour trouver l’utilisateur. Dans Authentik, ouvrez Directory > Users, cliquez sur New User, choisissez Internal User puis cliquez sur Next. Saisissez un nom d’utilisateur, par exemple ldapservice, puis cliquez sur Create :

Authentik : créer le compte de liaison

Ouvrez le nouvel utilisateur et cliquez sur Set password. Ce mot de passe va dans OVERLEAF_LDAP_BIND_CREDENTIALS :

Authentik : définir le mot de passe du compte de liaison (instance de test)

Notez le numéro de l’utilisateur dans la barre d’adresse, par exemple 19 dans …/#/identity/users/19. Vous en aurez besoin à l’étape 3.
2

Créer le fournisseur et l'application

Ouvrez Applications > Applications et cliquez sur New Application. L’assistant crée l’application et son fournisseur en même temps.1. Donnez à l’application un nom et un slug, par exemple overleaf-ldap, puis cliquez sur Next :

Authentik : nom et slug de l'application

2. Choisissez LDAP Provider et cliquez sur Next :

Authentik : choisir le fournisseur LDAP

3. Réglez Bind Mode sur Direct binding et Search Mode sur Direct querying :

Authentik : modes de liaison et de recherche du fournisseur LDAP

4. Plus bas, réglez Bind Flow sur default-authentication-flow et Base DN sur votre Base DN, par exemple dc=example,dc=com :

Authentik : flux de liaison et Base DN du fournisseur LDAP

5. Cliquez sur Next jusqu’à la dernière page et validez l’application.
3

Autoriser le compte de liaison à parcourir l'annuaire

Sans cette autorisation, le compte de liaison ne voit que lui-même, la recherche ne trouve aucun utilisateur et toutes les connexions LDAP échouent.Ouvrez le fournisseur, allez dans Permissions et cliquez sur Assign Role Object Permission. Dans Role, saisissez le numéro noté à l’étape 1 et choisissez ak-managed-role--user-<number>, puis activez Search full LDAP directory :

Authentik : accorder l'autorisation de recherche au compte de liaison (instance de test)

Le rôle affiche alors une coche sous Search full LDAP directory :

Authentik : autorisations d'un fournisseur LDAP (instance de test)

4

Lancer l'avant-poste LDAP

Authentik répond aux requêtes LDAP via un avant-poste (outpost), un conteneur distinct. Ouvrez Applications > Outposts, créez un avant-poste de type LDAP avec votre fournisseur et déployez-le comme l’indique Authentik. Il écoute sur le port 389 de l’hôte sur lequel il s’exécute. Une fois connecté, il affiche une coche verte :

Authentik : un avant-poste LDAP en fonctionnement (instance de test)

5

Renseigner les DN

La page du fournisseur affiche le Base DN et un exemple sous How to connect :

Authentik : vue d'ensemble d'un fournisseur LDAP (instance de test)

Ne recopiez pas les valeurs d’exemple telles quelles :
  • Bind DN affiche le compte avec lequel vous êtes connecté. Utilisez plutôt le compte de liaison de l’étape 1 : cn=ldapservice,ou=users,<Base DN>.
  • Search base affiche le Base DN. Utilisez ou=users,<Base DN>.
Authentik conserve sous ou=virtual-groups un groupe portant le nom de chaque utilisateur. Une recherche de (cn=alice) dans tout le Base DN trouve à la fois cn=alice,ou=users,… et cn=alice,ou=virtual-groups,…, et Overleaf refuse une connexion qui correspond à plus d’une entrée. Conservez la base de recherche ou=users,<Base DN>.
6

Vérifier la recherche

Avant de démarrer Overleaf, exécutez la recherche qu’il effectuera. Elle doit afficher exactement un dn: :
L’absence totale de dn: signifie généralement que l’autorisation de l’étape 3 est manquante.
7

Associer les administrateurs (facultatif)

Les groupes d’un utilisateur figurent dans memberOf, sous forme de DN sous ou=groups. Pour que les membres du groupe Authentik Admins deviennent administrateurs d’Overleaf :
L’indicateur d’administrateur est mis à jour à chaque connexion LDAP. Avec un attribut ou une valeur incorrects, tout administrateur qui se connecte via LDAP perd ses droits d’administrateur. Testez d’abord l’association avec un second compte administrateur.
variables.env
Dernière modification le 6 octobre 2026