KeeperUserSession Ephemeral Account

Keeper Endpoint Privilege Manager (Keeper EPM) performs privilege elevation through a Keeper-managed local administrator account named KeeperUserSession. This account is created and controlled by the Keeper EPM service on the endpoint, used only to launch elevated processes on behalf of the requesting user, and its credentials are never exposed to end users.

This page documents the account's lifecycle, the password Keeper EPMgenerates for it, and the requirements MDM administrators need to reconcile between their local password policy and Keeper EPM's generator.

What the Account is Used For

When an elevation is approved and all required controls are satisfied, Keeper EPM launches the target process under the KeeperUserSession account rather than granting elevated rights to the requesting user's own account. This achieves just-in-time elevation without granting standing admin rights.

• On Windows, elevated processes are launched via ProcessStartInfo using KeeperUserSession credentials

• On macOS, KeeperUserSession credentials are supplied to authd through the Keeper EPM authorization plugin

• On Linux, temporary sudoers entries scoped to the KeeperUserSession account allow elevation of the approved command, then are removed

The account is a member of the platform's administrator group (Administrators on Windows, admin on macOS, sudo/wheel on Linux) so the operating system accepts it for privileged operations.

Account Lifecycle

By default, KeeperUserSession follows a create-on-start, delete-on-stop pattern:

Event	Default behavior (MaintainKeeperAccount = false)
Keeper EPM service starts	Delete any existing KeeperUserSession account, create a new one with a freshly generated password
Keeper EPM service stops	Delete the KeeperUserSession account
Keeper EPM service crashes	Orphaned account cleaned up on next startup
Elevation performed	Password may be rotated before or after use, depending on platform behavior

For hybrid Azure AD, Intune, or AD-synced environments where SID stability matters, the MaintainKeeperAccount setting can be enabled to persist the account across restarts. See the MaintainKeeperAccount configuration guide for when to enable it.

Password Generation

Keeper EPM generates the KeeperUserSession password using a cryptographically secure random number generator on the endpoint. The password is never transmitted in cleartext, never logged, and never displayed to the end user.

Generator specifications:

Length	40 characters (36-character GUID string + 4-character fixed suffix)
Uppercase letters	Yes — included via GUID hex characters (A–F) and the suffix K
Lowercase letters	Yes — included via GUID hex characters (a–f) and the suffix g
Digits	Yes — included via GUID numeric characters and the suffix 1
Special characters	Yes — GUID hyphens (-) and the suffix $
Cryptographic source	Guid.NewGuid() (CLR CSPRNG)

Password storage and handling

Regardless of platform, the KeeperUserSession password is treated as ephemeral secret material:

• Windows: Protected at rest using DPAPI (Data Protection API) with hardware-backed key storage

• Linux / macOS: Held in protected memory via SecurePasswordManager, passed to chpasswd / dscl over stdin (not the command line), and zeroed from memory immediately after use

• In-flight (all platforms): Delivered to the elevation mechanism through a per-elevation channel; never written to disk, never logged, never included in audit event payloads

The password is not persisted anywhere the end user or another administrator can retrieve it. There is no supported mechanism to view or recover the KeeperUserSession password — it is regenerated on each service restart (or, when MaintainKeeperAccount = true, on each rotation).

Interaction with Local Password Policy

The endpoint's own password policy is enforced by the operating system when KEPM sets or rotates the KeeperUserSession password. This means any policy your MDM, Group Policy, pwpolicy, or PAM configuration applies to local user accounts will also apply to KeeperUserSession.

If your local password policy is stricter than KEPM's generator produces, account creation or password rotation will fail and elevation will fall back to prompting the user for their own credentials. This is the intended failure mode — KEPM does not silently grant elevation when provisioning fails — but it defeats the just-in-time elevation model.

Common Local Policy Rules to Check

Review each of the following against KEPM's generator specifications before enforcing them on endpoints running KEPM:

