Skip to main content
Denne funksjonen er utviklet av yu-i-i/overleaf-cep. Her tilbyr vi litt dokumentasjon for konfigurasjonen din.
Overleaf bruker biblioteket passport-ldapauth, som er relativt utdatert, så LDAP-kompatibilitet kan ikke garanteres fullt ut. Med enkelte LDAP-identitetsleverandører (for eksempel https://goauthentik.io/) kan innlogging mislykkes. Hvis mulig anbefales det derfor å bruke OAuth/SAML i stedet. For goauthentik kan du følge Trinn for trinn: goauthentik nedenfor, som er testet.

​
Hva er LDAP

LDAP er en autentiseringsprotokoll som brukes til ekstern identitetsverifisering. Overleaf Server Pro har et eget LDAP-innloggingsskjema i webgrensesnittet, atskilt fra standard autentiseringsmetode. Når en bruker sender inn LDAP-brukernavn og -passord, verifiserer Overleaf-backend legitimasjonen mot den konfigurerte LDAP-serveren, for eksempel ldap://ldap:10389.

Et Server Pro-eksempel for LDAP

​
Konfigurasjon

Internt bruker Overleaf LDAP biblioteket passport-ldapauth. De fleste av disse konfigurasjonsalternativene sendes videre til konfigurasjonsobjektet server, som brukes til å konfigurere passport-ldapauth. Hvis du har problemer med å konfigurere LDAP, er det verdt å lese README-filen for passport-ldapauth for å få et inntrykk av hvilken konfigurasjon den forventer. Miljøvariabelen EXTERNAL_AUTH kreves for å aktivere LDAP-autentiseringsmodulen. Denne miljøvariabelen angir hvilke eksterne autentiseringsmetoder som er aktivert. Verdien av variabelen er en liste. Hvis listen inneholder ldap, aktiveres LDAP-autentisering. For eksempel: EXTERNAL_AUTH=ldap saml I motsetning til Overleaf CEP begrenser vi i ayaka-notes-utgaven LDAP-autentisering til en ren autentiseringsmetode, som er tilgjengelig på http://your-overleaf.com/ldap/login. Når LDAP-autentisering brukes og en bruker skriver inn username og password i innloggingsskjemaet, skjer følgende:
  1. Det søkes etter en LDAP-bruker i LDAP-katalogen med filteret definert av OVERLEAF_LDAP_SEARCH_FILTER, og brukeren autentiseres.
  2. Hvis autentiseringen lykkes, søkes det i Overleafs brukerdatabase etter en bruker med en primær e-postadresse som samsvarer med e-postadressen til den autentiserte LDAP-brukeren:
    • Hvis en samsvarende bruker blir funnet, slettes feltet hashedPassword for denne brukeren (hvis det finnes). Dette sikrer at brukeren heretter bare kan logge inn via LDAP-autentisering.
    • Hvis ingen samsvarende bruker blir funnet, opprettes en ny Overleaf-bruker med e-postadressen, fornavnet og etternavnet som hentes fra LDAP-serveren.
For brukere som logger inn via LDAP, lagrer vi ikke hashede passord i Overleafs Mongo-database (eksisterende fjernes).

​
Miljøvariabler

  • OVERLEAF_LDAP_URL (påkrevd)
    • URL-en til LDAP-serveren.
      • Eksempel: ldaps://ldap.example.com:636 (LDAP over SSL)
      • Eksempel: ldap://ldap.example.com:389 (ukryptert eller STARTTLS, hvis konfigurert).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Visningsnavn for LDAP-identitetstjenesten, brukt på innloggingssiden.
    • Standard er Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • E-postattributtet som returneres av LDAP-serveren, standard mail. Hver LDAP-bruker må ha minst én e-postadresse. Hvis flere adresser oppgis, brukes bare den første.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Navnet på egenskapen som inneholder brukerens fornavn som brukes i applikasjonen, vanligvis givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Navnet på egenskapen som inneholder brukerens etternavn som brukes i applikasjonen, vanligvis sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Navnet på egenskapen som inneholder brukerens fulle navn, vanligvis cn. Hvis en av de to foregående variablene ikke er definert, hentes brukerens fornavn og/eller etternavn fra denne variabelen. Ellers brukes den ikke.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Plassholderteksten for innloggingsskjemaet, standard er Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Hvis satt til true, oppdateres LDAP-brukerens felt first_name og last_name ved innlogging, og skjemaet for brukerdetaljer på siden /user/settings slås av for LDAP-brukere. Ellers hentes detaljene bare ved første innlogging.
  • OVERLEAF_LDAP_BIND_DN
    • Det unike navnet (DN) til LDAP-brukeren som skal brukes for LDAP-tilkoblingen (denne brukeren må kunne søke etter/liste kontoer på LDAP-serveren), f.eks. cn=ldap_reader,dc=example,dc=com. Hvis den ikke er definert, brukes anonym binding.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Passord for OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Brukeregenskapen som skal bindes mot klienten, standard er dn.
  • OVERLEAF_LDAP_SEARCH_BASE (påkrevd)
    • Basis-DN-en det skal søkes etter brukere fra. F.eks. ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • LDAP-søkefilter som brukes til å finne en bruker. Bruk literalen ‘{{username}}’ for å få det oppgitte brukernavnet interpolert inn i LDAP-søket.
      • Eksempel: (|(uid={{username}})(mail={{username}})) (brukeren kan logge inn med e-post eller brukernavn).
      • Eksempel: (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • Søkeomfanget kan være base, one eller sub (standard).
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • JSON-matrise med attributter som skal hentes fra LDAP-serveren, f.eks. ["uid", "mail", "givenName", "sn"]. Som standard hentes alle attributter.
  • OVERLEAF_LDAP_STARTTLS
    • Hvis true, brukes LDAP over TLS.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Sti til filen som inneholder CA-sertifikatet som brukes til å verifisere LDAP-serverens SSL/TLS-sertifikat. Hvis det finnes flere sertifikater, kan det være en JSON-matrise med stier til sertifikatene. Filene må være tilgjengelige for Docker-containeren.
      • Eksempel (ett sertifikat): /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Eksempel (flere sertifikater): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Hvis true, verifiseres serversertifikatet mot listen over oppgitte CA-er.
  • OVERLEAF_LDAP_CACHE
    • Hvis true, hurtigbufres opptil 100 legitimasjoner om gangen i 5 minutter.
  • OVERLEAF_LDAP_TIMEOUT
    • Hvor lenge klienten skal la operasjoner pågå før tidsavbrudd, i ms (standard: Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Hvor lenge klienten skal vente før tidsavbrudd på TCP-tilkoblinger, i ms (standard: operativsystemets standard).
  • OVERLEAF_LDAP_IS_ADMIN_ATT og OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Når begge miljøvariablene er angitt, setter innloggingsprosessen user.isAdmin = true hvis LDAP-profilen inneholder attributtet angitt av OVERLEAF_LDAP_IS_ADMIN_ATT og verdien enten samsvarer med OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE eller er en matrise som inneholder OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE; ellers settes user.isAdmin til false. Hvis en av disse variablene ikke er angitt, settes administratorstatusen bare til true når administratorbrukeren opprettes i Launchpad.
De følgende fem variablene brukes til å konfigurere hvordan brukerkontakter hentes fra LDAP-serveren.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Filteret som brukes til å søke etter brukere på LDAP-serveren som skal lastes inn i kontaktene. Plassholderen ‘{{userProperty}}’ i filteret erstattes med verdien av egenskapen angitt av OVERLEAF_LDAP_CONTACTS_PROPERTY fra LDAP-brukeren som starter søket. Hvis den ikke er definert, hentes ingen brukere fra LDAP-serveren inn i kontaktene.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Angir basis-DN-en som søket etter kontakter skal starte fra. Standard er OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • Søkeomfanget kan være base, one eller sub (standard).
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Angir egenskapen i brukerobjektet som skal erstatte plassholderen ‘{{userProperty}}’ i OVERLEAF_LDAP_CONTACTS_FILTER.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Angir verdien av OVERLEAF_LDAP_CONTACTS_PROPERTY hvis søket startes av en bruker som ikke er LDAP-bruker. Hvis denne variabelen ikke er definert, vil det resulterende filteret ikke samsvare med noe. Verdien * kan brukes som jokertegn.
Eksempelet ovenfor fører til at alle LDAP-brukere med samme UNIX-gid lastes inn i kontaktene til den gjeldende LDAP-brukeren. Brukere som ikke er LDAP-brukere, får alle LDAP-brukere med UNIX gid=1000 i kontaktene sine.

​
Trinn for trinn: goauthentik

Dette er en gjennomgang av et oppsett som er testet mot goauthentik. Eksemplene bruker Base DN dc=example,dc=com; erstatt den med din egen.
1

Opprett en bind-konto

Overleaf logger først inn i katalogen med en egen konto for å finne brukeren. I Authentik åpner du Directory > Users, klikker New User, velger Internal User og klikker Next. Skriv inn et brukernavn, for eksempel ldapservice, og klikk Create:

Authentik: opprett bind-kontoen

Åpne den nye brukeren og klikk Set password. Dette passordet skal inn i OVERLEAF_LDAP_BIND_CREDENTIALS:

Authentik: angi passordet for bind-kontoen (testinstans)

Merk deg nummeret til brukeren i adressefeltet, for eksempel 19 i …/#/identity/users/19. Du trenger det i trinn 3.
2

Opprett leverandøren og applikasjonen

Åpne Applications > Applications og klikk New Application. Veiviseren oppretter applikasjonen og leverandøren samtidig.1. Gi applikasjonen et navn og en slug, for eksempel overleaf-ldap, og klikk Next:

Authentik: navn og slug for applikasjonen

2. Velg LDAP Provider og klikk Next:

Authentik: velg LDAP-leverandøren

3. Sett Bind Mode til Direct binding og Search Mode til Direct querying:

Authentik: bind- og søkemodus for LDAP-leverandøren

4. Lenger ned setter du Bind Flow til default-authentication-flow og Base DN til din Base DN, for eksempel dc=example,dc=com:

Authentik: bind-flyt og Base DN for LDAP-leverandøren

5. Klikk Next til siste side og send inn applikasjonen.
3

La bind-kontoen søke i katalogen

Uten denne tillatelsen ser bind-kontoen bare seg selv, søket finner ingen bruker, og alle LDAP-innlogginger mislykkes.Åpne leverandøren, gå til Permissions og klikk Assign Role Object Permission. Under Role skriver du inn nummeret fra trinn 1 og velger ak-managed-role--user-<number>, og deretter slår du på Search full LDAP directory:

Authentik: gi bind-kontoen søketillatelsen (testinstans)

Rollen viser deretter en hake under Search full LDAP directory:

Authentik: tillatelser for en LDAP-leverandør (testinstans)

4

Kjør LDAP-outposten

Authentik svarer på LDAP gjennom en outpost, en separat container. Åpne Applications > Outposts, opprett en outpost av typen LDAP med leverandøren din, og distribuer den slik Authentik beskriver. Den lytter på port 389 på verten den kjører på. Når den er tilkoblet, viser den en grønn hake:

Authentik: en kjørende LDAP-outpost (testinstans)

5

Fyll inn DN-ene

Leverandørsiden viser Base DN og et eksempel under How to connect:

Authentik: oversikt over en LDAP-leverandør (testinstans)

Ikke kopier eksempelverdiene som de er:
  • Bind DN viser kontoen du er logget inn med. Bruk i stedet bind-kontoen fra trinn 1: cn=ldapservice,ou=users,<Base DN>.
  • Search base viser Base DN. Bruk ou=users,<Base DN>.
Authentik har en gruppe med samme navn som hver bruker under ou=virtual-groups. Et søk i hele Base DN etter (cn=alice) finner både cn=alice,ou=users,… og cn=alice,ou=virtual-groups,…, og Overleaf avviser en innlogging som samsvarer med mer enn én oppføring. Behold søkebasen på ou=users,<Base DN>.
6

Kontroller søket

Før du starter Overleaf, kjører du søket som Overleaf vil utføre. Det må skrive ut nøyaktig én dn::
Ingen dn: i det hele tatt betyr vanligvis at tillatelsen fra trinn 3 mangler.
7

Tilordne administratorene (valgfritt)

Gruppene til en bruker ligger i memberOf, som DN-er under ou=groups. Slik gjør du medlemmene av Authentik-gruppen Admins til administratorer i Overleaf:
Administratorflagget oppdateres ved hver LDAP-innlogging. Med feil attributt eller verdi mister alle administratorer som logger inn via LDAP administratorrettighetene. Test tilordningen med en ekstra administratorkonto først.
variables.env
Sist endret 6. oktober 2026