> For the complete documentation index, see [llms.txt](https://newdocs.keeper.io/en/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/deployment/deployment-reference/keeperusersession-ephemeral-account.md). # 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:
EventDefault behavior (MaintainKeeperAccount = false)
Keeper EPM service startsDelete any existing KeeperUserSession account, create a new one with a freshly generated password
Keeper EPM service stopsDelete the KeeperUserSession account
Keeper EPM service crashesOrphaned account cleaned up on next startup
Elevation performedPassword 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](/en/keeperpam/endpoint-privilege-manager/deployment/deployment-reference/maintainkeeperaccount-configuration.md) 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:**
ProperValue
Length40 characters (36-character GUID string + 4-character fixed suffix)
Uppercase lettersYes — included via GUID hex characters (A–F) and the suffix K
Lowercase lettersYes — included via GUID hex characters (a–f) and the suffix g
DigitsYes — included via GUID numeric characters and the suffix 1
Special charactersYes — GUID hyphens (-) and the suffix $
Cryptographic sourceGuid.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](#password-generation) 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 ```powershell Get-LocalUser -Name "KeeperUserSession" Get-LocalGroupMember -Group "Administrators" | Where-Object Name -like "*KeeperUserSession" ``` #### macOS ```bash dscl . -read /Users/KeeperUserSession dseditgroup -o checkmember -m KeeperUserSession admin ``` #### Linux ```bash 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](#password-generation). #### 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://newdocs.keeper.io/en/keeperpam/endpoint-privilege-manager/deployment/deployment-reference/keeperusersession-ephemeral-account.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.