• Minimum length — must be at or below KEPM's generated length

• Maximum length — must be at or above KEPM's generated length

• Required character classes — KEPM must generate at least one character from each required class

• Prohibited characters — none of KEPM's character pool may be on your prohibited list

• Consecutive identical characters → Not guaranteed to be avoided. The GUID-based generator makes no such guarantee; no deduplication pass is applied.

• Sequential characters (abc, 123) → Not guaranteed to be avoided. No filtering for sequential patterns is performed.

• Dictionary / common-password checks — cryptographically random passwords generally satisfy these, but confirm your checker doesn't reject on entropy heuristics

• Password history / rotation avoids last N passwords → No history tracking. Each rotation calls Guid.NewGuid() independently; previously used passwords are not stored or compared.

• Minimum password age — KEPM's rotation cadence may conflict with a minimum-age rule; on service restart, the account is deleted and recreated, bypassing this

Reconciling Policy Conflicts

If you identify a conflict between your local password policy and KEPM's generator:

1. Preferred: Adjust the local policy to accommodate KEPM's generator (KEPM's passwords are cryptographically strong and satisfy the intent of most policies even where they violate specific rules)

2. Alternative: Exclude the KeeperUserSession account from the restrictive policy — most password policy engines support per-account or per-group exemptions

3. Not recommended: Weaken the policy globally

Verifying the Account on an Endpoint

The KeeperUserSession account is a normal local user account and can be inspected with platform-standard tools.

Windows

Get-LocalUser -Name "KeeperUserSession"
Get-LocalGroupMember -Group "Administrators" | Where-Object Name -like "*KeeperUserSession"

macOS

dscl . -read /Users/KeeperUserSession
dseditgroup -o checkmember -m KeeperUserSession admin

Linux

id KeeperUserSession
getent group sudo | grep KeeperUserSession

The password itself is not readable by any of these tools by design.

Troubleshooting

Symptom: Elevation Succeeds but User is Prompted for their own Password

Cause: KeeperUserSession account exists but PAM / authd rejected its password. This usually means the password KEPM generated violated your local password policy at the moment it was set, and the account was created with a stale or empty password.

Diagnosis: Check KEPM service logs for EPHEMERAL_ACCOUNT_PASSWORD_SET_FAILED or platform-specific credential-set errors immediately after service start.

Resolution: Reconcile your local password policy against KEPM's generator specifications.

Symptom: Account is Not Created at All

Cause: KEPM service failed to invoke the account-creation command, or the OS rejected the username. Very rare, and typically caused by name-collision (an existing account or group named KeeperUserSession) or a policy that blocks local account creation entirely (some hardened MDM profiles).

Diagnosis: Check KEPM service logs for EPHEMERAL_ACCOUNT_CREATE_FAILED.

Resolution: Remove any conflicting KeeperUserSession object; confirm MDM does not block local account creation.

Symptom: Orphaned KeeperUserSession Profile Folders Accumulating (Windows)

Cause: On Windows, deleting and recreating the account leaves behind profile folders under C:\Users\KeeperUserSession.*. This is expected on the default (non-persistent) configuration.

Resolution: KEPM automatically cleans up orphaned profile folders on service startup. If cleanup is not occurring, verify the service is running as SYSTEM and has permission to modify C:\Users. Enabling MaintainKeeperAccount = true eliminates the churn entirely for environments where profile-folder accumulation is undesirable.

Security Considerations

• The KeeperUserSession account is a local administrator by design and by necessity — the operating system will not accept it for privileged operations otherwise

• When MaintainKeeperAccount = true, a local admin account persists across service stops; ensure your uninstall procedure removes it

• The account is created with IsHidden on macOS (via OpenDirectory) to keep it out of the login window and System Settings user list; on Windows it is a normal local account and will appear in lusrmgr.msc

• The password is not shared with any other Keeper service, is not synchronized to the Keeper Vault, and cannot be retrieved by Keeper support