deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 21:37:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #5896 from jsuther1974/master

Browse Source 
Updated managed installer docs
This commit is contained in:
Gary Moore 2021-10-28 17:43:03 -07:00 committed by GitHub
commit f304278263
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 218 additions and 335 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
windows/security/threat-protection/windows-defender-application-control/TOC.yml
View File

@ -108,6 +108,8 @@
href: querying-application-control-events-centrally-using-advanced-hunting.md href: querying-application-control-events-centrally-using-advanced-hunting.md
- name: Known Issues - name: Known Issues
href: operations/known-issues.md href: operations/known-issues.md
- name: Managed installer and ISG technical reference and troubleshooting guide
href: configure-wdac-managed-installer.md
- name: AppLocker - name: AppLocker
href: applocker\applocker-overview.md href: applocker\applocker-overview.md
items: items:

22
windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md
View File

@ -26,7 +26,7 @@ ms.technology: windows-sec
- Windows Server 2016 and later - Windows Server 2016 and later
> [!NOTE] > [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-object-model) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM specifies an object model and programming requirements that enable COM objects to interact with other objects. The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-object-model) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM specifies an object model and programming requirements that enable COM objects to interact with other objects.
@ -104,16 +104,16 @@ Example 3: Allows a specific COM object to register in PowerShell
Here's an example of an error in the Event Viewer (**Application and Service Logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script**): Here's an example of an error in the Event Viewer (**Application and Service Logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script**):
Log Name: Microsoft-Windows-AppLocker/MSI and Script<br/> > Log Name: Microsoft-Windows-AppLocker/MSI and Script<br/>
Source: Microsoft-Windows-AppLocker<br/> > Source: Microsoft-Windows-AppLocker<br/>
Date: 11/11/2020 1:18:11 PM<br/> > Date: 11/11/2020 1:18:11 PM<br/>
Event ID: 8036<br/> > Event ID: 8036<br/>
Task Category: None<br/> > Task Category: None<br/>
Level: Error<br/> > Level: Error<br/>
Keywords:<br/> > Keywords:<br/>
User: S-1-5-21-3340858017-3068726007-3466559902-3647<br/> > User: S-1-5-21-3340858017-3068726007-3466559902-3647<br/>
Computer: contoso.com<br/> > Computer: contoso.com<br/>
Description: {f8d253d9-89a4-4daa-87b6-1168369f0b21} was prevented from running due to Config CI policy.<br/> > Description: {f8d253d9-89a4-4daa-87b6-1168369f0b21} was prevented from running due to Config CI policy.
Event XML: Event XML:

2
windows/security/threat-protection/windows-defender-application-control/audit-and-enforce-windows-defender-application-control-policies.md
View File

@ -27,7 +27,7 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included. Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.

2
windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies.md
View File

@ -27,7 +27,7 @@ ms.technology: windows-sec
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included. Running Application Control in audit mode lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.

220
windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
View File

