Zum Inhalt

Anmeldung mit Active Directory (LDAP)

Mitarbeiter melden sich in Vesana mit ihrem Windows-Domänenkonto an — gleicher Name, gleiches Passwort wie am PC. Es gibt kein zweites Passwort, das jemand vergisst. Wer die Firma verlässt und im AD deaktiviert wird, ist auch in Vesana draußen. Rechte kommen aus den AD-Gruppen.

Funktioniert mit Active Directory (Windows Server 2016 bis 2025) und mit jedem anderen LDAP-Verzeichnis (OpenLDAP, FreeIPA, Samba AD …).

Gehört zum Bereich SSO — standardmäßig aus

Die Verzeichnis-Anmeldung ist Teil der Vorschau-Funktion SSO. Freischalten unter Admin → System → Vorschau-Funktionen, danach einrichten unter Admin → Anmeldung & Sicherheit → SSO → „Active Directory / LDAP verbinden" (nur Super-Admins).

So sieht es für die Benutzer aus

  • Dieselbe Anmeldemaske wie immer. Das Feld heißt dann „Benutzername oder Domänenkonto".
  • Jede gängige Schreibweise funktioniert: max.muster, FIRMA\max.muster, max.muster@firma.local.
  • Klappt die Anmeldung nicht, nennt Vesana den Grund: Passwort abgelaufen, Konto deaktiviert, Konto gesperrt, nicht für Vesana freigegeben, Verzeichnis nicht erreichbar … Ein Tippfehler im Passwort bleibt ein schlichtes „Benutzername oder Passwort ist falsch".
  • Zwei-Faktor-Schutz bleibt in Vesana. Das AD prüft nur das Passwort. Authenticator-App oder Passkey richtet jeder wie gewohnt in Vesana ein, und 2FA-Pflichtregeln gelten auch für Domänenkonten.
  • Das Passwort ändert man in Windows. In den Vesana-Einstellungen steht statt des Passwort-Formulars ein Hinweis.

Vorbereitung im Active Directory (5 Minuten)

Auf einem Domänencontroller in einer PowerShell als Domänen-Admin:

# 1. Dienstkonto zum Lesen — ohne besondere Rechte
New-ADUser -Name "Vesana Dienstkonto" -SamAccountName svc-vesana `
  -UserPrincipalName svc-vesana@firma.local -Enabled $true -PasswordNeverExpires $true `
  -AccountPassword (Read-Host -AsSecureString "Passwort für svc-vesana")

# 2. Gruppe, deren Mitglieder sich in Vesana anmelden dürfen (empfohlen)
New-ADGroup -Name "Vesana-Zugang" -GroupScope Global -GroupCategory Security

# 3. Optional: Gruppen für Rollen, z. B. Admins
New-ADGroup -Name "Vesana-Admins" -GroupScope Global -GroupCategory Security
Add-ADGroupMember "Vesana-Zugang" -Members "Vesana-Admins"

Benutzer kommen dann in Vesana-Zugang bzw. eine Untergruppe. Verschachtelte Gruppen zählen: wer in einer Gruppe steckt, die Mitglied von „Vesana-Zugang" ist, darf sich auch anmelden.

Verschlüsselung: Vesana spricht nur verschlüsselt mit dem Verzeichnis (LDAPS oder StartTLS). Der DC braucht dafür ein Zertifikat. Ist eine Unternehmens-Zertifizierungsstelle (AD CS) installiert, haben die DCs das automatisch. Ob LDAPS läuft, zeigt Test-NetConnection dc1.firma.local -Port 636. Ohne Zertifizierungsstelle: AD CS als Unternehmens-Stammzertifizierungsstelle installieren, die DCs holen sich ihr Zertifikat dann selbst.

Warum kein unverschlüsseltes LDAP?

