Skyrsoft Autologon Manager signs a configured Windows account in at the logon screen with nobody
there to type a password. A native credential provider reads the credential from an encrypted
local cache and presents it the way a person would, rather than leaving anything for the built-in
AutoAdminLogon to read from the registry. The same agent brings an already-signed-in desktop back
after it locks, and gets out of the way cleanly when someone connects over RDP instead. It is aimed
at kiosks, signage players, lab machines, control-room displays and shop-floor terminals — anything
that has to come back to a signed-in desktop after a reboot.
How it works
Host reaches the logon screen
No AutoAdminLogon password sitting in the registry
Credential provider signs the session in
Reads the credential from an encrypted local cache and presents it the way a person would
Windows' own auto-logon stays switched off
The agent clears AutoAdminLogon so the two mechanisms cannot disagree about who signs in
A real machine answering autologon-cli diag — shown on the Autologon Manager
overview — reports whether the provider is actually registered with Windows, whether a
GPO has excluded it, whether something has switched the built-in mechanism back on, and whether the
agent is still talking to the server. The agent itself runs the poll loop that keeps all of this
current — it checks in with the server on an interval, and the response carries a configuration
version rather than a full push. An agent that is behind simply pulls what changed. Everything is
declarative rather than imperative, so there is no partial apply to reason about: the config version
is the fact of record, and an agent showing a stale one has not converged yet rather than having
failed.
Native credential provider
The provider is a Windows credential provider DLL, registered like any other, and Windows offers
its tile at the logon screen alongside whatever else is installed. It reads the stored credential
from the agent’s local cache — never the registry — and submits it the same way an interactive
logon would. If the agent cannot produce a usable credential for any reason, the provider’s TryRead
path returns nothing rather than a broken tile, and Windows falls through to a normal logon prompt.
Suppressing Windows’ own auto-logon
Once a machine has a credential deployed to it, the agent switches off Windows’ native
AutoAdminLogon on that machine. The two mechanisms otherwise both try to sign someone in at boot
and do not agree on who should win, so leaving both on makes the outcome unpredictable. The change
is scoped narrowly: it clears the AutoAdminLogon switch, not any DefaultPassword already sitting
in the registry underneath it. Removing a credential this product did not create is a decision for
whoever put it there, so the agent reports a leftover plaintext password instead of deleting it, and
the change is reversible through the same backup-and-restore mechanism the other logon policies use.
Auto-unlock without a password
Windows deliberately refuses a programmatic unlock through the credential-provider interface — a real Windows policy, not a gap in this product’s implementation. So the provider only ever performs auto-logon, and unlocking an already-signed-in desktop is the agent’s job instead: it disconnects the locked console session, and Windows reconnects it unlocked with the session intact and nothing to re-authenticate. Auto-unlock only ever acts on a session that already has a user logged into it — it is not a second way to sign in from a cold logon screen, which stays the provider’s job.
RDP coexistence
The provider offers its logon tile only when the configured account has no session anywhere on the machine. If that account is already active over RDP — or its console session was disconnected by an incoming RDP connection — the provider offers no tile at all, so the remote session holds instead of being pulled back to the console. On a client SKU such as Windows 10 or 11 Pro, a single account can only ever hold one interactive session, so connecting over RDP as the auto-logon user moves that one session to RDP and leaves the console at a logon screen; that is Windows’ own single-session behaviour, and the way to keep the kiosk account at the console while administering the machine is to connect over RDP as a different account.
Limits
Rotating the credential ends the session it changes. A scheduled or manual reset applies the new password and then logs the machine off so the provider signs back in with it — an operator relying on the machine staying signed in through a rotation needs to plan the schedule around that, covered in full on credential storage and rotation.
Suppressing native auto-logon clears the switch, not the credential. A DefaultPassword already
in the registry from a previous configuration is reported, never deleted — removing a credential the
product did not create is left to whoever put it there.
Auto-unlock needs a session to act on. It brings back a desktop that is already signed in and locked. A machine sitting at a genuine cold logon screen after a reboot is brought back by the credential provider instead.
The single-session limit on client SKUs is Windows, not this product. Windows 10 and 11 Pro allow one interactive session per account, so the auto-logon account cannot be live at the console and over RDP at the same time — administer from a different account instead.