@ -1,6 +1,6 @@
--- ---
title: Configure authorized apps deployed with a WDAC-managed installer (Windows) title: Allow apps deployed with a WDAC managed installer (Windows)
description: Explains about how to configure a custom Manged Installer. description: Explains how to configure a custom Managed Installer.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -11,33 +11,31 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 10/19/2021 ms.date: 10/19/2021
ms.technology: windows-sec ms.technology: windows-sec
--- ---
# Configuring authorized apps deployed by a managed installer with AppLocker and Windows Defender Application Control # Automatically allow apps deployed by a managed installer with Windows Defender Application Control
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows 11 - Windows 11
- Windows Server 2016 and above - Windows Server 2019 and above
> [!NOTE] > [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
Windows 10, version 1703 introduced a new option for Windows Defender Application Control (WDAC), called _managed installer_, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager. With Windows Defender Application Control (WDAC), you can automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, using a feature called _managed installer_. Managed installer can help you better balance security and manageability when enforcing application control policies.
## How does a managed installer work? ## How does a managed installer work?
A new rule collection in AppLocker specifies binaries that are trusted by the organization as an authorized source for application deployment. When one of these trusted binaries runs, Windows will monitor the binary's process (and processes it launches), and then tag all files it writes as having originated from a managed installer. The managed installer rule collection is configured using Group Policy and can be applied with the Set-AppLockerPolicy PowerShell cmdlet. You can't currently set managed installers with the AppLocker CSP through MDM. Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they are tagged as originating from a managed installer.
Having defined your managed installers by using AppLocker, you can then configure WDAC to trust files that are installed by a managed installer. You do so by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules present for the file, WDAC will allow a file to run based on its managed installer origin. You can then configure WDAC to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, WDAC will allow it to run based purely on its managed installer origin.
Ensure that the WDAC policy allows the system/boot components and any other authorized applications that can't be deployed through a managed installer.
## Security considerations with managed installer ## Security considerations with managed installer
@ -47,7 +45,7 @@ Users with administrator privileges, or malware running as an administrator user
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control. If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. Extension of the installer's authorization could result in unintentional authorization of an executable. To avoid that outcome, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation. Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer ## Known limitations with managed installer
@ -59,88 +57,100 @@ Some application installers may automatically run the application at the end of
- The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run. - The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run.
## Configuring the managed installer ## Configure managed installer tracking with AppLocker and WDAC
Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and WDAC policy, with specific rules and options enabled. To turn on managed installer tracking, you must:
There are three primary steps to keep in mind:
- Specify managed installers, by using the Managed Installer rule collection in AppLocker policy. - Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs.
- Enable service enforcement in AppLocker policy. - Enable AppLocker's Application Identity and AppLockerFltr services.
- Enable the managed installer option in a WDAC policy.
## Specify managed installers using the Managed Installer rule collection in AppLocker policy ### Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs
The identity of the managed installer executable(s) is specified in an AppLocker policy, in a Managed Installer rule collection. Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
> [!NOTE]
> Only EXE file types can be designated as managed installers.
### Create Managed Installer rule collection 1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you are designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.
Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use a text editor to make the changes that are needed to an EXE or DLL rule collection policy, to specify Type="ManagedInstaller", so that the new rule can be imported into a GPO.
1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you are designating as a managed installer. Note that only EXE file types can be designated as managed installers. Below is an example using the rule type Publisher with a hash fallback but other rule types can be used as well. You may need to reformat the output for readability.
```powershell ```powershell
Get-ChildItem <exe filepath> | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Xml > AppLocker_MI_PS_ISE.xml Get-ChildItem ${env:ProgramFiles(x86)}'\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
``` ```
2. Manually rename the rule collection to ManagedInstaller 2. Manually change the rule collection Type from "Exe" to "ManagedInstaller" and set EnforcementMode to "AuditOnly"
Change: Change:
```powershell ```XML
<RuleCollection Type="Exe" EnforcementMode="NotConfigured"> <RuleCollection Type="Exe" EnforcementMode="NotConfigured">
``` ```
to: to:
```powershell ```XML
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly"> <RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
``` ```
An example of a valid Managed Installer rule collection, using Microsoft Endpoint Config Manager (MEMCM), MEM (Intune), PowerShell, and PowerShell ISE, is shown below. Remove any rules that you do not wish to designate as a Managed Installer. 3. Manually edit your AppLocker policy and add the EXE and DLL rule collections with at least one rule for each. To ensure your policy can be safely applied on systems that may already have an active AppLocker policy, we recommend using a benign DENY rule to block a fake binary and set the rule collection's EnforcementMode to AuditOnly. Additionally, since many installation processes rely on services, you need to enable services tracking for each of those rule collections. The following example shows a partial AppLocker policy with the EXE and DLL rule collection configured as recommended.
```xml ```xml
<AppLockerPolicy Version="1">
<RuleCollection Type="Appx" EnforcementMode="NotConfigured" />
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" > <RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
<FilePublisherRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Allow all" Description="Allow all" UserOrGroupSid="S-1-1-0" Action="Allow"> <FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions> <Conditions>
<FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*"> <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
<BinaryVersionRange LowSection="*" HighSection="*" />
</FilePublisherCondition>
</Conditions> </Conditions>
</FilePublisherRule> </FilePathRule>
<RuleCollectionExtensions> <RuleCollectionExtensions>
<ThresholdExtensions> <ThresholdExtensions>
<Services EnforcementMode="Enabled" /> <Services EnforcementMode="Enabled" />
</ThresholdExtensions> </ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions> </RuleCollectionExtensions>
</RuleCollection> </RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly"> <RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePublisherRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Allow all" Description="Allow all" UserOrGroupSid="S-1-1-0" Action="Allow"> <FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions> <Conditions>
<FilePublisherCondition PublisherName="*" ProductName="*" BinaryName="*"> <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
<BinaryVersionRange LowSection="*" HighSection="*" />
</FilePublisherCondition>
</Conditions> </Conditions>
</FilePublisherRule> </FilePathRule>
<RuleCollectionExtensions> <RuleCollectionExtensions>
<ThresholdExtensions> <ThresholdExtensions>
<Services EnforcementMode="Enabled" /> <Services EnforcementMode="Enabled" />
</ThresholdExtensions> </ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions> </RuleCollectionExtensions>
</RuleCollection> </RuleCollection>
<RuleCollection Type="Msi" EnforcementMode="NotConfigured" /> ```
<RuleCollection Type="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly"> 4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Microsoft Endpoint Config Manager (MEMCM)and Microsoft Endpoint Manager Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This ensures the policy will merge successfully on devices which may already have an AppLocker policy in place.
<FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
```xml
<AppLockerPolicy Version="1">
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions> <Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® INTUNE™" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE"> <FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Benign DENY Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
<FilePublisherRule Id="55932f09-04b8-44ec-8e2d-3fc736500c56" Name="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE version 1.39.200.2 or greater in MICROSOFT® INTUNE™ from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="MICROSOFT.MANAGEMENT.SERVICES.INTUNEWINDOWSAGENT.EXE">
<BinaryVersionRange LowSection="1.39.200.2" HighSection="*" /> <BinaryVersionRange LowSection="1.39.200.2" HighSection="*" />
</FilePublisherCondition> </FilePublisherCondition>
</Conditions> </Conditions>
@ -159,26 +169,26 @@ An example of a valid Managed Installer rule collection, using Microsoft Endpoin
</FilePublisherCondition> </FilePublisherCondition>
</Conditions> </Conditions>
</FilePublisherRule> </FilePublisherRule>
<FilePublisherRule Id="a8cb325e-b26e-4f52-b528-a137764cae42" Name="POWERSHELL.EXE, version 10.0.0.0 and above, in MICROSOFT® WINDOWS® OPERATING SYSTEM, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="POWERSHELL.EXE">
<BinaryVersionRange LowSection="*" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="a8cb325e-b26e-4f52-b528-a137764cae54" Name="POWERSHELL_ISE.EXE, version 10.0.0.0 and above, in MICROSOFT® WINDOWS® OPERATING SYSTEM, from O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="POWERSHELL_ISE.EXE">
<BinaryVersionRange LowSection="*" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection> </RuleCollection>
</AppLockerPolicy> </AppLockerPolicy>
``` ```
>[!NOTE] 5. Deploy your AppLocker managed installer configuration policy. You can either import your AppLocker policy and deploy with Group Policy or use a script to deploy the policy with the Set-AppLockerPolicy cmdlet as shown in the following PowerShell command.
>Since many installation processes rely on services, it is typically necessary to enable tracking of services. Correct tracking of services requires the presence of at least one rule in the rule collection. So, a simple audit-only rule will suffice.
```powershell
Set-AppLockerPolicy -XmlPolicy <AppLocker XML FilePath> -Merge -ErrorAction SilentlyContinue
```
6. If deploying your AppLocker policy via script, use appidtel.exe to configure the AppLocker Application Identity service and AppLocker filter driver.
```console
appidtel.exe start [-mionly]
```
Specify "-mionly" if you don't plan to use the Intelligent Security Graph (ISG).
> [!NOTE]
> Managed installer tracking will start the next time a process runs that matches your managed installer rules. If an intended process is already running, you must restart it.
## Enable the managed installer option in WDAC policy ## Enable the managed installer option in WDAC policy
@ -203,69 +213,11 @@ Below are steps to create a WDAC policy that allows Windows to boot and enables
Set-RuleOption -FilePath <XML filepath> -Option 13 Set-RuleOption -FilePath <XML filepath> -Option 13
``` ```
## Set the AppLocker filter driver to autostart 4. Deploy your WDAC policy. See [Deploying Windows Defender Application Control (WDAC) policies](windows-defender-application-control-deployment-guide.md).
To enable the managed installer, you need to set the AppLocker filter driver to autostart, and start it. > [!NOTE]
> Your WDAC policy must include rules for all system/boot components, kernel drivers, and any other authorized applications that can't be deployed through a managed installer.
To do so, run the following command as an Administrator: ## Related articles
```console - [Managed installer and ISG technical reference and troubleshooting guide](configure-wdac-managed-installer.md)
appidtel.exe start [-mionly]
```
Specify "-mionly" if you will not use the Intelligent Security Graph (ISG).
## Using fsutil to query SmartLocker EA
Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
#### Example:
```powershell
fsutil file queryEA C:\Users\Temp\Downloads\application.exe
Extended Attributes (EA) information for file C:\Users\Temp\Downloads\application.exe:
Ea Buffer Offset: 410
Ea Name: $KERNEL.SMARTLOCKER.ORIGINCLAIM
Ea Value Length: 7e
0000: 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................
0010: b2 ff 10 66 bc a8 47 c7 00 d9 56 9d 3d d4 20 2a ...f..G...V.=. *
0020: 63 a3 80 e2 d8 33 8e 77 e9 5c 8d b0 d5 a7 a3 11 c....3.w.\......
0030: 83 00 00 00 00 00 00 00 5c 00 00 00 43 00 3a 00 ........\...C.:.
0040: 5c 00 55 00 73 00 65 00 72 00 73 00 5c 00 6a 00 \.U.s.e.r.s.\.T.
0050: 6f 00 67 00 65 00 75 00 72 00 74 00 65 00 2e 00 e.m.p..\D.o.w.n...
0060: 52 00 45 00 44 00 4d 00 4f 00 4e 00 44 00 5c 00 l.o.a.d.\a.p.p.l.
0070: 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 i.c.a.t.i.o.n..e.x.e
```
## Enabling managed installer logging events
Refer to [Understanding Application Control Events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) for information on enabling optional managed installer diagnostic events.
## Deploying the Managed Installer rule collection
Once you've completed configuring your chosen Managed Installer, by specifying which option to use in the AppLocker policy, enabling the service enforcement of it, and by enabling the Managed Installer option in a WDAC policy, you'll need to deploy it.
1. Use the following command to deploy the policy.
```powershell
$policyFile=
@"
Raw_AppLocker_Policy_XML
"@
Set-AppLockerPolicy -XmlPolicy $policyFile -Merge -ErrorAction SilentlyContinue
```
2. Verify Deployment of the ruleset was successful
```powershell
Get-AppLockerPolicy -Local
Version RuleCollections RuleCollectionTypes
------- --------------- -------------------
1 {0, 0, 0, 0...} {Appx, Dll, Exe, ManagedInstaller...}
```
Verify the output shows the ManagedInstaller rule set.
3. Get the policy XML (optional) using PowerShell:
```powershell
Get-AppLockerPolicy -Effective -Xml -ErrorVariable ev -ErrorAction SilentlyContinue
```
This command will show the raw XML to verify the individual rules that were set.

183
windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md
View File

@ -1,5 +1,5 @@
--- ---
title: Configure a WDAC managed installer (Windows) title: Managed installer and ISG technical reference and troubleshooting guide (Windows)
description: Explains how to configure a custom Manged Installer. description: Explains how to configure a custom Manged Installer.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
@ -18,148 +18,75 @@ ms.date: 08/14/2020
ms.technology: windows-sec ms.technology: windows-sec
--- ---
# Configuring a managed installer with AppLocker and Windows Defender Application Control # Managed installer and ISG technical reference and troubleshooting guide
**Applies to:** **Applies to:**
- Windows 10 - Windows 10
- Windows 11 - Windows 11
- Windows Server 2016 and above - Windows Server 2019 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](feature-availability.md).
Setting up managed installer tracking and application execution enforcement requires applying both an AppLocker and WDAC policy with specific rules and options enabled. ## Using fsutil to query SmartLocker EA
There are three primary steps to keep in mind:
- Specify managed installers by using the Managed Installer rule collection in AppLocker policy. Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
- Enable service enforcement in AppLocker policy.
- Enable the managed installer option in a WDAC policy.
## Specify managed installers using the Managed Installer rule collection in AppLocker policy **Example:**
The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer rule collection. ```powershell
fsutil file queryEA C:\Users\Temp\Downloads\application.exe
### Create Managed Installer rule collection Extended Attributes (EA) information for file C:\Users\Temp\Downloads\application.exe:
Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, a text editor can be used to make the simple changes needed to an EXE or DLL rule collection policy to specify Type="ManagedInstaller", so that the new rule can be imported into a GPO. Ea Buffer Offset: 410
Ea Name: $KERNEL.SMARTLOCKER.ORIGINCLAIM
1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you are designating as a managed installer. Note that only EXE file types can be designated as managed installers. Below is an example using the rule type Publisher with a hash fallback, but other rule types can be used as well. You may need to reformat the output for readability. Ea Value Length: 7e
0000: 01 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................
```powershell 0010: b2 ff 10 66 bc a8 47 c7 00 d9 56 9d 3d d4 20 2a ...f..G...V.=. *
Get-ChildItem <exe filepath> | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher, Hash -User Everyone -Xml > AppLocker_MI_PS_ISE.xml 0020: 63 a3 80 e2 d8 33 8e 77 e9 5c 8d b0 d5 a7 a3 11 c....3.w.\......
``` 0030: 83 00 00 00 00 00 00 00 5c 00 00 00 43 00 3a 00 ........\...C.:.
0040: 5c 00 55 00 73 00 65 00 72 00 73 00 5c 00 6a 00 \.U.s.e.r.s.\.T.
2. Manually rename the rule collection to ManagedInstaller 0050: 6f 00 67 00 65 00 75 00 72 00 74 00 65 00 2e 00 e.m.p..\D.o.w.n...
0060: 52 00 45 00 44 00 4d 00 4f 00 4e 00 44 00 5c 00 l.o.a.d.\a.p.p.l.
Change 0070: 44 00 6f 00 77 00 6e 00 6c 00 6f 00 61 00 64 i.c.a.t.i.o.n..e.x.e
```powershell
<RuleCollection Type="Exe" EnforcementMode="NotConfigured">
```
to
```powershell
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
```
An example of a valid Managed Installer rule collection using Microsoft Endpoint Config Manager (MEMCM) is shown below.
```xml
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b93" Name="MEMCM - CCMEXEC.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="780ae2d3-5047-4240-8a57-767c251cbb12" Name="MEMCM - CCMSETUP.EXE, 5.0.0.0+, Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="*" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
``` ```
### Enable service enforcement in AppLocker policy
Since many installation processes rely on services, it is typically necessary to enable tracking of services.
Correct tracking of services requires the presence of at least one rule in the rule collection, so a simple audit only rule will suffice. This can be added to the policy created above which specifies your managed installer rule collection.
For example:
```xml
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >
<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Dummy Rule" Description="" UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
```
## Enable the managed installer option in WDAC policy
In order to enable trust for the binaries laid down by managed installers, the Enabled: Managed Installer option must be specified in your WDAC policy.
This can be done by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
Below are steps to create a WDAC policy that allows Windows to boot and enables the managed installer option.
1. Copy the DefaultWindows_Audit policy into your working folder from C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml
2. Reset the policy ID to ensure it is in multiple policy format and give it a different GUID from the example policies. Also give it a friendly name to help with identification.
Ex.
```powershell
Set-CIPolicyIdInfo -FilePath <XML filepath> -PolicyName "<friendly name>" -ResetPolicyID
```
3. Set Option 13 (Enabled:Managed Installer)
```powershell
Set-RuleOption -FilePath <XML filepath> -Option 13
```
## Set the AppLocker filter driver to autostart
To enable the managed installer, you need to set the AppLocker filter driver to autostart and start it.
To do so, run the following command as an Administrator:
```console
appidtel.exe start [-mionly]
```
Specify `-mionly` if you will not use the Intelligent Security Graph (ISG).
## Enabling managed installer logging events ## Enabling managed installer logging events
Refer to [Understanding Application Control Events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) for information on enabling optional managed installer diagnostic events. Refer to [Understanding Application Control Events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) for information on enabling optional managed installer diagnostic events.
## Deploying the Managed Installer rule collection
Once you've completed configuring your chosen Managed Installer, by specifying which option to use in the AppLocker policy, enabling the service enforcement of it, and by enabling the Managed Installer option in a WDAC policy, you'll need to deploy it.
1. Use the following command to deploy the policy.
```powershell
$policyFile=
@"
Raw_AppLocker_Policy_XML
"@
Set-AppLockerPolicy -XmlPolicy $policyFile -Merge -ErrorAction SilentlyContinue
```
2. Verify Deployment of the ruleset was successful
```powershell
Get-AppLockerPolicy -Local
Version RuleCollections RuleCollectionTypes
------- --------------- -------------------
1 {0, 0, 0, 0...} {Appx, Dll, Exe, ManagedInstaller...}
```
Verify the output shows the ManagedInstaller rule set.
3. Get the policy XML (optional) using PowerShell:
```powershell
Get-AppLockerPolicy -Effective -Xml -ErrorVariable ev -ErrorAction SilentlyContinue
```
This command will show the raw XML to verify the individual rules that were set.