Ab Windows Server 2025 lehnt ein DC einfache Anmeldungen ohne TLS ohnehin ab („strongerAuthRequired"). Vor allem aber ginge das Passwort jedes Mitarbeiters im Klartext durchs Netz. Deshalb bietet Vesana diese Variante gar nicht erst an.

Einrichtung in Vesana

Admin → Anmeldung & Sicherheit → SSO → „Active Directory / LDAP verbinden". Der Dialog ist zweigeteilt: links die Verbindung, rechts, wer sich anmelden darf.

1. Verbindung

Feld Was eintragen
Name Frei wählbar, z. B. „Firmen-AD"
Verzeichnis Active Directory, sonst „Anderes LDAP"
Domänencontroller / Server DNS-Namen der DCs, z. B. dc1.firma.local, dc2.firma.local. Mehrere = Ausfallsicherheit. Den Namen so eintragen, wie er im Zertifikat steht (meist der volle DNS-Name, keine IP-Adresse).
Verschlüsselung LDAPS (Port 636, Standard) oder StartTLS (Port 389)
Dienstkonto svc-vesana@firma.local, FIRMA\svc-vesana oder der volle DN, dazu sein Passwort

Dann „Verbindung prüfen":

  • Zertifikat: Vertraut Vesana dem Zertifikat des DCs noch nicht, zeigt der Dialog es an: Name, Aussteller, Gültigkeit und SHA-256-Fingerabdruck. „Diesem Zertifikat vertrauen" übernimmt es. Bei Active Directory holt Vesana dabei gleich das Zertifikat der Zertifizierungsstelle der Domäne aus dem AD. Dem wird dann vertraut, und das übersteht die jährliche Erneuerung der DC-Zertifikate. Ohne AD-Zertifizierungsstelle wird genau das Server-Zertifikat übernommen. Erneuert der Server es, holt man es mit „Vom Server holen" einfach neu.
  • Basis-DN: wird erkannt und eingetragen (z. B. DC=firma,DC=local).
  • Am Ende steht „Alles in Ordnung — die Verbindung steht" oder bei jedem Schritt, was zu tun ist.

2. Wer darf sich anmelden?

  • Nur vorhandene Benutzer: Es melden sich nur Benutzer an, die es in Vesana schon gibt — mit demselben Namen wie im AD (max.muster oder max.muster@firma.local). Bei der ersten Anmeldung mit dem Domänenpasswort wird das Vesana-Konto mit dem AD-Konto verknüpft, ab dann gilt nur noch das Domänenpasswort.
  • Alle Domänenbenutzer: Wer sich zum ersten Mal anmeldet, bekommt automatisch ein Vesana-Konto (Benutzername max.muster@firma.local). Dazu gehören:
    • Nur Mitglieder dieser Gruppen (dringend empfohlen, z. B. Vesana-Zugang). Ohne Gruppe kann sich jeder Domänenbenutzer anmelden.
    • Standardrolle für alle, deren Gruppen keine eigene Rolle haben.
    • Rollen nach Verzeichnis-Gruppe, z. B. Vesana-Admins → Admin. Die erste passende Zeile gewinnt. Das gilt beim Anlegen; danach ändert man die Rolle in der Benutzerverwaltung.
  • Teams aus Verzeichnis-Gruppen: AD-Gruppe → Vesana-Team. Wird bei jeder Anmeldung und alle 15 Minuten abgeglichen: wer im AD aus der Gruppe fällt, verliert das Team (und damit dessen Rechte). Von Hand gesetzte Teams bleiben.

Gruppennamen schreibt man wie im AD (Vesana-Admins); Groß-/Kleinschreibung spielt keine Rolle, der volle DN geht auch.

3. Benutzer testen

Unten rechts im Dialog: Benutzername eintragen (Passwort optional) → „Benutzer testen". Vesana zeigt vor dem Speichern:

  • gefundenes Konto und Anzeigename
  • alle Gruppen, auch die verschachtelten
  • ob es ein Vesana-Konto gibt oder eines angelegt wird
  • welche Rolle und welche Teams es bekommt
  • mit Passwort: ob die Anmeldung klappen würde, sonst warum nicht (deaktiviert, abgelaufen, Passwort ändern …)

Danach Speichern. Fertig — die Anmeldemaske nimmt ab sofort Domänenkonten an.

Was Vesana im Hintergrund absichert

  • Konto im AD deaktiviert, gelöscht oder aus der Gruppe genommen ⇒ spätestens nach 15 Minuten sind alle Vesana-Sitzungen dieses Benutzers beendet. Wird das Konto wieder aktiviert, kann er sich normal anmelden.
  • Keine AD-Kontosperre durch Vesana: nach 5 falschen Passwörtern für ein Konto schickt Vesana 15 Minuten lang keine weiteren Versuche ans AD. Die übliche AD-Sperrschwelle liegt darüber. Der Benutzer liest „Zu viele falsche Passwörter … bitte 15 Minuten warten".
  • Lokale Super-Admins werden nie mit dem AD verknüpft. Sie bleiben der Notausgang, falls das Verzeichnis streikt. Empfehlung: mindestens ein lokales Super-Admin-Konto behalten.
  • Verzeichnis nicht erreichbar: Domänenkonten können sich nicht anmelden (klare Meldung). Hatte ein Konto vor der Verknüpfung ein lokales Vesana-Passwort, gilt nur in diesem Fall das als Notausgang. Ein Admin kann so ein Notfall-Passwort unter Benutzerverwaltung → „Passwort setzen" vergeben.
  • Das Passwort des Dienstkontos liegt verschlüsselt in der Datenbank und wird nie angezeigt. Ändert man Server, Zertifikat oder Dienstkonto, fragt Vesana es neu ab — so kann es nie an einen anderen Server gehen.
  • Verzeichnis abschalten oder löschen beendet sofort alle Sitzungen seiner Benutzer. Beim Löschen werden die Konten wieder lokal; wer ein Passwort hat, meldet sich damit an.

Fehlerbehebung

Meldung / Symptom Ursache und Lösung
„Das Zertifikat ist nicht vertrauenswürdig" Bei „Verbindung prüfen" das angezeigte Zertifikat vertrauen, oder das CA-Zertifikat einfügen: auf einem Domänen-PC certutil -ca.cert ca.cer und certutil -encode ca.cer ca.pem, Inhalt von ca.pem unter „Zertifikat einfügen".
„Der eingetragene Server steht nicht im Zertifikat" Den Namen aus dem Zertifikat eintragen (der Dialog listet ihn), statt einer IP-Adresse oder eines Kurznamens.
„Server erreichbar" schlägt fehl Kann der Vesana-Server den DC erreichen? DNS-Namen auflösbar (nslookup dc1.firma.local auf dem Vesana-Server)? Firewall 636 bzw. 389 offen?
„Dienstkonto angemeldet" schlägt fehl Name/Passwort des Dienstkontos prüfen; Konto aktiviert, Passwort nicht abgelaufen?
Benutzer „nicht gefunden" Steht das Konto unterhalb des Basis-DN? Bei „Anderes LDAP" ggf. den Benutzerfilter unter „Erweitert" anpassen.
Benutzer: „nicht für Vesana freigegeben" Benutzer ist in keiner der Gruppen unter „Nur Mitglieder dieser Gruppen".
Benutzer: „Kein Vesana-Konto" Modus „Nur vorhandene Benutzer" — Konto in Vesana anlegen (gleicher Name) oder auf „Alle Domänenbenutzer" umstellen.
Benutzer: „Passwort ändern" / „abgelaufen" Zuerst in Windows das Passwort ändern, dann neu anmelden.

Jeder Anmeldeversuch steht im Audit-Log (Grund bei Fehlschlägen), Verzeichnis-Störungen im Diagnose-Log (Kategorie „auth").

Andere LDAP-Verzeichnisse

Für OpenLDAP, FreeIPA & Co. „Anderes LDAP" wählen. Standards: Benutzer über uid oder mail, Gruppen über memberOf bzw. groupOfNames/posixGroup. Abweichungen unter Erweitert: Benutzerfilter ({login} = eingegebener Name ohne Domäne, {upn} = wie eingegeben), Attribut für Benutzer- und Anzeigename, Port, Zeitlimit.

Siehe auch: SSO (OIDC) für Entra ID, Keycloak & Co. — beides lässt sich gleichzeitig betreiben.