Skip to main content
Denne funktion er udviklet af yu-i-i/overleaf-cep. Her tilbyder vi noget dokumentation til din konfiguration.
Overleaf bruger biblioteket passport-ldapauth, som er relativt forældet, så LDAP-kompatibilitet kan ikke garanteres fuldt ud. Med visse LDAP-identitetsudbydere (for eksempel https://goauthentik.io/) kan der opstå loginfejl. Derfor anbefales det, hvis muligt, at bruge OAuth/SAML i stedet. For goauthentik skal du følge Trin for trin: goauthentik nedenfor, som er testet.

​
Hvad er LDAP

LDAP er en godkendelsesprotokol, der bruges til ekstern identitetsverifikation. Overleaf Server Pro tilbyder en dedikeret LDAP-loginformular i webgrænsefladen, adskilt fra standardgodkendelsesmetoden. Når en bruger indsender sit LDAP-brugernavn og -adgangskode, verificerer Overleafs backend legitimationsoplysningerne mod den konfigurerede LDAP-server, for eksempel ldap://ldap:10389.

Et Server Pro-eksempel på LDAP

​
Konfiguration

Internt bruger Overleaf LDAP biblioteket passport-ldapauth. De fleste af disse konfigurationsmuligheder videregives til konfigurationsobjektet server, som bruges til at konfigurere passport-ldapauth. Hvis du har problemer med at konfigurere LDAP, er det en god idé at læse README-filen for passport-ldapauth for at få en fornemmelse af, hvilken konfiguration den forventer. Miljøvariablen EXTERNAL_AUTH er påkrævet for at aktivere LDAP-godkendelsesmodulet. Denne miljøvariabel angiver, hvilke eksterne godkendelsesmetoder der er aktiveret. Værdien af variablen er en liste. Hvis listen indeholder ldap, aktiveres LDAP-godkendelse. For eksempel: EXTERNAL_AUTH=ldap saml I modsætning til Overleaf CEP begrænser vi i vores ayaka-notes-udgave LDAP-godkendelse til en ren godkendelsesmetode, som er tilgængelig på http://your-overleaf.com/ldap/login. Når LDAP-godkendelse bruges, og en bruger indtaster et username og password i loginformularen, sker følgende:
  1. Der søges efter en LDAP-bruger i LDAP-kataloget ved hjælp af filteret defineret af OVERLEAF_LDAP_SEARCH_FILTER, og brugeren godkendes.
  2. Hvis godkendelsen lykkes, kontrolleres Overleafs brugerdatabase for en bruger, hvis primære e-mailadresse matcher e-mailadressen på den godkendte LDAP-bruger:
    • Hvis der findes en matchende bruger, slettes feltet hashedPassword for denne bruger (hvis det findes). Det sikrer, at brugeren fremover kun kan logge ind via LDAP-godkendelse.
    • Hvis der ikke findes en matchende bruger, oprettes en ny Overleaf-bruger med den e-mail, det fornavn og det efternavn, der hentes fra LDAP-serveren.
For brugere, der logger ind via LDAP, gemmer vi ikke hashede adgangskoder i Overleafs mongo-database (og eksisterende fjernes).

​
Miljøvariabler

  • OVERLEAF_LDAP_URL (påkrævet)
    • URL til LDAP-serveren.
      • Eksempel: ldaps://ldap.example.com:636 (LDAP over SSL)
      • Eksempel: ldap://ldap.example.com:389 (ukrypteret eller STARTTLS, hvis konfigureret).
  • OVERLEAF_LDAP_IDENTITY_SERVICE_NAME
    • Visningsnavn for LDAP-identitetstjenesten, som bruges på loginsiden.
    • Standard er Log in with LDAP Provider.
  • OVERLEAF_LDAP_EMAIL_ATT
    • E-mailattributten, som LDAP-serveren returnerer, standard mail. Hver LDAP-bruger skal have mindst én e-mailadresse. Hvis der angives flere adresser, bruges kun den første.
  • OVERLEAF_LDAP_FIRST_NAME_ATT
    • Navnet på egenskaben, der indeholder brugerens fornavn, som bruges i applikationen, normalt givenName.
  • OVERLEAF_LDAP_LAST_NAME_ATT
    • Navnet på egenskaben, der indeholder brugerens efternavn, som bruges i applikationen, normalt sn.
  • OVERLEAF_LDAP_NAME_ATT
    • Navnet på egenskaben, der indeholder brugerens fulde navn, normalt cn. Hvis en af de to foregående variabler ikke er defineret, udtrækkes brugerens fornavn og/eller efternavn fra denne variabel. Ellers bruges den ikke.
  • OVERLEAF_LDAP_PLACEHOLDER
    • Pladsholderteksten til loginformularen, standard er Username.
  • OVERLEAF_LDAP_UPDATE_USER_DETAILS_ON_LOGIN
    • Hvis den er sat til true, opdateres LDAP-brugerens felter first_name og last_name ved login, og formularen med brugeroplysninger på siden /user/settings slås fra for LDAP-brugere. Ellers hentes oplysningerne kun ved første login.
  • OVERLEAF_LDAP_BIND_DN
    • Det distinguished name for den LDAP-bruger, der skal bruges til LDAP-forbindelsen (denne bruger skal kunne søge i/liste konti på LDAP-serveren), f.eks. cn=ldap_reader,dc=example,dc=com. Hvis den ikke er defineret, bruges anonym binding.
  • OVERLEAF_LDAP_BIND_CREDENTIALS
    • Adgangskode til OVERLEAF_LDAP_BIND_DN.
  • OVERLEAF_LDAP_BIND_PROPERTY
    • Den egenskab ved brugeren, der skal bindes mod klienten, standard er dn.
  • OVERLEAF_LDAP_SEARCH_BASE (påkrævet)
    • Det base-DN, hvorfra der søges efter brugere. F.eks. ou=people,dc=example,dc=com.
  • OVERLEAF_LDAP_SEARCH_FILTER
    • LDAP-søgefilter, som en bruger findes med. Brug den bogstavelige tekst ‘{{username}}’ for at få det angivne brugernavn indsat i LDAP-søgningen.
      • Eksempel: (|(uid={{username}})(mail={{username}})) (brugeren kan logge ind med e-mail eller med loginnavn).
      • Eksempel: (sAMAccountName={{username}}) (Active Directory).
  • OVERLEAF_LDAP_SEARCH_SCOPE
    • Søgningens omfang kan være base, one eller sub (standard).
  • OVERLEAF_LDAP_SEARCH_ATTRIBUTES
    • JSON-array med attributter, der skal hentes fra LDAP-serveren, f.eks. ["uid", "mail", "givenName", "sn"]. Som standard hentes alle attributter.
  • OVERLEAF_LDAP_STARTTLS
    • Hvis true, bruges LDAP over TLS.
  • OVERLEAF_LDAP_TLS_OPTS_CA_PATH
    • Sti til filen med det CA-certifikat, der bruges til at verificere LDAP-serverens SSL/TLS-certifikat. Hvis der er flere certifikater, kan det være et JSON-array med stier til certifikaterne. Filerne skal være tilgængelige for Docker-containeren.
      • Eksempel (ét certifikat): /var/lib/overleaf/certs/ldap_ca_cert.pem
      • Eksempel (flere certifikater): ["/var/lib/overleaf/certs/ldap_ca_cert1.pem", "/var/lib/overleaf/certs/ldap_ca_cert2.pem"]
  • OVERLEAF_LDAP_TLS_OPTS_REJECT_UNAUTH
    • Hvis true, verificeres servercertifikatet mod listen over angivne CA’er.
  • OVERLEAF_LDAP_CACHE
    • Hvis true, caches op til 100 legitimationsoplysninger ad gangen i 5 minutter.
  • OVERLEAF_LDAP_TIMEOUT
    • Hvor længe klienten skal lade operationer køre, før de får timeout, i ms (standard: Infinity).
  • OVERLEAF_LDAP_CONNECT_TIMEOUT
    • Hvor længe klienten skal vente, før TCP-forbindelser får timeout, i ms (standard: operativsystemets standard).
  • OVERLEAF_LDAP_IS_ADMIN_ATT og OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE
    • Når begge miljøvariabler er angivet, opdaterer loginprocessen user.isAdmin = true, hvis LDAP-profilen indeholder attributten angivet af OVERLEAF_LDAP_IS_ADMIN_ATT, og dens værdi enten matcher OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE eller er et array, der indeholder OVERLEAF_LDAP_IS_ADMIN_ATT_VALUE; ellers sættes user.isAdmin til false. Hvis en af disse variabler ikke er angivet, sættes administratorstatus kun til true, når administratorbrugeren oprettes i Launchpad.
Følgende fem variabler bruges til at konfigurere, hvordan brugerkontakter hentes fra LDAP-serveren.
  • OVERLEAF_LDAP_CONTACTS_FILTER
    • Filteret, der bruges til at søge efter brugere på LDAP-serveren, som skal indlæses i kontakter. Pladsholderen ‘{{userProperty}}’ i filteret erstattes med værdien af den egenskab, der er angivet af OVERLEAF_LDAP_CONTACTS_PROPERTY, fra den LDAP-bruger, der starter søgningen. Hvis det ikke er defineret, hentes ingen brugere fra LDAP-serveren ind i kontakter.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_BASE
    • Angiver det base-DN, hvorfra søgningen efter kontakter starter. Standard er OVERLEAF_LDAP_SEARCH_BASE.
  • OVERLEAF_LDAP_CONTACTS_SEARCH_SCOPE
    • Søgningens omfang kan være base, one eller sub (standard).
  • OVERLEAF_LDAP_CONTACTS_PROPERTY
    • Angiver den egenskab ved brugerobjektet, der erstatter pladsholderen ‘{{userProperty}}’ i OVERLEAF_LDAP_CONTACTS_FILTER.
  • OVERLEAF_LDAP_CONTACTS_NON_LDAP_VALUE
    • Angiver værdien af OVERLEAF_LDAP_CONTACTS_PROPERTY, hvis søgningen startes af en bruger, der ikke er LDAP-bruger. Hvis denne variabel ikke er defineret, matcher det resulterende filter ingenting. Værdien * kan bruges som jokertegn.
Ovenstående eksempel medfører, at alle LDAP-brugere med samme UNIX-gid indlæses i den aktuelle LDAP-brugers kontakter. Brugere, der ikke er LDAP-brugere, får alle LDAP-brugere med UNIX gid=1000 i deres kontakter.

​
Trin for trin: goauthentik

Denne vejledning gennemgår en opsætning, der er testet mod goauthentik. Eksemplerne bruger Base DN dc=example,dc=com; erstat den med din egen.
1

Opret en bind-konto

Overleaf logger først ind i kataloget med sin egen konto for at finde brugeren. I Authentik skal du åbne Directory > Users, klikke på New User, vælge Internal User og klikke på Next. Indtast et brugernavn, for eksempel ldapservice, og klik på Create:

Authentik: opret bind-kontoen

Åbn den nye bruger, og klik på Set password. Denne adgangskode skal i OVERLEAF_LDAP_BIND_CREDENTIALS:

Authentik: angiv adgangskoden til bind-kontoen (testinstans)

Notér brugerens nummer i adresselinjen, for eksempel 19 i …/#/identity/users/19. Du skal bruge det i trin 3.
2

Opret udbyderen og applikationen

Åbn Applications > Applications, og klik på New Application. Guiden opretter applikationen og dens udbyder samtidig.1. Giv applikationen et navn og en slug, for eksempel overleaf-ldap, og klik på Next:

Authentik: applikationens navn og slug

2. Vælg LDAP Provider, og klik på Next:

Authentik: vælg LDAP-udbyderen

3. Sæt Bind Mode til Direct binding og Search Mode til Direct querying:

Authentik: bind- og søgetilstand for LDAP-udbyderen

4. Længere nede skal du sætte Bind Flow til default-authentication-flow og Base DN til din Base DN, for eksempel dc=example,dc=com:

Authentik: bind flow og Base DN for LDAP-udbyderen

5. Klik på Next indtil sidste side, og indsend applikationen.
3

Lad bind-kontoen søge i kataloget

Uden denne tilladelse ser bind-kontoen kun sig selv, søgningen finder ingen bruger, og alle LDAP-logins mislykkes.Åbn udbyderen, gå til Permissions, og klik på Assign Role Object Permission. Som Role skal du skrive nummeret fra trin 1 og vælge ak-managed-role--user-<number> og derefter slå Search full LDAP directory til:

Authentik: giv bind-kontoen søgetilladelsen (testinstans)

Rollen viser derefter et flueben under Search full LDAP directory:

Authentik: tilladelser for en LDAP-udbyder (testinstans)

4

Kør LDAP-outposten

Authentik besvarer LDAP via en outpost, en separat container. Åbn Applications > Outposts, opret en outpost af typen LDAP med din udbyder, og udrul den, som Authentik beskriver. Den lytter på port 389 på den vært, den kører på. Når den er forbundet, viser den et grønt flueben:

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

5

Udfyld DN'erne

Udbydersiden viser Base DN og et eksempel under How to connect:

Authentik: oversigt over en LDAP-udbyder (testinstans)

Kopiér ikke eksempelværdierne, som de er:
  • Bind DN viser den konto, du er logget ind med. Brug i stedet bind-kontoen fra trin 1: cn=ldapservice,ou=users,<Base DN>.
  • Search base viser Base DN. Brug ou=users,<Base DN>.
Authentik har en gruppe med navnet på hver bruger under ou=virtual-groups. En søgning efter (cn=alice) i hele Base DN finder både cn=alice,ou=users,… og cn=alice,ou=virtual-groups,…, og Overleaf afviser et login, der matcher mere end én post. Behold søgebasen på ou=users,<Base DN>.
6

Kontrollér søgningen

Før du starter Overleaf, skal du køre den søgning, som Overleaf vil udføre. Den skal udskrive præcis én dn::
Ingen dn: overhovedet betyder som regel, at tilladelsen fra trin 3 mangler.
7

Tilknyt administratorerne (valgfrit)

En brugers grupper findes i memberOf, som DN’er under ou=groups. Sådan gør du medlemmerne af Authentik-gruppen Admins til administratorer i Overleaf:
Administratorflaget opdateres ved hvert LDAP-login. Med en forkert attribut eller værdi mister alle administratorer, der logger ind via LDAP, deres administratorrettigheder. Test tilknytningen med en anden administratorkonto først.
variables.env
Sidst ændret 6. oktober 2026