Configuration Manager as a Managed Installer with Windows 10

Introduction

Windows 10 introduced a new set of features called Device Guard that helps enterprises protect their business critical machines against malware and other unwanted software. Key amongst these is a new application and software whitelisting technology known as configurable code integrity that, together with AppLocker, enables enterprises to strongly control what is allowed to run in their environment.

Like all whitelisting solutions, configurable code integrity and AppLocker policies can be complex to set up and difficult to maintain, particularly for enterprises whose software catalogs are large, ever-changing, and include applications from a variety of internal and 3^rd-party software developers. Enter the concept of the Managed Installer.

As of Windows 10 Enterprise Anniversary Edition, administrators can configure a new type of AppLocker rule that identifies a specific trusted installation authority, or Managed Installer. Any applications or other software (executables and .dll’s) that are installed by that specified installation authority will be automatically trusted by AppLocker and allowed to run without needing to create any other rules. Applications and software that are installed using any other mechanism will not pass the Managed Installer rule and will only run if explicitly allowed by another AppLocker rule. This will drastically reduce the overhead required to maintain whitelisting policy when deploying applications and software to systems protected by Windows AppLocker.

Managed Installer functionality is still in a prototype phase at the moment and does not yet have any associated user interface screens within Windows. However, thanks to collaboration between the ConfigMgr and Windows engineering teams it can be set up today and tested in any environment on machines with the ConfigMgr 1606 Technical Preview client that are running Windows 10 Enterprise with Windows Insider Program build 14367 or later with some caveats explained below. The Windows version and ConfigMgr client version are the only two prerequisites for this functionality. As noted, Managed Installer functionality currently only applies to AppLocker, but the Windows engineering team intends to integrate the functionality with Device Guard’s configurable code integrity feature in a later release. The remainder of this blog will provide detailed instructions on how clients can leverage this new functionality.

For additional reading about Device Guard and AppLocker, please consult the following resources:

Device Guard Documentation

Device Guard Deployment Guide

AppLocker Documentation

Blog: Managing Device Guard Configurable Code Integrity with existing ConfigMgr functionality

Creating the Custom AppLocker Policy

Creating an AppLocker Policy that contains a Managed Installer is most easily done in the Local Security Policy snap-in in Microsoft Management Console (MMC), then moving to the XML editor of your choice. This can be done with similar workflows on any recent version of Windows, but in this example a Windows 10 client is used.

1. From the Windows Start menu, type “secpol.msc” and then press enter to launch the MMC snap-in. Once the console opens, navigate to Application Control Policies > AppLocker > Executable Rules.
   
2. Right click Executable Rules and create a new rule that allows “Everyone” to run CCMExec.exe based on a condition of your choice. For this example, a File Path condition has been selected (this is the least secure option but it should allow readers to copy the policy used here for basic testing).
   
3. Once the rule has been created it will appear in the console. Now, export the policy XML for editing. Right-click Applocker in the navigation pane and select Export Policy… highlighted below.
   
   The exported policy XML will look similar to the example below. The three default rules are present, as well as the new file hash rule for CCMExec.exe, highlighted in yellow.
4. Next, duplicate the entire EXE rule collection via copy-paste, and then remove the default rules in the duplicate version. The original CCMExec.exe file path in the first rule collection can also be deleted at this point. Change the value of the Type attribute on the new rule collection to “ManagedInstaller”. What remains is a new Rule Collection of type “ManagedInstaller” and an EXE rule collection that contains only the original (in this case default) rules.
   
5. Now that the Managed Installer rule collection has been created, the Services Enforcement extension that was introduced in the first release of Windows 10 must be added. To add the extension, that allows for the enforcement of AppLocker policies against Windows Services, paste the below into your policy inside the EXE rule collection. You can see the result highlighted in green in the below.Insert this text:

           <RuleCollectionExtensions>
               <ThresholdExtensions>
                   <Services EnforcementMode="Enabled" />
               </ThresholdExtensions>
           </RuleCollectionExtensions>
   

6. Finally, select the Enforcement mode for the EXE and Managed Installer rule collections. The possible options are “Notconfigured”, “AuditOnly”, or “Enabled”. They have the following significance:
   • NotConfigured – No enforcement or auditing occurs.
   • AuditOnly – Applications and executables are not blocked from running by AppLocker, but logging occurs in the client event logs (visible in Event Viewer under Applications and Services Logs > Microsoft > Windows > AppLocker) whenever an application or executable is allowed to run or would have been blocked if enforcement mode had been enabled. Note: Logging for Managed Installer rules is shared with the logging for EXE rules. The only visible difference between the EXE rule log entries and the Managed Installer log entries, both found in Event Viewer under Applocker > EXE and DLL is that the rule type is specified in the details tab in the information pane when a given log entry is selected.
   • Enabled – Applications and executables in violation of the AppLocker policies are blocked from running.

   The recommended way of configuring AppLocker is to set up your policy and first set the enforcement mode to AuditOnly and then examine the event logs on the client machine to assess whether the policy is working correctly. Once the correctness of the policy has been adequately verified, then enforcement mode can be changed to enabled. Extreme care should be taken when auditing AppLocker policies because if they are configured incorrectly it can cause severe instability on affected machines.

   To complete this example, the policy enforcement mode will be changed to AuditOnly in this case. The change is highlighted in blue.

   With this final change the policy is ready to be saved and subsequently deployed. Once the policy has been validated and client event logs appear to be exhibiting the desired behavior, then the values of EnforcementMode highlighted below in blue can be changed to Enabled to enforce the new AppLocker policy (the policy must also be redeployed for the changes to take effect).
   

