Admin Session - How it Works

Also known as Session Elevation or Administrator Access

Users can double-click the Admin By Request desktop icon or select the icon from tray tools and confirm that they want to initiate an Admin Session.

Any user given full session elevation gets full local admin rights on their system. Full session elevation mode is ideal for situations such as when elevated access to ‘system’ resources such as drivers or printers etc. is required, when a user needs elevation only for a specific amount of time, or when a Developer requires the use of multiple elevated applications.

As with ‘Run As’ mode, everything in the elevation session is audited, so you can see the reason why the person needs the elevation, anything installed, uninstalled, or run. Full Session elevation mode includes the ability to block the elevation of any system files (CMD.EXE etc.) whilst running elevated, and the ability to ‘force terminate’ any elevated processes once the timer has run down.

The Restricted Admin Session pattern

A common hardened deployment pattern uses Admin Session in combination with Lockdown settings and Pre-Approval rules to create a controlled session where only known-safe applications can be elevated - rather than allowing unrestricted elevation of anything the user chooses to run.

This pattern is useful when an organization needs to accommodate applications that trigger native Windows UAC rather than ABR's interception flow (for example, an installer that spawns msiexec.exe mid-installation) but does not want to give users a fully open elevation window.

Configuration:

1. Disable Run As Admin globally (or for the relevant Sub-Setting), so the only elevation path is through Admin Session.

2. Enable Admin Session with a short Access time appropriate to the expected task duration.

3. Optionally require approval and reason, or add MFA, to gate session start.

4. Under Lockdown settings for Windows: enable Deny elevating system files to prevent cmd.exe, regedit.exe, PowerShell, and similar tools from being elevated during the session.

5. Add Pre-Approval rules for the specific vendor certificates or applications that legitimately need elevation during the session.

Result:

During the Admin Session, only pre-approved applications matching the configured rules can elevate. Arbitrary UAC elevation attempts for system tools and unrecognized executables are blocked. The audit trail is complete, and the session is time-bounded.

This is substantially more secure than a standard LAPS account (which provides unrestricted access with no audit of what was actually done), and more practical than helpdesk-assisted one-at-a-time elevation for tasks requiring multiple elevated steps.

Relationship to Run As Admin

Admin Session and Run As Admin are both ABR elevation types, but they serve different use cases. Choosing the wrong one for a given task produces either an over-broad or an ineffective elevation. The table below captures the key differences:

	Run As Admin	Admin Session
What is elevated	A single, specific process	The user's full security token (entire session)
Scope	Only the target process and, where configured, its pre-approved children	All processes launched during the session window
Duration	For the lifetime of the elevated process	A configurable time window (default 15 minutes)
How it starts	Right-click > "Run as administrator," installer auto-trigger, browser download	ABR tray/menu bar icon > Request administrator access
Child processes	Do NOT automatically inherit elevation	All child processes launched during session are elevated
Auditlog category	RUN AS ADMIN	ADMIN SESSIONS
Tamper protection	Not applicable (no group membership change)	Yes (admin group snapshot/restore at session start and end)
Best when	You know exactly which application needs elevation	Multiple tools needed, or application requires persistent admin rights throughout

Many organizations start with approval requirements enabled for both elevation types during initial rollout, observe what users actually need, and then refine settings over time. A common stable configuration is: Run As Admin with reason required but no approval (fast-path with documentation), and Admin Session with reason required and approval required (gated for the broader elevation type).

Sub-Settings scope

Like all ABR settings, Admin Session configuration applies at Global Settings level by default and can be overridden per Sub-Setting for specific user or device groups.

Typical deployment patterns by user group:

• General users (Global Settings): Allow Admin Sessions On, Require approval On, Require reason On. Every session request is gated on approval.

• IT administrators (IT department Sub-Setting): Allow Admin Sessions On, Require approval Off, Require reason Off. IT staff can start sessions immediately without a reason form or approval wait, while still being fully audited.

• Developers (Developer Sub-Setting): Allow Admin Sessions On, Require approval Off, Require reason On, Access time extended (for example, 60 minutes). Developers document their work but can work at their own pace without waiting for approval.

• Kiosk or shared devices (device group Sub-Setting): Allow Admin Sessions Off. No elevation is possible on unassigned shared equipment.

The Access time setting is also configurable per Sub-Setting, allowing different groups to have different session durations. IT staff or developers with well-understood, lengthy workflows may need 30 or 60 minutes rather than the default 15.

Sub-Settings are evaluated top-down - the first Sub-Setting that matches the user or device wins for each setting. App Control (pre-approvals) is additive across matching Sub-Settings, but Authorization settings use first-match-wins.

Working with Admin Session

For more information, refer to Requesting Administrator Access:

• Windows

• macOS

• Linux