mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-07-03 03:03:43 +00:00
Merge branch 'main' into pm-20230224-edu-managed-installer
This commit is contained in:
Paolo Matarazzo
GitHub
@ -27,7 +27,10 @@ Here's an example to set AssignedAccess configuration:
|
||||
1. Download the [psexec tool](/sysinternals/downloads/psexec).
|
||||
2. Run `psexec.exe -i -s cmd.exe`.
|
||||
3. In the command prompt launched by psexec.exe, enter `powershell.exe` to open PowerShell.
|
||||
4. Execute the following script:
|
||||
|
||||
Step 4 is different for Windows 10 or Windows 11
|
||||
|
||||
4. Execute the following script for Windows 10:
|
||||
|
||||
```xml
|
||||
$nameSpaceName="root\cimv2\mdm\dmmap"
|
||||
@ -87,3 +90,55 @@ $obj.Configuration = [System.Web.HttpUtility]::HtmlEncode(@"
|
||||
|
||||
Set-CimInstance -CimInstance $obj
|
||||
```
|
||||
4. Execute the following script for Windows 11:
|
||||
|
||||
```xml
|
||||
$nameSpaceName="root\cimv2\mdm\dmmap"
|
||||
$className="MDM_AssignedAccess"
|
||||
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
|
||||
Add-Type -AssemblyName System.Web
|
||||
$obj.Configuration = [System.Web.HttpUtility]::HtmlEncode(@"
|
||||
|
||||
<?xml version="1.0" encoding="utf-8" ?>
|
||||
<AssignedAccessConfiguration
|
||||
xmlns=http://schemas.microsoft.com/AssignedAccess/2017/config xmlns:win11=http://schemas.microsoft.com/AssignedAccess/2022/config>
|
||||
<Profiles>
|
||||
<Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">
|
||||
<AllAppsList>
|
||||
<AllowedApps>
|
||||
<App AppUserModelId="Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic" />
|
||||
<App AppUserModelId="Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo" />
|
||||
<App AppUserModelId="Microsoft.Windows.Photos_8wekyb3d8bbwe!App" />
|
||||
<App AppUserModelId="Microsoft.BingWeather_8wekyb3d8bbwe!App" />
|
||||
<App AppUserModelId="Microsoft.WindowsCalculator_8wekyb3d8bbwe!App" />
|
||||
<App DesktopAppPath="%windir%\system32\mspaint.exe" />
|
||||
<App DesktopAppPath="C:\Windows\System32\notepad.exe" />
|
||||
</AllowedApps>
|
||||
</AllAppsList>
|
||||
<win11:StartPins>
|
||||
<![CDATA[
|
||||
{ "pinnedList":[
|
||||
{"packagedAppId":"Microsoft.WindowsCalculator_8wekyb3d8bbwe!App"},
|
||||
{"packagedAppId":"Microsoft.Windows.Photos_8wekyb3d8bbwe!App"},
|
||||
{"packagedAppId":"Microsoft.ZuneMusic_8wekyb3d8bbwe!Microsoft.ZuneMusic"},
|
||||
{"packagedAppId":"Microsoft.ZuneVideo_8wekyb3d8bbwe!Microsoft.ZuneVideo"},
|
||||
{"packagedAppId":"Microsoft.BingWeather_8wekyb3d8bbwe!App"},
|
||||
{"desktopAppLink":"%ALLUSERSPROFILE%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Paint.lnk"},
|
||||
{"desktopAppLink":"%APPDATA%\\Microsoft\\Windows\\StartMenu\\Programs\\Accessories\\Notepad.lnk"}
|
||||
] }
|
||||
]]>
|
||||
</win11:StartPins>
|
||||
<Taskbar ShowTaskbar="true"/>
|
||||
</Profile>
|
||||
</Profiles>
|
||||
<Configs>
|
||||
<Config>
|
||||
<Account>MultiAppKioskUser</Account>
|
||||
<DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
|
||||
</Config>
|
||||
</Configs>
|
||||
</AssignedAccessConfiguration>
|
||||
"@)
|
||||
|
||||
Set-CimInstance -CimInstance $obj
|
||||
```
|
||||
@ -22,8 +22,7 @@ ms.date: 12/31/2017
|
||||
- Windows 10 Pro, Enterprise, and Education
|
||||
|
||||
> [!NOTE]
|
||||
> [!INCLUDE [Multi-app kiosk mode not supported on Windows 11](./includes/multi-app-kiosk-support-windows11.md)]
|
||||
> The use of multiple monitors isn't supported for multi-app kiosk mode.
|
||||
> The use of multiple monitors isn't supported for multi-app kiosk mode in Windows 10.
|
||||
|
||||
A [kiosk device](./kiosk-single-app.md) typically runs a single app, and users are prevented from accessing any features or functions on the device outside of the kiosk app. In Windows 10, version 1709, the [AssignedAccess configuration service provider (CSP)](/windows/client-management/mdm/assignedaccess-csp) was expanded to make it easy for administrators to create kiosks that run more than one app. The benefit of a kiosk that runs only one or more specified apps is to provide an easy-to-understand experience for individuals by putting in front of them only the things they need to use, and removing from their view the things they don't need to access.
|
||||
|
||||
|
||||
@ -18,7 +18,7 @@ ms.topic: how-to
|
||||
- Windows 11 Pro, Enterprise, and Education
|
||||
|
||||
> [!NOTE]
|
||||
> The use of multiple monitors isn't supported for multi-app kiosk mode.
|
||||
> The use of multiple monitors is supported for multi-app kiosk mode in Windows 11.
|
||||
|
||||
An assigned access multi-app kiosk runs one or more apps from the desktop. People using the kiosk see a customized Start that shows only the apps that are allowed. With this approach, you can configure a locked-down experience for different account types. A multi-app kiosk is appropriate for devices that are shared by multiple people. Here's a guide on how to set up a multi-app kiosk.
|
||||
|
||||
|
||||
@ -40,6 +40,10 @@ The table below provides support details for specific deployment scenarios. Boot
|
||||
|
||||
Alternatives to WDS, such as [Microsoft Configuration Manager](/mem/configmgr/) and [Microsoft Deployment Toolkit](/mem/configmgr/mdt/) (MDT) provide a better, more flexible, and feature-rich experience for deploying Windows images.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> [Microsoft Deployment Toolkit](/mem/configmgr/mdt/) (MDT) only supports deployment of Windows 10. It doesn't support deployment of Windows 11. For more information, see [Supported platforms](/mem/configmgr/mdt/release-notes#supported-platforms).
|
||||
|
||||
## Not affected
|
||||
|
||||
WDS PXE boot isn't affected by this change. You can still use WDS to PXE boot devices with custom boot images, but you can't use **boot.wim** as the boot image and run Windows Setup in WDS mode.
|
||||
|
||||
@ -35,17 +35,22 @@ You can use the Windows Defender Application Control (WDAC) Wizard and the Power
|
||||
|
||||
1. Create a new base policy using the templates:
|
||||
|
||||
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The example below shows beginning with the [Default Windows Mode](../wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
|
||||
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The following example shows beginning with the [Default Windows Mode](../wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
|
||||
|
||||
|
||||
|
||||
> [!NOTE]
|
||||
> If your AppId Tagging Policy does build off the base templates or does not allow Windows in-box processes, you will notice significant performance regressions, especially during boot. For this reason, it is strongly recommended to build off the base templates.
|
||||
For more information on the issue, see the [AppId Tagging Known Issue](../operations/known-issues.md#slow-boot-and-performance-with-custom-policies).
|
||||
|
||||
|
||||
2. Set the following rule-options using the Wizard toggles:
|
||||
|
||||
|
||||
|
||||
3. Create custom rules:
|
||||
|
||||
Selecting the `+ Custom Rules` button will open the Custom Rules panel. The Wizard supports five types of file rules:
|
||||
Selecting the `+ Custom Rules` button opens the Custom Rules panel. The Wizard supports five types of file rules:
|
||||
|
||||
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
|
||||
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
|
||||
@ -58,16 +63,16 @@ You can use the Windows Defender Application Control (WDAC) Wizard and the Power
|
||||
|
||||
4. Convert to AppId Tagging Policy:
|
||||
|
||||
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the usermode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
|
||||
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the user mode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
|
||||
|
||||
```powershell
|
||||
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
|
||||
```
|
||||
The policyID GUID will be returned by PowerShell if successful.
|
||||
The policyID GUID is returned by the PowerShell command if successful.
|
||||
|
||||
## Create the policy using PowerShell
|
||||
|
||||
Using this method, you'll create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). In an elevate PowerShell instance:
|
||||
Using this method, you create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). In an elevate PowerShell instance:
|
||||
|
||||
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [WDAC File Rule Levels](../select-types-of-rules-to-create.md#table-2-windows-defender-application-control-policy---file-rule-levels) can be used in AppId rules:
|
||||
|
||||
@ -87,14 +92,14 @@ Using this method, you'll create an AppId Tagging policy directly using the WDAC
|
||||
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
|
||||
```
|
||||
|
||||
If you're using filepath rules, you'll likely want to set option 18. Otherwise, there's no need.
|
||||
If you're using filepath rules, you may want to set option 18. Otherwise, there's no need.
|
||||
|
||||
4. Set the name and ID on the policy, which is helpful for future debugging:
|
||||
|
||||
```powershell
|
||||
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId"" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
|
||||
```
|
||||
The policyID GUID will be returned by PowerShell if successful.
|
||||
The policyID GUID is returned by the PowerShell command if successful.
|
||||
|
||||
## Deploy for Local Testing
|
||||
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
@ -8,7 +8,7 @@ author: jsuther1974
|
||||
ms.reviewer: jgeurten
|
||||
ms.author: vinpa
|
||||
manager: aaroncz
|
||||
ms.date: 11/04/2022
|
||||
ms.date: 06/14/2023
|
||||
ms.topic: reference
|
||||
---
|
||||
|
||||
@ -25,7 +25,7 @@ ms.topic: reference
|
||||
|
||||
Members of the security community<sup>*</sup> continuously collaborate with Microsoft to help protect customers. With the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also potentially use to bypass WDAC.
|
||||
|
||||
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. These applications or files can be used by an attacker to circumvent application allow policies, including WDAC:
|
||||
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following applications. An attacker can use these applications or files to circumvent application allow policies, including WDAC:
|
||||
|
||||
- addinprocess.exe
|
||||
- addinprocess32.exe
|
||||
@ -72,7 +72,7 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
|
||||
|
||||
<sup>1</sup> A vulnerability in bginfo.exe was fixed in version 4.22. If you use BGInfo, for security, make sure to download and run the latest version of [BGInfo](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
|
||||
|
||||
<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that isn't being used in a development context, we recommend that you block msbuild.exe.
|
||||
<sup>2</sup> If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. Otherwise, we recommend that you block msbuild.exe.
|
||||
|
||||
<sup>*</sup> Microsoft recognizes the efforts of people in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
|
||||
|
||||
@ -99,9 +99,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
|
||||
> [!NOTE]
|
||||
> This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
|
||||
|
||||
Certain software applications may allow other code to run by design. Such applications should be blocked by your WDAC policy. In addition, when an application version is upgraded to fix a security vulnerability or potential WDAC bypass, you should add *deny* rules to your application control policies for that application’s previous, less secure versions.
|
||||
Certain software applications may allow other code to run by design. Unless these applications are business critical, you should block them in your WDAC policy. In addition, when an application version is upgraded to fix a security vulnerability or potential WDAC bypass, add *deny* rules to your application control policies for that application’s previous, less secure versions.
|
||||
|
||||
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass WDAC. These modules can't be blocked by name or version, and therefore must be blocked by their corresponding hashes.
|
||||
Microsoft recommends that you install the latest security updates. For example, updates help resolve several issues in PowerShell modules that allowed an attacker to bypass WDAC. These modules can be blocked by their corresponding hashes.
|
||||
|
||||
As of October 2017, system.management.automation.dll is updated to revoke earlier versions by hash values, instead of version rules.
|
||||
|
||||
@ -111,14 +111,14 @@ If you wish to use this blocklist policy on Windows Server 2016, locate the deny
|
||||
- msxml6.dll
|
||||
- jscript9.dll
|
||||
|
||||
The blocklist policy below includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone WDAC policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy below using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the sample policy below.
|
||||
The blocklist policy that follows includes "Allow all" rules for both kernel and user mode that make it safe to deploy as a standalone WDAC policy. On Windows versions 1903 and above, Microsoft recommends converting this policy to multiple policy format using the *Set-CiPolicyIdInfo* cmdlet with the *-ResetPolicyId* switch. Then, you can deploy it as a Base policy side-by-side with any other policies in your environment. To instead add these rules to an existing Base policy, you can merge the policy that follows using the *Merge-CIPolicy* cmdlet. If merging into an existing policy that includes an explicit allowlist, you should first remove the two "Allow all" rules and their corresponding FileRuleRefs from the blocklist policy.
|
||||
|
||||
**WDAC policy XML**:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
|
||||
<VersionEx>10.1.0.0</VersionEx>
|
||||
<VersionEx>10.1.0.2</VersionEx>
|
||||
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
|
||||
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
|
||||
<Rules>
|
||||
@ -159,6 +159,14 @@ The blocklist policy below includes "Allow all" rules for both kernel and user m
|
||||
<Deny ID="ID_DENY_DOTNET" FriendlyName="dotnet.exe" FileName="dotnet.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
<Deny ID="ID_DENY_FSI_ANYCPU" FriendlyName="fsiAnyCpu.exe" FileName="fsiAnyCpu.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_AMD_1" FriendlyName="HVCIScan.exe with missing resources AMD Hash Sha1" Hash="424823CD625834C05D55C7B825B0D8059D589748" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_AMD_2" FriendlyName="HVCIScan.exe with missing resources AMD Hash Sha256" Hash="4968BA3E491CF6471C5D1C6CBECE84294012298D8EB6D32C03E476892F34279C" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_AMD_3" FriendlyName="HVCIScan.exe with missing resources AMD Hash Page Sha1" Hash="FCFA167F5F1FC88E0886132AB0B2E0C32B4B1BF5" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_AMD_4" FriendlyName="HVCIScan.exe with missing resources AMD Hash Page Sha256" Hash="283F6E8998E7A20C68FFD8715E6F130EC7648055285883686336F5711DB1C978" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_ARM_1" FriendlyName="HVCIScan.exe with missing resources ARM Hash Sha1" Hash="A72B1B9554B682F9180E5051C1DA1F2601DCD773" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_ARM_2" FriendlyName="HVCIScan.exe with missing resources ARM Hash Sha256" Hash="AC399FA29FAB56F01F63B499766D489198021C54C000463342E0382AD3AF29BE" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_ARM_3" FriendlyName="HVCIScan.exe with missing resources ARM Hash Page Sha1" Hash="9FD720F1D4913073054D93CF446C9ADC7F0BA445" />
|
||||
<Deny ID="ID_DENY_HVCISCAN_ARM_4" FriendlyName="HVCIScan.exe with missing resources ARM Hash Page Sha256" Hash="8CBB25C135FBB43C67F70E933C482A8F6DA9F37FF4761FA061BBD91B30CEFE17" />
|
||||
<Deny ID="ID_DENY_INFINSTALL" FriendlyName="infdefaultinstall.exe" FileName="infdefaultinstall.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
<Deny ID="ID_DENY_INSTALLUTIL" FriendlyName="Microsoft InstallUtil" FileName="InstallUtil.exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe" MinimumFileVersion="0.0.0.0" MaximumFileVersion="65355.65355.65355.65355" />
|
||||
@ -1500,6 +1508,14 @@ The blocklist policy below includes "Allow all" rules for both kernel and user m
|
||||
<FileRuleRef RuleID="ID_DENY_D_604" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_605" />
|
||||
<FileRuleRef RuleID="ID_DENY_D_606" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_1" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_2" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_3" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_AMD_4" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_ARM_1" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_ARM_2" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_ARM_3" />
|
||||
<FileRuleRef RuleID="ID_DENY_HVCISCAN_ARM_4" />
|
||||
</FileRulesRef>
|
||||
</ProductSigners>
|
||||
</SigningScenario>
|
||||
@ -1507,6 +1523,18 @@ The blocklist policy below includes "Allow all" rules for both kernel and user m
|
||||
<UpdatePolicySigners />
|
||||
<CiSigners />
|
||||
<HvciOptions>0</HvciOptions>
|
||||
<Settings>
|
||||
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
|
||||
<Value>
|
||||
<String>Microsoft Windows Recommended User Mode BlockList</String>
|
||||
</Value>
|
||||
</Setting>
|
||||
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
|
||||
<Value>
|
||||
<String>10.1.0.2</String>
|
||||
</Value>
|
||||
</Setting>
|
||||
</Settings>
|
||||
</SiPolicy>
|
||||
```
|
||||
|
||||
|
||||
@ -95,3 +95,19 @@ As a workaround, download the MSI file and run it locally:
|
||||
```console
|
||||
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
|
||||
```
|
||||
### Slow boot and performance with custom policies
|
||||
|
||||
WDAC will evaluate all running processes, including inbox Windows processes. If policies don't build off the WDAC templates or don't trust the Windows signers, you'll see slower boot times, degraded performance and possibly boot issues. For these reasons, it's strongly recommended to build off the [WDAC base templates](../example-wdac-base-policies.md).
|
||||
|
||||
#### AppId Tagging policy considerations
|
||||
|
||||
If the AppId Tagging Policy wasn't built off the WDAC base templates or doesn't allow the Windows in-box signers, you'll notice a significant increase in boot times (~2 minutes).
|
||||
|
||||
If you can't allowlist the Windows signers, or build off the WDAC base templates, it is strongly recommended to add the following rule to your policies to improve the performance:
|
||||
|
||||
:::image type="content" source="../images/known-issue-appid-dll-rule.png" alt-text="Allow all dlls in the policy.":::
|
||||
|
||||
:::image type="content" source="../images/known-issue-appid-dll-rule-xml.png" alt-text="Allow all dll files in the xml policy.":::
|
||||
|
||||
|
||||
Since AppId Tagging policies evaluate but can't tag dll files, this rule will short circuit dll evaluation and improve evaluation performance.
|
||||
Reference in New Issue
Block a user