mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-08-03 23:47:46 +00:00
Anso
865d792874
* feat(pricing): collapse to two tiers (Community + Admiral) Collapse Sencho's pricing from three tiers (Community / Skipper / Admiral) to two: a generous free Community tier and a single paid Admiral tier. The Skipper tier is removed. Now free in Community: auto-heal, auto-update, scheduled operations, webhooks, notification routing, Fleet Actions and bulk operations, SSO preset providers (Google / GitHub / Okta), unlimited users with admin and viewer roles, and deploy safety (atomic deploys, auto-rollback, and one-click rollback). Admiral (paid) is focused on running and governing a fleet: blueprints, Fleet Secrets, deploy enforcement, vulnerability report export, audit log, host console, private registries, mesh networking, node cordon, managed cloud backup, LDAP / Active Directory SSO, and the advanced RBAC roles (deployer, node-admin, auditor) with per-resource scoped assignments. Internally the license variant distinction is removed so tier is binary (community / paid). License validation still verifies the Lemon Squeezy store and product before granting paid status. Docs and the contributor guide are updated to the two-tier model. * docs(pricing): correct licensing page to two-tier pricing and tidy stale tier wording The licensing docs page kept the old Admiral pricing plus a Founder Lifetime column and an Enterprise paragraph after the two-tier collapse. Update it to $12/month or $99/year, drop the lifetime and Enterprise content, and link to the pricing page for current pricing. Also fix stale "Skipper" wording in CLA.md, SUPPORT.md, one test title, and three test comments. Historical CHANGELOG entries and the retired-Skipper license-guard test are intentionally left as-is. * docs: align licensing and SSO pages with the two-tier model Correct the SSO overview so the Google, GitHub, and Okta presets read as available on every tier, matching the provider table; only LDAP and Active Directory require Sencho Admiral. Remove the lifetime-plan references from the licensing, settings, and troubleshooting pages so they reflect subscription-only Admiral pricing. * fix(rbac): omit scoped permissions from /me on the Community tier Scoped role assignments only take effect on the paid tier, but GET /api/permissions/me returned them unconditionally, so a downgraded instance with leftover assignments rendered per-resource affordances the API then rejected with 403. The endpoint now mirrors the permission middleware and includes scoped permissions only on the paid tier. Adds a regression test covering the downgrade case. * docs: use custom-pricing wording on the contact page The two-tier model has no Enterprise tier; reword the contact page's enterprise pricing/deals to custom pricing/deals so it does not imply a tier that no longer exists.
80 lines
5.6 KiB
Plaintext
80 lines
5.6 KiB
Plaintext
---
|
|
title: Managing Two-Factor Authentication
|
|
description: Reset a user's 2FA, recover from lockouts, and understand the per-user vs per-provider MFA toggles.
|
|
---
|
|
|
|
<Note>
|
|
This page is for administrators handling 2FA on behalf of other operators. For general 2FA usage (enrolment, recovery codes, the sign-in challenge), see [Two-Factor Authentication](/features/two-factor-authentication).
|
|
</Note>
|
|
|
|
## Reset a user's 2FA
|
|
|
|
A user who has lost both their authenticator app and their remaining backup codes cannot sign in on their own. Any administrator can reset the affected account from the Settings UI.
|
|
|
|
1. Open **Settings · Users**.
|
|
2. Find the user in the list. Users with 2FA enabled show a shield-off icon (warning color) in the action column.
|
|
3. Click the shield icon and confirm the reset.
|
|
|
|
<Frame>
|
|
<img src="/images/two-factor-auth/admin-reset.png" alt="Reset 2FA confirmation modal opened from the Users panel. The header shows the kicker USERS RESET 2FA and the italic display title Reset 2FA for viewer. The body reads Removes the user's authenticator enrolment and backup codes They will sign in with just their password on their next login and can re-enrol from their account settings Use this when a user has lost access to their authenticator. The footer has Cancel and Reset 2FA buttons." />
|
|
</Frame>
|
|
|
|
The modal copy is verbatim:
|
|
|
|
> Removes the user's authenticator enrolment and backup codes. They will sign in with just their password on their next login and can re-enrol from their account settings. Use this when a user has lost access to their authenticator.
|
|
|
|
After confirming:
|
|
|
|
- The user can sign in with their password alone; no second factor is required.
|
|
- The user's token version is bumped, so every existing session of theirs returns `401` on its next API request.
|
|
- The action is recorded in the audit log under the administrator's username.
|
|
|
|
Tell the user to re-enrol from **Settings · Account · Two-factor authentication · Set up 2FA** as soon as they are back in. The account is unprotected until they do.
|
|
|
|
## Emergency recovery from the command line
|
|
|
|
If every administrator has lost access to 2FA and no one can sign in through the UI, reset the admin account directly on the host running Sencho.
|
|
|
|
From a shell on that host:
|
|
|
|
```bash
|
|
docker compose exec sencho node dist/cli/resetMfa.js <username>
|
|
```
|
|
|
|
Replace `<username>` with the admin's account name. On success the command prints a confirmation line and exits with code 0. Sign in with the password, then re-enrol immediately.
|
|
|
|
The command respects the container's `DATA_DIR`, so it always acts on the same SQLite database the application uses. It writes an audit-log entry attributed to `cli` so the action is auditable after the fact.
|
|
|
|
This is one of several host-level recovery commands. See [Emergency command-line recovery](/operations/emergency-cli) for the full set, including password reset, creating an emergency admin, and disabling a broken SSO provider.
|
|
|
|
<Note>
|
|
Enabling **Developer Mode** under **Settings · Developer** surfaces additional `[MFA:diag]` lines in the backend logs. They are helpful when investigating a 2FA support ticket and can be turned off again once the issue is resolved.
|
|
</Note>
|
|
|
|
## SSO and 2FA: two independent toggles
|
|
|
|
When SSO (LDAP or OIDC) is configured, users with 2FA enabled sign in through SSO **without** a second factor by default. SSO is already an authenticated flow, and a TOTP on top is extra friction most teams do not need.
|
|
|
|
Two separate toggles let you change this, and they are independent:
|
|
|
|
| Toggle | Where it lives | Tier | What it does |
|
|
|--------|----------------|------|--------------|
|
|
| **Require 2FA on SSO sign-in** | Each user's own **Settings · Account · Two-factor authentication** section | All tiers | Per-user opt-in. When on, that one user's SSO sign-ins also require a TOTP after the SSO flow returns. Helper text: `By default, SSO logins skip the second factor. Enforce it here to require both.` |
|
|
| **Require MFA** (per provider) | The provider config under **Settings · SSO** | Admiral (LDAP), Community (Custom OIDC and preset OIDC) | Admin-set, fleet-wide for that provider. When on, every SSO-provisioned user must enrol TOTP after their first successful sign-in before they can use the rest of the console. |
|
|
|
|
The per-user toggle decides *whether a TOTP is asked for on every SSO sign-in*. The per-provider toggle decides *whether new SSO users are forced to enrol TOTP at all*. Both can be on at once: the per-provider toggle ensures enrolment, the per-user toggle then asks for the TOTP on every sign-in.
|
|
|
|
If your organisation needs a fleet-wide policy that asks every SSO user for a TOTP on every sign-in, raise this with the Sencho team; it is not exposed as a global setting today. The closest workaround is to enable both toggles for every user.
|
|
|
|
For the user-facing view of the per-user toggle, see [Two-Factor Authentication · SSO sign-in](/features/two-factor-authentication#sso-sign-in). For provider configuration and the per-provider toggle, see [SSO Authentication](/features/sso).
|
|
|
|
## What a reset changes in the database
|
|
|
|
For completeness, an administrator reset performs the following on the target user:
|
|
|
|
- Clears the stored TOTP secret and all remaining backup codes.
|
|
- Rotates the user's token version, invalidating any outstanding session cookies and Bearer tokens bound to that user.
|
|
- Leaves everything else untouched: the username, password hash, role, scoped permissions, and audit history are preserved.
|
|
|
|
Nothing about the user's SSO bindings changes. If the user was signing in with SSO plus enforced 2FA, they resume SSO-only sign-in after the reset (until they re-enrol, at which point the same toggles apply again).
|