Hello guys,

Recently, I've had a user not being able to install his setup created with Advanced Installer on a machine where the Code Integrity (Device Guard) policy was enabled.

In today's article, since I familiarized myself with the topic, I will try to explain what this policy is and how to configure it as such you will be able to install the setup created with Advanced Installer there.

Device Guard is a policy that allows organizations to lock down devices in a way that provides advanced malware protection against new and unknown malware variants by blocking anything other than trusted apps—which are apps that are signed by specific software vendors, the Windows Store, or even your own organization.

Now, the issue our users encountered is the fact that some resources from the project (such as temporary fles, custom actions, etc.) are signed with our own certificate, while the resources from the setup (e.g. the customer files) are signed with his own certificate.

As previously mentioned, the solution would be to add both our certificate and the user's certificate to the policy, so that the setup becomes "trustworthy".

Turning on this policy is quite easy as you'll see in the following steps. However, it's the configuration which is a bit more complicated at it requires some PowerShell knowledge.

Here's how to enable the policy:

1. open the Group Policy Editor

2. navigate to "Computer Configuration" --> "Administrative Templates" --> "System" --> "Device Guard"

If you double click on the policy, you will see that it can be easily enabled:

However, it requires as input the path to the configuration file (as I previously explained).

Below we'll be discussing how to create a Device Guard policy. As previously mentioned, for this we will need PowerShell for which I will try to explain each cmdlet.

Note: Of course, for this, please use a Virtual Machine

Note: Open a PowerShell window, create a "temp" folder (or whatever name you want) under C:\ and navigate there in PowerShell.

1. first of all, we need to scan a reference system to create an XML policy file. To do so, we will use the "New-CIPolicy" cmdlet.

Explanation:

The New-CIPolicy cmdlet creates a new Code Integrity (CI) policy, which is a set of rules that define what code is allowed to run on a system. The -FilePath parameter specifies the path to the file where the policy will be saved. The -Level parameter specifies the level of the policy, which can be either "Publisher" or "System". The "Publisher" level allows code from trusted publishers to run, while the "System" level allows only code that is signed by Microsoft to run. The -UserPEs parameter specifies that the policy should apply to user-mode Portable Executable (PE) files, which are executable files that run in user mode, rather than kernel mode. The -ScanPath parameter specifies the path to a directory that will be scanned for executables to include in the policy.

We restricted New-CIPolicy to scanning only the system32 folder. This should capture most files that Windows needs to boot and run. We will scan the Program Files folder separately, which will generate a second XML file, policyprogfiles.xml, that we can merge with policysys32.xml.

2. we will repeat step 1), this time for the Program Files folder
3. we will then merge the two, using the Merge-CIPolicy cmdlet
By default, the New-CIPolicy always creates policies in audit mode. We will need to enforce policies by deleting the audit-mode rule from the XML file.

When a Code Integrity (CI) policy is created in audit mode, it is used to monitor and log any violations of the policy, but it does NOT block the execution of code that violates the policy. This is useful for testing and debugging purposes, as it allows you to see what code would be blocked if the policy were enforced.
4. convert the XML into a Device Guard policy using ConvertFrom-CIPolicy
We now have the configuration file for our Device Guard Policy - hooray!

Let's see how this looks like in practice, shall we?

Let's click "Apply" then "Ok"

Note: We must reboot the machine in order for the policy to take effect.

After the reboot, let's try to launch the setup created with Advanced Installer (which should be signed). Upon launching the MSI, this should be the encountered message:

Now about the "fix", as mentioned at the start of this article, we should add the certificates to be "trusted" by the policy. To do so, considering the points above (1 to 4), we would have a point 3.5 (between 3 and 4) where we would do that.
Explanation:

This cmdlet allows you to specify a code signing certificate and specify that any code signed with that certificate is allowed to run on the system. This can be useful for allowing code from a trusted publisher to run, while still blocking code that is not signed or is signed by an untrusted publisher.

We would need to do that for both the certificate you are using to sign the setup and our certificate.

We then need to reconvert the XML file to BIN, add it to the policy and reboot the machine once again.

After the reboot, you should now be able to install the setup created with Advanced Installer.

Hope this helps!

Best regards and a Merry Christmas,
Catalin

Catalin wrote: ↑

Fri Dec 23, 2022 4:35 pm

After the reboot, you should now be able to install the setup created with Advanced Installer.

Hi @Catalin,

First of all thanks so much for your post. It was so helpful to understand how to configure Windows Device Guard policy.

I have a problem with this in Microsoft Windows 10 Enterprise 2016 LTSB OS Version: 10.0.14393 N/A 14393

I have followed all the steps and in this version of Windows the enable or diable policy are a little bit different, following microsoft docs with power shell I can enable or disable the policy successfully but the installer didn't work.

I have try first with the latest Windows 10 version and with the guide everything works well but with this Enterprise LTSB version using the same policy the installer is failing. It can start because I have added our company cert to polocy file (also AI Cert) and before showing the first installer screen it fails with the policy message popup.

Also I have noticed that using the Windows WDAC Wizard it adds certs also with issuing CA. Like this one Can you please try to reproduce the issue with this windows version? For me it wouldn't be a problem to connect with you in a meeting if it is helpful for you.

With regards,

Hello Juan,

First of all, you are always welcome!

I am glad to hear my article was of help for you.

Unfortunately, regarding Windows 10 LTSB, I'm afraid that I'm not really familiar with and therefore I can't really assist.

I think the best way to work this around would be with the help from someone over at Microsoft that is more knowledgeable in this version of Windows and Device Guard.

Thank you for your understanding!

Best regards,
Catalin

Catalin wrote: ↑

Fri Jun 23, 2023 1:52 pm

I think the best way to work this around would be with the help from someone over at Microsoft that is more knowledgeable in this version of Windows and Device Guard.

Hi Catalin,

I would really appreciate if you can take a further look on that because I have discovered an strange thing in that windows version.
With policy enabled on audit mode I can run other installers and I can see events in the Windows Event Viewer saying that the installer did not meet policy requirements, but with AI installer I cannot run it, I get a windows error popup with the following message.

This installation is forbidden by system policy

But no event is registered in Code Integrity section of Event Viewer. I can only see one event in Application Section with MsiInstaller source with following message.

The description for Event ID 1044 from source MsiInstaller cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event: C:\Users\User\AppData\Roaming\Company\installer\install\installer_setup.msi

(NULL) (NULL) (NULL) (NULL) (NULL) the message resource is present but the message is not found in the string/message table

Taking this strange behavior in chance It seems that policy is correctly configurer but there is something more related that is affecting specially to AI installers.

With regards,

Hello Juan,

I actually remembered I had some customers in the past with the exact same error. This is indeed caused by a policy, but by a different one as per my tests.

Could you please try running the setup as administrator and let me know if that helps?

If the installation package is an MSI, please open CMD with "Run as administrator" and run the MSI from there using msiexec:
If the package is an EXE, you can simply right click on it and "Run as administrator".

Are you an administrator on that machine?

If not, could you please contact an administrator and make sure that the following policy is also not enabled: Computer Configuration --> Administrative Templates --> Windows Components --> Windows Installer --> "Prohibit non-administrators from applying vendor signed updates"

Additionally, please also check the "Prohibit user installs" policy.

Hope this helps!

Best regards,
Catalin