Zum Inhalt

Login-/2FA-Probleme

Falsches Passwort mehrfach eingegeben

Anmeldung, 2FA-Bestätigung und Identitätsbestätigung sind gebremst: 10 Anfragen pro Minute je Client-Adresse. Darüber antwortet der Server mit HTTP 429, die Anmeldemaske zeigt „Zu viele Versuche in kurzer Zeit. Bitte kurz warten." Ein Konto wird dabei nicht gesperrt — nach einer Minute geht es weiter. Bei echtem Passwort-Verlust setzt ein Admin das Passwort zurück (Admin → Benutzer & Rechte → Benutzer).

Ein deaktiviertes Konto bekommt bei der Passwort-Anmeldung dieselbe Antwort wie ein falsches Passwort („Invalid credentials") — Vesana verrät nicht, ob es ein Konto gibt. Prüfe also in der Benutzerliste, ob das Konto aktiv ist. Bei SSO steht dagegen ausdrücklich „Dieses Konto ist deaktiviert."

Anmeldung mit dem Domänenkonto (Active Directory / LDAP)

Ist unter Admin → Anmeldung & Sicherheit → SSO ein Verzeichnis verbunden (Vorschau-Funktion SSO, Admin → System → Vorschau-Funktionen), melden sich Mitarbeiter mit name, DOMÄNE\name oder name@domäne in der normalen Anmeldemaske an. Die Maske nennt den Grund, wenn es scheitert:

Meldung Bedeutung
Zu viele falsche Passwörter für dieses Konto … 15 Minuten warten Nach 5 falschen Passwörtern für ein Domänenkonto pausiert Vesana dieses Konto 15 Minuten, damit das AD-Konto nicht gesperrt wird
Domänenpasswort abgelaufen / muss geändert werden Passwort zuerst in Windows ändern
Domänenkonto deaktiviert / gesperrt / abgelaufen Zustand im AD — Vesana meldet ihn nur weiter
Für Vesana nicht freigegeben das Konto ist in keiner zugelassenen AD-Gruppe
Firmenverzeichnis nicht erreichbar kein Domänencontroller antwortet; ein lokales Konto mit richtigem Vesana-Passwort meldet sich trotzdem an
Dies ist ein lokales Super-Admin-Konto lokale Super-Admins werden nie mit dem Verzeichnis verknüpft — mit dem Vesana-Passwort anmelden

Im AD deaktivierte, gelöschte oder aus der Gruppe genommene Konten verlieren ihre Vesana-Sitzungen spätestens nach 15 Minuten. Der zweite Faktor (Authenticator, Passkey) bleibt auch bei Domänenkonten in Vesana. Details: Active Directory (LDAP).

2FA-Code wird nicht akzeptiert

  • Authenticator-App (TOTP): Zeit auf dem Smartphone und auf dem Server müssen stimmen (TOTP ist zeitbasiert) — bei „Invalid code" zuerst die Systemzeit auf beiden Seiten prüfen.
  • Passkey / Sicherheitsschlüssel (WebAuthn): funktioniert ohne Einrichtung auf der Instanz — Vesana nimmt die Adresse, unter der du die Oberfläche öffnest. Der Browser verlangt HTTPS. Ein Passkey gilt nur für die Domain, unter der er angelegt wurde (siehe Domain-Wechsel).

2FA-Lockout

Nach 5 Fehlversuchen bei der Code-Eingabe greift ein 30-Minuten-Lockout (HTTP 429 mit Retry-After-Header). Während des Lockouts hilft nur Warten oder ein Admin-Reset (siehe unten).

Komplett ausgesperrt (kein Authenticator, kein Passkey, keine Backup-Codes)

Dafür gibt es den Admin-Weg:

Admin → Benutzer & Rechte → Benutzer → betroffener Benutzer → „2FA zurücksetzen"

  • Nur für Super-Admins, mit frischer Identitätsbestätigung.
  • Entfernt Authenticator, alle Passkeys und alle Backup-Codes des Benutzers und beendet alle seine Sitzungen (Audit-Eintrag 2fa_reset_by_admin). Der Benutzer meldet sich danach mit Passwort an; gilt für ihn eine 2FA-Pflicht, führt ihn die Oberfläche direkt in die Neu-Einrichtung.
  • Nicht für das eigene Konto — dafür braucht es einen zweiten Super-Admin.
  • Nicht für SSO-Konten — deren zweiter Faktor liegt beim Identity-Provider und wird dort zurückgesetzt.

Halte deshalb immer mindestens zwei Super-Admins mit eingerichteter 2FA. Ist der einzige Super-Admin ohne Faktor und ohne Backup-Code, gibt es in der Oberfläche keinen Weg zurück. Der Notfall-Weg unter Admin-Zugriff & Split-Container hebt nur eine Zugriffsbeschränkung des Admin-Bereichs auf (z. B. IP-Allowlist), keine 2FA.

Backup-Codes verloren

Backup-Codes entstehen beim Einrichten des ersten zweiten Faktors — Authenticator-App oder Passkey — und werden einmalig angezeigt. Jeder Code ist genau einmal einlösbar. Neue Codes erzeugst du unter Einstellungen → 2FA; dafür verlangt Vesana eine Identitätsbestätigung aus den letzten 15 Minuten (Passkey, Authenticator-Code, Passwort oder ein verbleibender Backup-Code). Neue Codes machen alle alten ungültig. Sind alle Codes aufgebraucht und der Faktor nicht verfügbar, bleibt nur der Admin-Reset oben.

2FA-Pflicht-Regel greift

Greift eine 2FA-Pflicht-Regel (Admin → Anmeldung & Sicherheit → 2FA & Sitzungen) für einen Benutzer, eine Rolle, eine Permission oder einen Tenant und ist die Karenzzeit abgelaufen, ohne dass der geforderte Faktor eingerichtet wurde, kann sich der Benutzer zwar anmelden — die Oberfläche lässt ihn aber nur noch den Faktor einrichten, alles andere ist gesperrt. Braucht er dafür länger als 15 Minuten, bestätigt er sich einmal mit seinem Passwort und richtet weiter ein. Das ist die Regel wie konfiguriert — prüfe die Karenzzeit und ob der Benutzer als Ausnahme eingetragen werden sollte (z. B. Service-Konten ohne interaktiven Login).

Details: 2FA.

Server-Zeit falsch

Authenticator-Codes sind zeitbasiert: geht die Serveruhr falsch, lehnt Vesana korrekte Codes ab. Fix: NTP auf dem Server einrichten (timedatectl prüfen/aktivieren), dann erneut versuchen.

Nach einem Domain-Wechsel funktioniert der Passkey nicht mehr

Die Oberfläche spricht die API immer unter der Adresse an, unter der du sie geöffnet hast — ein Domain-Wechsel braucht dafür keinen Cache-Reset. Was sich ändert:

  • Anmelde-Cookies gelten nur für die alte Adresse — unter der neuen meldest du dich einmal neu an.
  • Passkeys sind an die Domain gebunden, unter der sie angelegt wurden. Unter der neuen Adresse mit Authenticator-Code oder Backup-Code anmelden und den Passkey neu registrieren. Ist die WebAuthn-Domain fest eingestellt (VESANA_WEBAUTHN_RP_ID in der .env), muss sie zur neuen Adresse passen.

Oberfläche lädt endlos neu, die Anmeldemaske erscheint nie

Läuft eine Sitzung ab, während ein Rest-Cookie im Browser zurückbleibt, konnte sich die Oberfläche vor v1.9.446 in einer Schleife aufhängen: sie schickte zur Anmeldung, hielt dich dort sofort wieder für angemeldet und lud das Dashboard erneut. Betroffen war immer nur der Browser, in dem der Zustand entstanden ist.

Behoben ab v1.9.446: Abmelden entfernt jetzt alle Merkmale, an denen die Oberfläche „angemeldet" erkennt, und kurz nach dem Abmelden gilt eine Sperre, die auch dann greift, wenn ein Cookie sich technisch nicht löschen lässt. Auf einer älteren Version hilft „Websitedaten löschen" für diese Adresse.

Dieselbe Wurzel hatte die Meldung „CSRF token missing or mismatched" beim Speichern nach dem Ein- oder Ausschalten des eigenen Admin-Containers: der Browser hielt zwei gleichnamige Sitzungs-Cookies aus altem und neuem Geltungsbereich. Ab v1.9.446 prüft der Server gegen beide und räumt den alten Satz mit ab.

Anmeldung antwortet mit „502" (nur v1.9.446)

Auf v1.9.446 konnte die Antwort auf Login, 2FA-Bestätigung und die stille Sitzungsverlängerung den Header-Puffer von nginx sprengen („upstream sent too big header") — niemand kam mehr hinein, laufende Sitzungen endeten nach 30 Minuten. Behoben in v1.9.447.

Wer auf v1.9.446 festhängt und nicht mehr an die Oberfläche kommt: auf dem Server docker compose pull && docker compose up -d — oder als Sofortmaßnahme im nginx-Container proxy_buffer_size 16k; setzen und nginx -s reload.

Anschluss