Using Visual Studio with Microsoft Endpoint Privilege Management, some notes

Today, I share some notes about configuring Microsoft Endpoint Privilege Management for Visual Studio.

Endpoint Privilege Management (EPM) is a feature within Microsoft Intune that allows standard users to perform tasks that typically require administrative privileges. This means users can install applications without needing full admin rights.

Visual Studio (VS) seems to be one of the most challenging applications to elevate via EPM. In this post, I share some information from my investigation to get Visual Studio working with EPM. I’m not saying that this is the way to get Visual Studio to work, but it’s a way to get it to work. It is up to the person who implements this to determine whether this way is the right one, because there are some complications by supplying VS with EPM.

In our journey to elevate Visual Studio with Endpoint Privilege Management with Microsoft Intune, we first started to investigate the elevation of Visual Studio itself. We tried to configure EPM for VS without allowing the automatic elevation of child processes. This turned out to be impossible as lots and lots of child processes are involved, related to Visual Studio. We allowed child processes to elevate automatically for Visual Studio.

This allowed us to install certain extensions, the extensions that are installed directly in VS itself. But we also realized there is an option to start command-line tools from VS. This means you have an elevated PowerShell/ command prompt. So, allowing automatic child process elevation from Visual Studio, is absolutely not a good idea. But unfortunately, because of the long list of child processes involved in this process, it seems too hard to create rules for every child process.

The next approach we investigated was to allow the elevation of Visual Studio Installer. VS Installer allows us to repair VS and install, for example, Workloads. Again, lots and lots of child processes are involved when elevating VS Installer and, for example, installing a workload, so child processes need to be automatically elevated. But at least it seems we can’t start an elevated command prompt.

But VS Installer doesn’t allow us to install VSIX Extensions, the extension type that is often used to install an extension directly from Visual Studio. When a (VSIX) extension is installed directly from VS, VSIXInstaller is started to handle the installation of the extension. So we started to investigate the elevation of VSIXInstaller with EPM. It turned out that a lot of child processes are involved in installing these extensions. It also made us realize that when we install such an extension directly from VS of by downloading it from the marketplace, VSIXInstaller is started automatically, and (currently) EPM can’t handle the elevation of this when the elevation type is set to user confirmed. But it does work fine when we set elevation type to automatic.

To summarize this;
To make changes, like installing workloads and installing VSIX extensions for Visual Studio, we should allow VS Installer and VSIXInstaller to be elevated via Endpoint Privilege Management. And, unfortunately, it seems about impossible to get the job done without allowing child processes to elevate automatically.

If you now think, ok, allowing all child processes is not ideal, but better than providing full administrator permissions to the end user, let’s move on with setting up the EPM Elevation rules.

Setting up the elevation rules policy for VS Installer and VSIXInstaller

An EPM rule contains information on the executable you allow to elevate, and we need to use a file hash or signature source. As the file hash changes frequently, I suggest using the signature source, the certificate with which the file is digitally signed.
When we select such a signature source, we have the choice to use the publisher or certificate authority. We first tested with the publisher certificate, but we noticed we frequently needed to change the certificate in the EPM profile, and therefore changed this to the certificate authority.

The easiest way to get the correct information related to the certificate on the local device is by using the EpmTools PowerShell module.
By running the below command we get the information we need, including the certificates themselves for Visual Studio Installer:

Get-FileAttributes -FilePath 'C:\Program Files (x86)\Microsoft Visual Studio\Installer\setup.exe' -CertOutputPath C:\Temp\VSInstaller\ -Verbose

It also shows if it’s the publisher certificate or not.
And it shows us the file attributes which we can later use in the EPM rule.

If we check the Digital signatures tab of the properties of the executable, we see the same certificates.

The publisher certificate is valid for about a year. But we noticed we needed to change the certificate in the EPM rule more often.

The certificate authority certificates are valid for a much longer period.

We can run the same command, but for the VSIXInstaller:

Get-FileAttributes -FilePath 'C:\Program Files (x86)\Microsoft Visual Studio\Installer\resources\app\ServiceHub\Services\Microsoft.VisualStudio.Setup.Service\VSIXInstaller.exe' -CertOutputPath C:\Temp\VSInstaller\ -Verbose

Let’s switch to the Microsoft Intune portal to set up the EPM elevation rules policy for VS Installer and VSIXInstaller.

Before we set up the EPM rules policy, we first create a Reusable setting for the certificate authority certificate. With such s reusable setting, we can select the certificate later in the EPM Rules policy, instead of uploading it multiple times.

Under the Endpoint Security, Endpoint Privilege Management section, we create the reusable setting.

Upload the certificate authority certificate and create the setting.

Next, we create the Elevation rules policy in which we add an elevation rule per application (executable).

Add a Rule name and select the elevation type of your choice.
Select Allow all child processes under Child process behavior, add setup.exe as File name, and add the File Path.
Select Use a certificate file in reusable settings as signature source.

Select the previously created reusable setting that holds the certificate authority certificate.

Finish the elevation rule by adding the other file attributes.

Add a second elevation rule, this time for VSIXInstaller.
This time, select Automatic as Elevation type.

Don’t forget the file attributes.

With these two rules, the end user can elevate the processes for VS Installer and VSIXInstaller.

The end-result

With this EPM configuration in-place we are able to install the (VSIX) extension directly from Visual Studio itself without elevating Visual Studio.

VSIXInstaller is automatically started and elevated when VS is closed to install the extension.

The extension is indeed installed when VS is opened again.

This also works when we download a VSIX extension from the marketplace.
Just double click the file after downloading it, and VSIXInstaller handles the installation.

When we start Visual Studio Installer elevated via EPM, we can update, repair and make other changes to Visual Studio.

That’s it for this blog post.
Thanks for reading and happy testing!