Managed Local Accounts

The managed local account model lets CerberusD prepare a controlled local Windows account on a target resource instead of distributing a shared standing password. The account is not treated as a permanent personal account for daily use; it is an operating preparation tied to resource, assignment, session, and revocation decisions.

This matters for work paths such as RDP. The person can reach the assigned resource without knowing the password, while the agent prepares the local state and CerberusD keeps the session and closure record.

Scope

The “give them the password and let them connect” pattern is fast at first, but it leaves weak evidence:

• copied passwords remain outside the panel,
• closing access does not remove every copy,
• local accounts become hard to connect to specific work,
• user experience for protocols such as RDP drifts away from the security model.

CerberusD makes local account preparation part of the access decision instead.

How it works

Managed local accounts have three parts.

Ownership marker lets the agent recognize accounts governed by CerberusD. If an existing local user collides with the requested name but is not owned by CerberusD, the action stops safely.

Dynamic password preparation creates or rotates the password for the session context. The password is not displayed to the everyday user; it is used through the credential custody model.

Revocation behavior ties account disablement, deletion, or future rotation to recorded command outcomes after access ends.

Supported local actions

When the deployment policy enables the model, the agent can:

• create a managed local Windows account,
• rotate the password for an existing managed account,
• prepare local group membership required for RDP,
• disable the managed account,
• delete the managed account,
• report the result into session and evidence flows.

Account creation can be disabled by deployment policy. When disabled, that capability is unavailable and the resource is evaluated through another credential preparation model.

Process

1. The resource connects to CerberusD through the agent.
2. The resource is claimed and readiness signals are read.
3. An authorized role assigns a person to the resource.
4. If local account preparation is required, the agent receives a controlled action.
5. The agent creates the Cerberus-managed local account or rotates the existing one.
6. If RDP is required, local access membership is prepared.
7. Credential custody uses the session preparation without showing the password to the person.
8. When the session closes or access is revoked, the account can be disabled or removed.
9. The result is attached to the evidence flow.

In practical terms: a dynamic user is created for a specific task, only the required logon permission is prepared, and when the duration expires or the work closes the user is disabled. The panel revocation decision therefore closes the real logon path on the target machine as well.

Security behavior

The agent only mutates a local account it can verify as Cerberus-managed. If a local user with the same name already exists and ownership cannot be verified, the action fails closed.

Managed accounts can be configured so the user cannot change the password and the password does not expire unexpectedly. This keeps lifecycle control tied to session preparation and revocation rather than personal user habits.

This local account model is not used on Windows domain controllers. Local SAM account mutation is unsupported there, so the agent treats the action as unavailable.

Evidence left behind

The record shows context, not the password:

• which resource was prepared,
• which person and assignment were part of the decision,
• whether the account was created, rotated, disabled, or deleted,
• when the session started and closed,
• the outcome of the revocation action.

The review moves from “who received the password?” to “which access decision prepared which local account state?”