LDAP-/AD-Anmeldung einrichten (Firmen-Login)

Admin

Mit dem Firmen-Login melden sich Nutzer mit ihrem Active-Directory-Konto (Username + Passwort) an — zusätzlich zur OTP-Anmeldung per Einmalcode. Beide Wege laufen gleichzeitig: Die Login-Seite zeigt dann zwei Tabs, „Login per Code” und „Firmen-Login”. Den Tab und die Erstanmeldung aus Nutzersicht erklärt Firmen-Login (Erstanmeldung).

LDAP ist ein Pro/Site-Feature (verfügbar in Pro und Site, nicht in Free → Lizenz- & Editionsmodell) und wird ausschließlich vom zentralen Web-API-Server bedient. Einzelplatz- und Peer-Installationen (autonomer Desktop, Desktop-als-Server) bieten kein LDAP — siehe Topologie.

Voraussetzungen

Service-Account in AD: ein eigenes Dienstkonto mit Lese-Rechten auf den Benutzer-Subtree — least privilege, kein Domain-Admin. Das Passwort sollte möglichst nicht ablaufen, sonst bricht jede Anmeldung, bis es neu hinterlegt wird.
LDAPS / TLS: ein Domänencontroller mit gültigem LDAPS-Zertifikat auf Port 636; das CA-Zertifikat muss vom Server als vertrauenswürdig einstufbar sein.
Netzwerk: vom API-Server aus Port 636 (LDAPS) bzw. 389 (StartTLS) zum DC offen.
Base DN: z. B. DC=corp,DC=example,DC=com. Optional ein engerer Such-Subtree.
Mindestens eine AD-Gruppe, deren Mitglieder sich anmelden dürfen.

Einrichten

Die Einstellungen liegen unter Admin → Tab „LDAP / AD” (nur im Web-/Paired-Modus sichtbar).

Verbindung ausfüllen: Host (DC-Hostname/IP), Port 636, Security Ldaps, Base DN (DC=corp,DC=example,DC=com), optional ein engerer UserSearchBase.
Service-Account ausfüllen: ServiceAccountDn (Bind-DN oder UPN) und Passwort. Das Passwort wird verschlüsselt gespeichert und nie im Klartext angezeigt; beim erneuten Speichern leer lassen, um das vorhandene Secret zu behalten.
Attribute in der Regel auf den AD-Defaults belassen. Für UPN-Login (max.muster@corp.example.com) das LoginAttribute auf userPrincipalName setzen.
„Verbindung testen” klicken — prüft die eingegebene Konfiguration (erfolgreicher Service-Account-Bind), ohne zu speichern.
Gruppen-Mappings anlegen (siehe unten): mindestens eine Login-Gruppe mit einer Rolle.
Enabled auf true setzen und speichern. Änderungen greifen live (Hot-Reload) — kein Neustart nötig.
Verifizieren: ausloggen → Tab „Firmen-Login” → mit einem echten AD-Konto testen, ein Admin-Konto über die Admin-Gruppe gegenprüfen.

Gruppen → Rollen

Jedes Mapping bildet eine AD-Gruppe auf eine Berechtigung ab. Das Gate entscheidet pro Anmeldung „darf rein?” und „welche Rolle?”:

Login- vs. Deny-Gruppen. Nur eine als Login-Gruppe (IsAllowedLoginGroup = true) markierte Gruppe gewährt Zutritt und Rolle. Deny-/Observe-Gruppen können einen Nutzer nie versehentlich hochstufen.
Höchste Rolle gewinnt. Bei Mehrfachmitgliedschaft zählt die stärkste getroffene Login-Gruppe (Admin > Employee). Eine zu weit gefasste Admin-Gruppe vergibt unbeabsichtigt Admin-Rechte.
AllowAllAuthenticated ist ein weites Tor: true lässt jeden erfolgreich gebundenen AD-Nutzer mit der DefaultRole rein — bequem für „alle Mitarbeiter”, aber ohne Gruppen-Gate. Für abgestufte Rechte besser Login-Gruppen verwenden.
Sicherer Default „niemand”. Solange die Login-Liste leer ist und AllowAllAuthenticated = false, kommt niemand rein — ein Admin muss das Tor bewusst öffnen.

Konto-Verknüpfung

Beim ersten erfolgreichen Firmen-Login wird kein zweites Konto angelegt, wenn bereits ein Konto mit derselben E-Mail existiert: Der bestehende OTP-Nutzer wird verknüpft statt dupliziert. Anker ist die stabile AD-Kennung objectGUID — eine spätere Änderung von E-Mail oder Username bricht die Verknüpfung nicht.

Danach gilt: Ein verknüpftes Konto ist eine Zeile. Beide Tabs funktionieren weiter — ein verknüpfter Nutzer kann sich auch per OTP anmelden, ohne ein zweites Konto zu erzeugen.

Schutzregeln: Gehört eine E-Mail bereits einem anderen AD-Konto, wird der Login abgelehnt (kein Hijack); ein anonymisiertes (DSGVO-gelöschtes) Konto wird nie wiederbelebt.

Rollen-Ownership

Der Client redet nie direkt mit dem Verzeichnis: Er postet nur Username/Passwort an seinen Server; der Server bindet gegen AD — dasselbe Muster wie bei OTP, wo der Server den Code versendet.

Browser (Web-Modus) und gepairter Desktop (Server-Mode) → Firmen-Login über den zentralen Web-API-Server. ✅
Desktop als eigener Server (Peer für andere Desktops) → bedient nur OTP, kein Firmen-Login. ❌
Autonomer Desktop (Einzelinstallation) → kein Verzeichnis erreichbar, kein Firmen-Login-Tab. ❌

Der „Firmen-Login”-Tab erscheint nur, wenn der gekoppelte Server LDAP als aktiviert und konfiguriert meldet. Server ohne diese Meldung zeigen nur den OTP-Tab.

Troubleshooting

Fehlergrund	Ursache / Behebung
`ServerUnreachable`	Host nicht erreichbar, TLS-Handshake fehlgeschlagen (CA nicht vertraut), Port zu oder Timeout. CA, Port und das `Security`+`Port`-Paar prüfen.
`InvalidCredentials`	Falsches Nutzer-Passwort oder falsches Service-Account-Passwort. Den Service-Account-Bind isoliert mit „Verbindung testen” prüfen.
`UserNotFound`	Service-Account-Bind ok, aber die Suche liefert keinen Nutzer. Base DN/UserSearchBase, LoginAttribute und Filter prüfen.
„Niemand kommt rein”, trotz korrekter Bind-Daten	Login-Liste leer und `AllowAllAuthenticated = false` = sicherer Default „niemand”. Login-Gruppe(n) anlegen oder `AllowAllAuthenticated` bewusst setzen.

Verwandt

Firmen-Login (Erstanmeldung) — die Nutzersicht
OTP-Anmeldung einrichten
RBAC & Vertraulichkeitsstufen
Nutzerverwaltung