Skip to main content
Diese Funktion wurde von yu-i-i/overleaf-cep entwickelt. Hier stellen wir einige Dokumente für Ihre Konfiguration bereit.
Overleaf verwendet die Bibliothek passport-ldapauth, die relativ veraltet ist; die LDAP-Kompatibilität kann daher nicht vollständig garantiert werden. Bei bestimmten LDAP-Identitätsanbietern (zum Beispiel https://goauthentik.io/) können Anmeldefehler auftreten. Wenn möglich, wird daher empfohlen, vorrangig OAuth/SAML zu verwenden. Für goauthentik folgen Sie der unten stehenden, getesteten Anleitung Schritt für Schritt: goauthentik.

​
Was ist LDAP?

LDAP ist ein Authentifizierungsprotokoll zur externen Identitätsprüfung. Overleaf Server Pro bietet in der Weboberfläche ein eigenes LDAP-Anmeldeformular, getrennt von der Standard-Authentifizierungsmethode. Wenn ein Benutzer seinen LDAP-Benutzernamen und sein Passwort übermittelt, prüft das Overleaf-Backend die Zugangsdaten gegen den konfigurierten LDAP-Server, zum Beispiel ldap://ldap:10389.

Ein Server Pro-Beispiel für LDAP

​
Konfiguration

Intern verwendet Overleaf LDAP die Bibliothek passport-ldapauth. Die meisten dieser Konfigurationsoptionen werden an das Konfigurationsobjekt server durchgereicht, mit dem passport-ldapauth konfiguriert wird. Wenn Sie Probleme bei der LDAP-Konfiguration haben, lohnt es sich, die README von passport-ldapauth zu lesen, um ein Gefühl für die erwartete Konfiguration zu bekommen. Die Umgebungsvariable EXTERNAL_AUTH ist erforderlich, um das LDAP-Authentifizierungsmodul zu aktivieren. Diese Umgebungsvariable legt fest, welche externen Authentifizierungsmethoden aktiviert sind. Der Wert dieser Variablen ist eine Liste. Enthält die Liste ldap, wird die LDAP-Authentifizierung aktiviert. Zum Beispiel: EXTERNAL_AUTH=ldap saml Anders als bei Overleaf CEP beschränken wir in unserer ayaka-notes-Edition die LDAP-Authentifizierung auf eine reine Authentifizierungsmethode, die unter http://your-overleaf.com/ldap/login verfügbar ist. Wenn bei der LDAP-Authentifizierung ein Benutzer im Anmeldeformular einen username und ein password eingibt, geschieht Folgendes:
  1. Im LDAP-Verzeichnis wird mit dem durch OVERLEAF_LDAP_SEARCH_FILTER definierten Filter nach einem LDAP-Benutzer gesucht, der dann authentifiziert wird.
  2. Ist die Authentifizierung erfolgreich, wird in der Overleaf-Benutzerdatenbank nach einem Benutzer gesucht, dessen primäre E-Mail-Adresse mit der E-Mail-Adresse des authentifizierten LDAP-Benutzers übereinstimmt:
    • Wird ein passender Benutzer gefunden, wird das Feld hashedPassword dieses Benutzers gelöscht (falls vorhanden). So wird sichergestellt, dass sich der Benutzer künftig nur noch über die LDAP-Authentifizierung anmelden kann.
    • Wird kein passender Benutzer gefunden, wird ein neuer Overleaf-Benutzer mit der E-Mail-Adresse sowie dem Vor- und Nachnamen angelegt, die vom LDAP-Server abgerufen werden.
Für Benutzer, die sich über LDAP anmelden, speichern wir keine gehashten Passwörter in der Overleaf-MongoDB-Datenbank (bzw. entfernen vorhandene).

​
Umgebungsvariablen

  • OVERLEAF_LDAP_URL (erforderlich)
    • URL des LDAP-Servers.
      • Beispiel: ldaps://ldap.example.com:636 (LDAP über SSL)
      • Beispiel: ldap://ldap.example.com:389 (unverschlüsselt oder STARTTLS, falls konfiguriert).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Anzeigename für den LDAP-Identitätsdienst, der auf der Anmeldeseite verwendet wird.
    • Standardwert: Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • Das vom LDAP-Server zurückgegebene E-Mail-Attribut, standardmäßig mail. Jeder LDAP-Benutzer muss mindestens eine E-Mail-Adresse haben. Werden mehrere Adressen geliefert, wird nur die erste verwendet.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Der Name der Eigenschaft, die den in der Anwendung verwendeten Vornamen des Benutzers enthält, in der Regel givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Der Name der Eigenschaft, die den in der Anwendung verwendeten Nachnamen des Benutzers enthält, in der Regel sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Der Name der Eigenschaft, die den vollständigen Namen des Benutzers enthält, in der Regel cn. Ist eine der beiden vorherigen Variablen nicht definiert, werden Vor- und/oder Nachname des Benutzers aus dieser Variablen extrahiert. Andernfalls wird sie nicht verwendet.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Der Platzhalter für das Anmeldeformular, standardmäßig Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Wenn auf true gesetzt, werden die Felder first_name und last_name des LDAP-Benutzers bei der Anmeldung aktualisiert, und das Formular für Benutzerdetails auf der Seite /user/settings wird für LDAP-Benutzer deaktiviert. Andernfalls werden die Details nur bei der ersten Anmeldung abgerufen.
  • OVERLEAF_LDAP_BIND_DN
    • Der Distinguished Name des LDAP-Benutzers, der für die LDAP-Verbindung verwendet werden soll (dieser Benutzer sollte Konten auf dem LDAP-Server suchen/auflisten können), z. B. cn=ldap_reader,dc=example,dc=com. Ist er nicht definiert, wird ein anonymer Bind verwendet.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Passwort für OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Eigenschaft des Benutzers, mit der gegen den Client gebunden wird, standardmäßig dn.
  • OVERLEAF_LDAP_SEARCH_BASE (erforderlich)
    • Die Base-DN, ab der nach Benutzern gesucht wird. Z. B. ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • LDAP-Suchfilter, mit dem ein Benutzer gefunden wird. Verwenden Sie das Literal ‘{{username}}’, damit der angegebene Benutzername in die LDAP-Suche eingesetzt wird.
      • Beispiel: (|(uid={{username}})(mail={{username}})) (Benutzer kann sich mit E-Mail-Adresse oder Login-Namen anmelden).
      • Beispiel: (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • Der Suchbereich kann base, one oder sub (Standard) sein.
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • JSON-Array der vom LDAP-Server abzurufenden Attribute, z. B. ["uid", "mail", "givenName", "sn"]. Standardmäßig werden alle Attribute abgerufen.
  • OVERLEAF_LDAP_STARTTLS
    • Wenn true, wird LDAP über TLS verwendet.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Pfad zur Datei mit dem CA-Zertifikat, mit dem das SSL/TLS-Zertifikat des LDAP-Servers überprüft wird. Bei mehreren Zertifikaten kann es sich um ein JSON-Array mit Pfaden zu den Zertifikaten handeln. Die Dateien müssen für den Docker-Container zugänglich sein.
      • Beispiel (ein Zertifikat): /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Beispiel (mehrere Zertifikate): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Wenn true, wird das Serverzertifikat gegen die Liste der angegebenen CAs geprüft.
  • OVERLEAF_LDAP_CACHE
    • Wenn true, werden bis zu 100 Zugangsdaten gleichzeitig für 5 Minuten zwischengespeichert.
  • OVERLEAF_LDAP_TIMEOUT
    • Wie lange der Client Vorgänge laufen lässt, bevor eine Zeitüberschreitung eintritt, in ms (Standard: Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Wie lange der Client bei TCP-Verbindungen wartet, bevor eine Zeitüberschreitung eintritt, in ms (Standard: Standardwert des Betriebssystems).
  • OVERLEAF_LDAP_IS_ADMIN_ATT und OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Sind beide Umgebungsvariablen gesetzt, setzt der Anmeldevorgang user.isAdmin = true, wenn das LDAP-Profil das durch OVERLEAF_LDAP_IS_ADMIN_ATT angegebene Attribut enthält und dessen Wert entweder OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE entspricht oder ein Array ist, das OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE enthält; andernfalls wird user.isAdmin auf false gesetzt. Ist eine dieser Variablen nicht gesetzt, wird der Admin-Status nur bei der Erstellung des Admin-Benutzers im Launchpad auf true gesetzt.
Die folgenden fünf Variablen legen fest, wie Benutzerkontakte vom LDAP-Server abgerufen werden.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Der Filter, mit dem auf dem LDAP-Server nach Benutzern gesucht wird, die in die Kontakte geladen werden sollen. Der Platzhalter ‘{{userProperty}}’ im Filter wird durch den Wert der durch OVERLEAF_LDAP_CONTACTS_PROPERTY angegebenen Eigenschaft des LDAP-Benutzers ersetzt, der die Suche auslöst. Ist er nicht definiert, werden keine Benutzer vom LDAP-Server in die Kontakte übernommen.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Gibt die Base-DN an, ab der nach Kontakten gesucht wird. Standardmäßig OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • Der Suchbereich kann base, one oder sub (Standard) sein.
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Gibt die Eigenschaft des Benutzerobjekts an, die den Platzhalter ‘{{userProperty}}’ in OVERLEAF_LDAP_CONTACTS_FILTER ersetzt.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Gibt den Wert von OVERLEAF_LDAP_CONTACTS_PROPERTY an, wenn die Suche von einem Nicht-LDAP-Benutzer ausgelöst wird. Ist diese Variable nicht definiert, liefert der resultierende Filter keine Treffer. Der Wert * kann als Platzhalter verwendet werden.
Das obige Beispiel lädt alle LDAP-Benutzer mit derselben UNIX-gid in die Kontakte des aktuellen LDAP-Benutzers. Nicht-LDAP-Benutzer erhalten alle LDAP-Benutzer mit UNIX-gid=1000 in ihren Kontakten.

​
Schritt für Schritt: goauthentik

Diese Anleitung beschreibt eine Einrichtung, die mit goauthentik getestet wurde. Die Beispiele verwenden den Base DN dc=example,dc=com; ersetzen Sie ihn durch Ihren eigenen.
1

Bind-Konto anlegen

Overleaf meldet sich zunächst mit einem eigenen Konto am Verzeichnis an, um den Benutzer zu finden. Öffnen Sie in Authentik Directory > Users, klicken Sie auf New User, wählen Sie Internal User und klicken Sie auf Next. Geben Sie einen Benutzernamen ein, zum Beispiel ldapservice, und klicken Sie auf Create:

Authentik: Bind-Konto anlegen

Öffnen Sie den neuen Benutzer und klicken Sie auf Set password. Dieses Passwort gehört in OVERLEAF_LDAP_BIND_CREDENTIALS:

Authentik: Passwort des Bind-Kontos festlegen (Testinstanz)

Notieren Sie sich die Nummer des Benutzers in der Adressleiste, zum Beispiel 19 in …/#/identity/users/19. Sie benötigen sie in Schritt 3.
2

Provider und Anwendung anlegen

Öffnen Sie Applications > Applications und klicken Sie auf New Application. Der Assistent legt die Anwendung und ihren Provider gemeinsam an.1. Geben Sie der Anwendung einen Namen und einen Slug, zum Beispiel overleaf-ldap, und klicken Sie auf Next:

Authentik: Name und Slug der Anwendung

2. Wählen Sie LDAP Provider und klicken Sie auf Next:

Authentik: LDAP-Provider auswählen

3. Setzen Sie Bind Mode auf Direct binding und Search Mode auf Direct querying:

Authentik: Bind- und Suchmodus des LDAP-Providers

4. Setzen Sie weiter unten Bind Flow auf default-authentication-flow und Base DN auf Ihren Base DN, zum Beispiel dc=example,dc=com:

Authentik: Bind Flow und Base DN des LDAP-Providers

5. Klicken Sie auf Next bis zur letzten Seite und schließen Sie die Anwendung ab.
3

Dem Bind-Konto die Verzeichnissuche erlauben

Ohne diese Berechtigung sieht das Bind-Konto nur sich selbst, die Suche findet keinen Benutzer und jede LDAP-Anmeldung schlägt fehl.Öffnen Sie den Provider, gehen Sie zu Permissions und klicken Sie auf Assign Role Object Permission. Geben Sie als Role die Nummer aus Schritt 1 ein, wählen Sie ak-managed-role--user-<number> und aktivieren Sie dann Search full LDAP directory:

Authentik: dem Bind-Konto die Suchberechtigung erteilen (Testinstanz)

Die Rolle zeigt dann ein Häkchen unter Search full LDAP directory:

Authentik: Berechtigungen eines LDAP-Providers (Testinstanz)

4

LDAP-Outpost betreiben

Authentik beantwortet LDAP-Anfragen über einen Outpost, einen separaten Container. Öffnen Sie Applications > Outposts, legen Sie einen Outpost vom Typ LDAP mit Ihrem Provider an und stellen Sie ihn so bereit, wie Authentik es beschreibt. Er lauscht auf Port 389 des Hosts, auf dem er läuft. Sobald er verbunden ist, zeigt er ein grünes Häkchen:

Authentik: ein laufender LDAP-Outpost (Testinstanz)

5

DNs eintragen

Die Provider-Seite zeigt den Base DN und ein Beispiel unter How to connect:

Authentik: Übersicht eines LDAP-Providers (Testinstanz)

Übernehmen Sie die Beispielwerte nicht unverändert:
  • Bind DN zeigt das Konto, mit dem Sie angemeldet sind. Verwenden Sie stattdessen das Bind-Konto aus Schritt 1: cn=ldapservice,ou=users,<Base DN>.
  • Search base zeigt den Base DN. Verwenden Sie ou=users,<Base DN>.
Authentik führt unter ou=virtual-groups für jeden Benutzer eine Gruppe mit dessen Namen. Eine Suche nach (cn=alice) im gesamten Base DN findet sowohl cn=alice,ou=users,… als auch cn=alice,ou=virtual-groups,…, und Overleaf verweigert eine Anmeldung, die auf mehr als einen Eintrag passt. Belassen Sie die Suchbasis bei ou=users,<Base DN>.
6

Suche prüfen

Führen Sie vor dem Start von Overleaf die Suche aus, die Overleaf durchführen wird. Sie muss genau ein dn: ausgeben:
Wird überhaupt kein dn: ausgegeben, fehlt meist die Berechtigung aus Schritt 3.
7

Administratoren zuordnen (optional)

Die Gruppen eines Benutzers stehen in memberOf, als DNs unter ou=groups. Um die Mitglieder der Authentik-Gruppe Admins zu Administratoren von Overleaf zu machen:
Das Admin-Flag wird bei jeder LDAP-Anmeldung aktualisiert. Bei einem falschen Attribut oder Wert verliert jeder Administrator, der sich über LDAP anmeldet, seine Administratorrechte. Testen Sie die Zuordnung zuerst mit einem zweiten Administratorkonto.
variables.env
Zuletzt geändert am 6. Oktober 2026