Configuring Client Devices

Four steps are required to configure clients to treat ConfigMgr as a Managed Installer. These can be accomplished with via Group Policy or using ConfigMgr’s configuration Items, programs, or task sequences, and PowerShell. In this example a short PowerShell script is used and can be deployed in a package containing both the script and the AppLocker policy XML file. The script must be run with Administrative privileges to have the desired result. Note that these commands can be run from any folder except for the step to set the AppLocker policy, which needs to be run from the folder where the policy XML file is located.

1. Start Windows Application Identity services
   The PowerShell command to accomplish this is as follows:

   PS C:\WINDOWS\system32> AppIdtel start

2. Create a custom DWORD in the client registry
   To configure the ConfigMgr client to behave as a Managed Installer, the following registry DWORD must be added with a value of “1”.

   HKLM\SOFTWARE\Microsoft\CCM\EnableManagedInstaller

   This mechanism for changing the client behavior is subject to change in subsequent releases once this functionality has its own Configuration Manager Console user interface screen. This can be accomplished using reg.exe that can be executed from PowerShell as follows:

   PS C:\WINDOWS\system32> reg.exe add HKLM\SOFTWARE\Microsoft\CCM /v EnableManagedInstaller /t REG_DWORD /d "1" /f

3. Deploy the custom AppLocker policy that was created above
   AppLocker policies are often deployed via Group Policy, but in this example the policy will be applied using one of the AppLocker PowerShell cmdlets to apply policy from the policy XML file distributed in the same package as the script. The PowerShell command for this is:

   PS C:\WINDOWS\system32> set-ApplockerPolicy -XmlPolicy AuditPolicy.xml

4. Restart the client SMS Host Agent service (CCMExec), or restart the device
   The final step to configure clients is to restart the CCMExec service that can be accomplished by executing the net.exe command from PowerShell as follows:

   PS C:\WINDOWS\system32> net stop ccmexec
   PS C:\WINDOWS\system32> net start ccmexec

These four sets of commands can be combined into a simple PowerShell script by copying the lines from above into a text file and naming the file with a .ps1 file extension. The resulting script looks like the below.

AppIdtel start
reg.exe add HKLM\SOFTWARE\Microsoft\CCM /v EnableManagedInstaller /t REG_DWORD /d "1" /f
set-ApplockerPolicy -XmlPolicy AuditPolicy.xml
net stop ccmexec
net start ccmexec

The above should be saved to a .ps1 PowerShell script file and that file can then be distributed along with the policy XML file created above to be run on clients using a required package and program. Clients that have run the script will treat ConfigMgr as a Managed Installer. At time of writing, when using Windows Insider Preview build 14367, packages and programs deployed from ConfigMgr 1606 Technical Preview with programs set to run with administrative privileges will be trusted automatically. All other deployments from the same ConfigMgr version will be automatically trusted by clients running an upcoming Windows Insider Program Fast Ring build. This blog will be updated to reflect this upon the release of that build of Windows. To validate the policy once it has been deployed, normal application, update, and package deployments should be made to the clients (taking the aforementioned caveats into consideration) and then the local client event logs should be examined to ensure that no trusted software is in violation of both the EXE and Managed Installer AppLocker rules. Software that is allowed by at least one of these rules will be allowed to run. Once the policy has been validated, the AppLocker policy should be edited so that EnforcementMode is set to “Enabled”, and then the AppLocker policy deployment step (and only this step) should be re-run to update the policy on the client.

Once this is complete then the original goal has been accomplished! The client has been locked down and only existing software and new software deployed from ConfigMgr will be allowed to run on the client device.

Let us know what you think about the Managed Installer functionally with Configuration Manager Technical Preview. To provide feedback or report any issues with the functionality included in this Technical Preview, please use Connect. If there’s a new feature or enhancement you want us to consider including in future updates, please use the Configuration Manager UserVoice site.

Thanks,

Dune Desormeaux, Program Manager, Enterprise Client and Mobility
Jeffrey Sutherland, Principal Lead Program Manager OS Enterprise and Security

Configuration Manager Resources:

Documentation for System Center Configuration Manager Technical Previews
Documentation for System Center Configuration Manager
System Center Configuration Manager Forums
System Center Configuration Manager Support
System Center Configuration Manager Technical Preview 5 (v1603)