Skyrsoft Autologon Manager console sign-in supports a local password alongside single sign-on through Okta, Microsoft Entra ID, Google Workspace, AD FS or a generic OpenID Connect issuer — five presets, all authenticating through the same OIDC flow underneath. You can configure more than one provider, but only one is active at a time, matching the single sign-in button an operator sees on the login page. A second factor, TOTP or a passkey, covers local accounts, access is checked against one of two roles, and a locked-out installation can still be recovered directly on the server, with no console access needed.
How it works
One identity, shared across every provider
The first successful sign-in through the active provider creates the local operator record automatically. Identity is anchored on UPN, so a person who later signs in through a different provider — or through a local account, if local sign-in is still enabled — resolves to that same record rather than a new one. That is what lets an operator move between an on-premises IdP and a cloud one, or between SSO and a local account, without losing whatever role they already hold.
Role assignment and group mapping
A user’s role comes from group-to-role mappings configured on that provider’s own edit page — group claim values differ by IdP, so a mapping belongs to exactly one provider, alongside a separate Global card for rules that should apply no matter which provider is active. The highest role across a person’s matched groups wins; no match, and no bootstrap-admin listing, refuses the sign-in outright, unless the provider carries a Default role for exactly this case. Role assignment happens only at that first provisioning: an admin’s later change on Settings → Users sticks, and a returning sign-in that still matches no group keeps the role already on the account rather than being reset to the provider’s default.
Per-provider account lifecycle
Each provider can turn on its own inactivity lifecycle: disable an account after a configurable number of days without a sign-in (default 90), then delete it a further configurable number of days after that (default 30). It is off by default, so an expiring account is a deliberate choice for that provider rather than a side effect of adding one, and it only ever touches accounts that provider created — a local account is never affected. Disabling never deletes anything, and a deleted account can sign in again and be provisioned fresh the next time the person authenticates.
Multi-factor authentication
Local accounts can enrol either or both of two factors from My profile: a TOTP authenticator app,
and a passkey — a hardware security key or a platform passkey such as Windows Hello or Touch ID.
Either one alone satisfies sign-in, so enrolling both leaves a working fallback if you lose the
other. When policy requires MFA, a local account without a factor is forced to enrol at its next
sign-in. For SSO, MFA is the identity provider’s job by default; Require MFA can instead be applied
to every sign-in regardless of path, and a per-provider Require MFA plus an acr_values request
can ask a specific provider for step-up on its own.
A wrong password and a wrong TOTP code count against the same brute-force limit — five consecutive failures locks the account for 15 minutes by default, both admin-configurable — and a correct TOTP code is still refused if it was already accepted once, so a code captured off a screen or a log cannot be replayed even inside its own validity window. The counter lives on the account row in the database rather than in memory, so it survives a service restart instead of resetting.
Roles
Two roles exist, checked on the server rather than only hidden from the console’s navigation. Admin reaches everything, including Settings — providers, MFA policy, AD domains, operator accounts, the admin API token, security policy, the console certificate and licensing. Users reaches every operational screen: the fleet, groups, commands, deploy, and credential reset and reveal. Settings is hidden for a Users account, and its actions are refused if attempted directly.
First sign-in and break-glass recovery
A fresh install seeds a bootstrap admin — admin by default — with a random password generated for
that server; there is no shared default across installs. Because a brand-new install has no other
way to tell you what it picked, the sign-in page displays the username and password until you
change them, the server’s Windows event log carries the same pair if you can’t reach the console
yet, and the first sign-in forces a password change before you can go any further. Local sign-in
itself is two steps — username, then password — and the username step never reveals whether an
account exists, so it can’t be used to enumerate admins.
If a bootstrap admin loses both its password and every MFA factor, there is no way to recover it
through the console — that is the point of requiring both. Recovery is a command run locally on the
server itself: Skyrsoft.Autologon.Server.exe break-glass --upn admin --new-password "...", which
sets the password, clears TOTP and every registered passkey, and logs the action prominently to the
Windows event log. It targets only a UPN actually listed as a bootstrap admin and needs no
confirmation to run — OS-level access to the server is itself the authorisation.
Limits
Only one provider is active at a time. Configuring several identity providers does not put several sign-in buttons on the login page; which one is live is chosen on Settings → Authentication, and switching it is a deliberate step taken there.
Identity spans every provider you configure, which cuts both ways. A lower-trust provider added alongside a trusted one inherits whatever role an existing UPN already carries, because the two resolve to the same operator record. Only configure a provider you trust to own the addresses it asserts.
A provider’s current group membership only ever sets a role at the first sign-in. A promotion or demotion made on the identity provider afterward has no effect until an admin changes the role by hand on Settings → Users. A role that resolves to no match keeps blocking the sign-in every time, regardless of when the mismatch happened.
Microsoft Entra ID and Google Workspace both need a workaround for group mapping. Entra drops
its groups claim entirely, replacing it with an overage indicator, once a signing-in user belongs
to more than roughly 200 groups — App roles and the roles claim are the fix for that tenant.
Google’s tokens carry no group claim at all, so a Google provider needs a Default role; without
one, every first-time Google sign-in is refused.
Break-glass only ever resets a bootstrap admin. A different local admin who is locked out, while at least one other admin can still sign in, is recovered from Settings → Users instead of the CLI command — Reset MFA clears a lost authenticator or passkey, and a separate password reset covers a forgotten password, so which one you need depends on what was actually lost.