Intune Endpoint Privilege Management Adds Support for Elevation in User Context

Intune Endpoint Privilege Management Now Supports Elevation in User Context

Microsoft has added a long-awaited feature to Intune Endpoint Privilege Management (EPM) — the ability to elevate processes using the current user account instead of the system’s virtual account. This new capability enhances compatibility, improves network access, and resolves several limitations that administrators faced with the default virtual account method.

---

🔍 Why This Matters

Previously, EPM could only elevate applications using a virtual account (identified by the special SID S-1-5-110). While this method was secure, it created practical problems:

• Kerberos tickets weren’t available, causing issues accessing network shares or domain resources.
• Registry operations in HKCU (HKEY_CURRENT_USER) could fail because the process didn’t run as the actual user.
• Applications launched from network paths couldn’t authenticate correctly.

By introducing the option to elevate as the current user, Microsoft has made it easier to run administrative tasks that rely on user-specific resources or profiles—without breaking access or requiring workarounds.

---

⚙️ How to Configure It in Intune

Setting up “Elevation in user context” is straightforward. Here’s the step-by-step process:

1. Go to Intune Admin Center → Endpoint security → Endpoint Privilege Management → Elevation rules.
2. Create a new EPM policy or edit an existing one.
3. In the Elevation type section, you’ll now see a new option:
   • Elevate as current user (in addition to the existing “Elevate with EPM virtual account”).
4. Define the file path or hash of the executable you want to allow. For example: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
5. Choose how the elevation is triggered:
   • User confirmation (the only method currently supported for this mode).
   • Require justification (optional, for audit logs).
6. Add a rule description, set any scope conditions (like file version or publisher), and assign it to a target device group.

This can also be tested with a support request template:

• Right-click the executable you want to test (like PowerShell).
• Choose Run with elevated access.
• Select Create rule with these file details to generate a policy draft from that process.

---

💻 User Experience

When a user launches an application that matches the rule:

1. They right-click the file and choose “Run with elevated access.”
2. A UAC-like prompt appears asking for confirmation.
   • On a secure desktop, the user will need to verify their identity using Windows Hello, PIN, or password.
3. Once approved, the process launches under the user’s own Entra ID account, not the MEM-managed virtual account.

You can confirm this by checking the process in PowerShell or Task Manager — it’ll run as the user’s name, not S-1-5-110.

This ensures:

• HKCU registry writes work correctly.
• Profile-based paths (like %APPDATA%) remain accessible.
• Network drives and Kerberos-authenticated resources are available as expected.

---

🧩 Use Cases

While elevating in user context isn’t needed for every task, there are specific scenarios where it’s essential:

1. Running applications from a network share
   • Virtual accounts can’t authenticate to SMB shares.
   • This new method allows elevation while maintaining network access.
2. Installing client-server software
   • Some installers connect to a server during setup.
   • Running as the current user ensures seamless access to those network resources.
3. Updating line-of-business (LOB) apps
   • Applications that store user-specific data in HKCU or user profile directories now install and update correctly.
4. Custom scripts requiring profile access
   • PowerShell scripts that depend on current user paths can now run elevated without losing context.

---

🔒 Best Practices

While the new feature is convenient, Microsoft still recommends using the virtual account method for most elevation scenarios because it isolates the elevated process from the user’s session, reducing risk. Use elevation as current user only when required by functionality.

Best practice checklist:

• ✅ Use “Elevate with virtual account” whenever possible.
• 🔄 Switch to “Elevate as current user” only for apps that need network or profile access.
• 🧠 Clearly document elevation rules and their justification.
• 📜 Review EPM logs in Intune for elevation requests and approvals.
• 🚫 Avoid granting elevation to high-risk binaries (e.g., cmd.exe or regedit.exe) unless absolutely necessary.

---

🧭 Troubleshooting and Validation

After applying the policy, you can verify the behavior:

1. Check Process Context:
   In PowerShell, run: whoami
   • It should return your Entra ID username when elevated as current user.
   • It would return a virtual account when using the default mode.
2. Validate Network Access:
   Attempt to access a shared folder or run: Test-Path \\Server\Share
   • The command should succeed under user context elevation.
3. Confirm Audit Logs:
   Review EPM audit logs in Intune or Event Viewer under
   Applications and Services Logs > Microsoft > Windows > EPM.
   • Events will show the elevation type, file path, and user identity.

---

🧱 Security Implications

This new elevation method is powerful but must be managed carefully:

• Since processes run as the same user, malware that compromises the session could potentially exploit this feature if rules are too permissive.
• Always combine EPM rules with Conditional Access, Defender Smart App Control, and Application Control policies (WDAC) for layered security.
• Regularly audit elevation logs and remove rules that are no longer necessary.

---

🏁 Conclusion

The ability to elevate processes as the current user in Intune Endpoint Privilege Management bridges an important gap in enterprise administration. It simplifies workflows that depend on user-specific permissions, network shares, or HKCU registry access—without requiring domain admin credentials or local admin rights.

This change aligns Microsoft’s EPM with established privilege management solutions and gives IT admins more flexibility in handling real-world application elevation needs.

In short:

• Secure tasks remain elevated under control.
• Network-based workflows now function properly.
• User productivity improves, and the risk of unsupported workarounds is reduced.

---