Skyrsoft Autologon Manager stores one auto-logon credential per machine, encrypted, and can reset it at the source — in Active Directory or locally on the machine — on a schedule you set. It never echoes a stored password back into a form, and every reset or reveal writes a row to that machine’s own credential audit trail. Rotation changes the real account password, not just the copy this product holds, so the machine is never running on a value that has drifted out of sync with the directory.
How it works
An admin sets the credential on a machine’s Config page, or inline from Fleet, and chooses the account type: a domain (Active Directory) user, or a local Windows account. Which type is even offered depends on how the agent enrolled — a workgroup agent can only take a local credential, and a domain agent is offered its own domain — covered in full on agent identity and mutual TLS. From there, two separate things can change the password: an admin pressing Reset on demand, or a rotation schedule doing the same thing automatically.
Setting and resetting a credential
Choosing Domain (Active Directory) lets the server reset the account directly; choosing Local means the agent applies the change on the machine it manages. Reset password on an agent’s details page generates a policy-compliant password and changes it at the source in the same action, so nothing has to be coordinated separately in the directory:
- AD accounts — the server binds a domain controller over LDAPS as a delegated service account,
replaces
unicodePwd, and clears any lockout, then pushes the new credential out and cycles the session. One service account covers a whole domain; configure it on Settings → AD domains. - Local accounts — the agent applies the change itself (
NetUserSetInfo) on its next check-in, and the server promotes the new value onto the stored record once the agent acknowledges it.
AD rotation is convergent, not imperative: it is handled as a target-state statement rather than a one-shot command, so a rotation interrupted between changing the AD password and updating the stored copy repairs itself on the next attempt — completing only the half that did not finish, rather than repeating one that already succeeded and risking a second, conflicting change to AD.
Scheduled rotation
Turning on Rotation enabled and picking a schedule — Daily, Weekly or Monthly, built with a friendly picker that writes the underlying cron for you — hands the same reset to a background service that checks every minute for a due agent. Both account types are covered: an AD rotation runs the server-side LDAPS reset above, and a local rotation queues the same one-shot reset command the agent already knows how to apply. Agents in a group are staggered rather than rotated all at once, so a kiosk fleet does not cycle every machine in the same second. Rotation was originally AD-only in the per-agent Config UI even though the local path already worked end to end; that gap in the interface, not the underlying feature, is what per-agent local overrides fixed.
Reveal
Reveal password, gated to the Admin role, shows the stored password — AD or local — on demand. It is a deliberate exception to “never show it again,” and it is paired with an audit trail rather than left unaudited: every reveal, like every reset, writes who, when and which account to the agent’s credential audit trail.
Limits
Rotating a credential logs the session off. Applying a new password forces a logoff-and-logon cycle so the machine actually starts using it — this is a correctness fix, not a side effect to work around: a session left running on the old password keeps re-presenting stale credentials in the background (drive reconnects, ticket renewals), and each of those is a failed logon that can trip a domain lockout policy within minutes. Schedule rotations for a window where a session bounce is acceptable, and expect every existing machine with rotation enabled to bounce on its next cycle.
AD reset needs a real delegation, and it is narrower than it looks. The service account needs
the Reset Password extended right plus write access to the lockoutTime attribute, both scoped
to the organisational units holding the managed accounts — no group membership and no read access to
lockoutTime are required. Get the scope wrong and the reset itself still works; only the lockout
clear silently fails.
A domain credential can only go to a domain agent of the matching domain. The server refuses a domain credential on a workgroup-class agent even if one is somehow submitted, and a domain agent only ever offers its own domain’s accounts — not a different one it has no proof of.
Reveal access is effectively tier-0. The server already holds the means to decrypt every stored password, so treat an account that can use Reveal as equivalent to an account with server access.