One of the most asked features just arrived in Intune Endpoint Privilege Management, the option to not only elevate a process using the virtual account, but also allow it within the current user session, eliminating challenges with network access due to missing Kerberos tickets, but it now also allows to elevate programs that tries to write to HKCU and had issues when being ran as a different user.
How to configure
Let’s start on how you can use the new feature, fortunately it’s pretty easy, they just added a new elevation type “Elevate as current user” in the EPM Policy:
For the demo, I will use an existing support approval request for powershell.exe as a basis. Just imagine powershell.exe is your line-of-business application you want to elevate… First thing is to open the support approval request and select “Create rule with these file details” so we don’t have to fill them in manually:
No need to actually approve the request, as we will only use it as a template:
Now that we have the rule available, we can modify it as we need, add a description or similar:
And assign it to a group of our choice:
User experience
Elevation in user context currently only supports a “user confirmed” like style, no automatic rules are currently possible. So, when we start our lob app by right clicking and selecting “Run with elevated access”, we are getting prompted, if we want to continue:
And are then asked on secure desktop to confirm our identity by entering our password or if available Windows Hello for Business PIN again, to make sure it’s actually us.
In PowerShell we can easily see, the process is not started in the MEM\…
SID (S1-5-110) User as usual, but directly in my Entra ID Account:
Which means, not only apps that write to HKCU or the User profile will now work fine, but we can also access network shares, as we have access to our Kerberos tickets just like we would have on our normal account:
Use cases / Best Practices
In general, it is recommended that you use the more secure option to elevate your application in the virtual account wherever possible, however there are certain use cases that only work in the same user account. One example could be a lob app that is started from a network share, which would not be accessible in the virtual account. Another example could be the installation of a client server application that requires access to the server during the installation.
Conclusion
In my opinion, having the option to elevate in the current user context is a game changer. Most other EPM Tools already had this option available, now it is also available in a 1st party solution. Until now we had to rely on unsupported solutions like mmeierm/NTCreateTokenSample, which internally uses a not documented NT API that could stop working at any time.
Leave a Reply