4
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md
View File

@ -25,7 +25,7 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines. You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines.
@ -41,7 +41,7 @@ MEMCM includes native support for WDAC, which allows you to configure Windows 10
Note that MEMCM does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable WDAC altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot. Note that MEMCM does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable WDAC altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager).
## Deploy custom WDAC policies using Packages/Programs or Task Sequences ## Deploy custom WDAC policies using Packages/Programs or Task Sequences

16
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script.md
View File

@ -25,7 +25,7 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host. This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use PowerShell but can work with any scripting host.
@ -61,13 +61,15 @@ This topic describes how to deploy Windows Defender Application Control (WDAC) p
In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition. Deploying your policy via [MEM](/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune) or the Application Control CSP will handle this step automatically. In addition to the steps outlined above, the binary policy file must also be copied to the device's EFI partition. Deploying your policy via [MEM](/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune) or the Application Control CSP will handle this step automatically.
1. Mount the EFI volume and make the directory, if it does not exist, in an elevated PowerShell prompt: 1. Mount the EFI volume and make the directory, if it does not exist, in an elevated PowerShell prompt:
```powershell
mountvol J: /S
J:
mkdir J:\EFI\Microsoft\Boot\CiPolicies\Active
```
2. Copy the signed policy binary as `{PolicyGUID}.cip` to J:\EFI\Microsoft\Boot\CiPolicies\Active ```powershell
mountvol J: /S
J:
mkdir J:\EFI\Microsoft\Boot\CiPolicies\Active
```
2. Copy the signed policy binary as `{PolicyGUID}.cip` to `J:\EFI\Microsoft\Boot\CiPolicies\Active`.
3. Reboot the system. 3. Reboot the system.
## Script-based deployment process for Windows 10 versions earlier than 1903 ## Script-based deployment process for Windows 10 versions earlier than 1903

6
windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md
View File

@ -26,7 +26,7 @@ ms.localizationpriority: medium
- Windows Server 2016 and above - Windows Server 2016 and above
>[!NOTE] >[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
This topic covers tips and tricks for admins as well as known issues with WDAC. This topic covers tips and tricks for admins as well as known issues with WDAC.
Test this configuration in your lab before enabling it in production. Test this configuration in your lab before enabling it in production.
@ -40,12 +40,12 @@ In some cases, the code integrity logs where WDAC errors and warnings are writte
Installing .msi files directly from the internet to a computer protected by WDAC will fail. Installing .msi files directly from the internet to a computer protected by WDAC will fail.
For example, this command will not work: For example, this command will not work:
```code ```console
msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
``` ```
As a workaround, download the MSI file and run it locally: As a workaround, download the MSI file and run it locally:
```code ```console
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
``` ```