Skip to content

Login/2FA issues

Wrong password entered multiple times

Sign-in, 2FA confirmation and identity confirmation are rate-limited: 10 requests per minute per client address. Beyond that the server answers with HTTP 429 and the login screen shows "Too many attempts in a short time. Please wait a moment." No account gets locked — after a minute it works again. If the password is really lost, an admin resets it (Admin → Users & access → Users).

A deactivated account gets the same answer on password sign-in as a wrong password ("Invalid credentials") — Vesana does not reveal whether an account exists. So check in the user list whether the account is active. With SSO, the message says explicitly "This account is disabled."

Signing in with a domain account (Active Directory / LDAP)

If a directory is connected under Admin → Login & Security → SSO (preview feature SSO, Admin → System → Preview features), employees sign in with name, DOMAIN\name or name@domain in the normal login screen. The screen states the reason when it fails:

Message Meaning
Too many wrong passwords for this account … wait 15 minutes After 5 wrong passwords for a domain account, Vesana pauses that account for 15 minutes so the AD account does not get locked
Domain password has expired / must be changed change the password in Windows first
Domain account disabled / locked / expired state in AD — Vesana only passes it on
Not enabled for Vesana the account is in none of the allowed AD groups
Company directory cannot be reached no domain controller answers; a local account with the correct Vesana password still signs in
This is a local super admin account local super admins are never linked to the directory — sign in with the Vesana password

Accounts disabled, deleted or removed from the group in AD lose their Vesana sessions after 15 minutes at the latest. The second factor (authenticator, passkey) stays in Vesana for domain accounts too. Details: Active Directory (LDAP).

2FA code isn't accepted

  • Authenticator app (TOTP): the time on the phone and on the server must be correct (TOTP is time-based) — on "Invalid code", check the system time on both sides first.
  • Passkey / security key (WebAuthn): works without any setup on the instance — Vesana uses the address under which you open the interface. The browser requires HTTPS. A passkey only works for the domain it was created under (see domain change).

2FA lockout

After 5 failed attempts at code entry, a 30-minute lockout applies (HTTP 429 with Retry-After header). During the lockout, only waiting or an admin reset (see below) helps.

Completely locked out (no authenticator, no passkey, no backup codes)

This is what the admin path is for:

Admin → Users & access → Users → affected user → "Reset 2FA"

  • Super admins only, with a fresh identity confirmation.
  • Removes the user's authenticator, all passkeys and all backup codes and ends all their sessions (audit entry 2fa_reset_by_admin). The user then signs in with their password; if a mandatory 2FA rule applies to them, the interface takes them straight into the new setup.
  • Not for your own account — that needs a second super admin.
  • Not for SSO accounts — their second factor lives at the identity provider and is reset there.

So always keep at least two super admins with 2FA set up. If the only super admin has no factor and no backup code left, there is no way back through the interface. The emergency path under Admin access & split-container only lifts an access restriction of the admin area (e.g. IP allowlist), not 2FA.

Lost backup codes

Backup codes are created when the first second factor is set up — authenticator app or passkey — and are shown once. Each code can be redeemed exactly once. You create new codes under Settings → 2FA; Vesana asks for an identity confirmation from the last 15 minutes (passkey, authenticator code, password or a remaining backup code). New codes invalidate all old ones. If all codes are used up and the factor is unavailable, only the admin reset above remains.

A mandatory 2FA rule applies

If a mandatory 2FA rule (Admin → Login & Security → 2FA & Sessions) applies to a user, role, permission or tenant and the grace period has expired without the required factor being set up, the user can still sign in — but the interface only lets them set up the factor; everything else is blocked. If they need longer than 15 minutes for that, they confirm once with their password and continue. This is the rule working as configured — check the grace period and whether the user should be listed as an exception (e.g. service accounts without interactive login).

Details: 2FA.

Server clock wrong

Authenticator codes are time-based: if the server clock is off, Vesana rejects correct codes. Fix: set up NTP on the server (check/enable with timedatectl), then try again.

After a domain change the passkey no longer works

The interface always talks to the API under the address you opened it with — a domain change needs no cache reset for that. What does change:

  • Sign-in cookies only apply to the old address — sign in once under the new one.
  • Passkeys are bound to the domain they were created under. Sign in under the new address with an authenticator code or a backup code and register the passkey again. If the WebAuthn domain is set explicitly (VESANA_WEBAUTHN_RP_ID in the .env), it must match the new address.

The interface reloads endlessly and the login screen never appears

If a session expired while a leftover cookie stayed in the browser, the interface could hang in a loop before v1.9.446: it sent you to the login, immediately considered you logged in again and reloaded the dashboard. Only the browser in which this state arose was affected.

Fixed in v1.9.446: logging out now removes every marker the interface uses to recognise "logged in", and a short block after logout applies even if a cookie cannot technically be deleted. On an older version, clearing the site data for that address helps.

The same root cause produced "CSRF token missing or mismatched" when saving after switching the separate admin container on or off: the browser held two identically named session cookies from the old and new scope. From v1.9.446 the server checks against both and clears the old set as well.

Login answers with "502" (v1.9.446 only)

On v1.9.446 the response to login, 2FA confirmation and silent session renewal could exceed the nginx header buffer ("upstream sent too big header") — nobody could get in, and running sessions ended after 30 minutes. Fixed in v1.9.447.

If you are stuck on v1.9.446 and cannot reach the interface: run docker compose pull && docker compose up -d on the server — or, as an immediate measure, set proxy_buffer_size 16k; in the nginx container and run nginx -s reload.

Next