In some environments, certain applications may fail when executed by a standard user and elevated through Heimdal Privilege Elevation and Delegation Management (PEDM). This behavior is typically caused by how the application validates the original Windows logon token. It is considered a Windows design edge case and is not specific to Heimdal.
Symptoms
You may observe one or more of the following:
- Application launches but fails during execution
- Permission or access errors appear despite successful PEDM elevation
- Certain functions abort or behave inconsistently
- The application works when run from a local administrator session
- PEDM logs indicate elevation was successful
Cause
Some applications are designed to require privileges tied specifically to the original interactive logon token. These applications may:
- Validate the user session context
- Check token integrity
- Expect the user to be an administrator at logon
In a standard PEDM workflow:
- User logs in as standard user
- PEDM elevates the application
- Windows creates a linked administrative token
Although elevation succeeds, the elevated token is not identical to the original logon token. Applications that perform strict token validation may detect this difference and fail. This behavior originates from Windows UAC token architecture, not from PEDM functionality.
The Windows Media Creation Tool (MCT) is a well-known example of software that can exhibit this behavior. The Windows Media Creation Tool is a commonly observed example of this behavior. Because it expects permissions associated with the original logon token, it may fail when:
- The user is logged in as standard user
- The tool is elevated post-logon via PEDM
This makes it a representative edge case, but it is not the only application that can behave this way.
Scope / When This Occurs
This issue may occur when all of the following apply:
- The user logs in as a standard user
- PEDM performs post-logon elevation
- The application performs strict token or session validation
Only a small subset of applications typically exhibit this behavior.
Is This a Heimdal Limitation?
No. Any privilege management solution that performs post-logon elevation can encounter similar behavior with applications that require the original administrator logon token. The limitation stems from Windows security design and application implementation.
Workarounds
Option 1 — Run from an Administrative Session
Temporarily run the affected application while logged in as a local administrator.
Pros
- Highest compatibility
- Matches application expectations
Cons
- Requires controlled admin access
Option 2 — Use Enterprise-Supported Deployment Methods
Where applicable, use vendor-recommended enterprise deployment tools (for example, for Windows upgrades: WSUS, Intune, Configuration Manager, Windows Update for Business).
Pros
- Enterprise-grade approach
- Avoids token edge cases
- Fully supported by vendors
Cons
- Requires deployment infrastructure
Option 3 — Controlled Temporary Admin Exception
Where policy permits:
- Grant temporary local administrator rights
- Execute the application
- Remove elevated rights after completion
This preserves least-privilege principles while enabling the operation.
Security Considerations
PEDM operates as designed by:
- Enforcing least privilege at logon
- Elevating only the requested process
- Maintaining proper Windows token isolation
Applications that assume administrative rights at logon may conflict with modern least-privilege environments.