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

Merge pull request #8073 from MicrosoftDocs/main

Browse Source 
Publish main to live on 3/23 @ 10:30 am
This commit is contained in:
Stephanie Savell 2023-03-23 12:39:29 -05:00 committed by GitHub
commit 317d4f370c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
12 changed files with 232 additions and 458 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.openpublishing.redirection.json
View File

@ -20730,6 +20730,11 @@
"redirect_url": "/windows/deployment/s-mode",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business.md",
"redirect_url": "https://aka.ms/AzureCodeSigning",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md",
"redirect_url": "/windows/deployment/windows-autopatch/overview/windows-autopatch-privacy",

6
education/windows/get-minecraft-for-education.md
View File

@ -44,9 +44,9 @@ When you sign up for a Minecraft Education trial, or purchase a subscription, Mi
To purchase direct licenses:
1. Go to [https://education.minecraft.net/](https://education.minecraft.net/) and select **How to Buy** in the top navigation bar
1. Scroll down and select **Buy Now** under **Direct Purchase**
1. In the *purchase* page, sign in with an account that has *Billing Admin* privileges in your organization
1. Go to [https://education.minecraft.net/licensing](https://education.minecraft.net/licensing)
1. Under **Direct Purchase**, select **Buy Now**
1. Sign in to the Admin Center purchase page with an account that has *Billing Admin* privileges in your organization
1. If necessary, fill in any requested organization or payment information
1. Select the quantity of licenses you'd like to purchase and select **Place Order**
1. After you've purchased licenses, you'll need to [assign Minecraft Education licenses to your users](#assign-minecraft-education-licenses)

14
windows/deployment/TOC.yml
View File

@ -7,9 +7,9 @@
href: deploy-whats-new.md
- name: Windows client deployment scenarios
href: windows-10-deployment-scenarios.md
- name: What is Windows as a service?
- name: Quick guide to Windows as a service
href: update/waas-quick-start.md
- name: Windows update fundamentals
- name: Windows as a service overview
href: update/waas-overview.md
- name: Monthly quality updates
href: update/quality-updates.md
@ -47,12 +47,12 @@
- name: Define your servicing strategy
href: update/plan-define-strategy.md
- name: Delivery Optimization for Windows client updates
href: do/waas-delivery-optimization.md
href: do/waas-delivery-optimization.md?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json
items:
- name: Using a proxy with Delivery Optimization
href: do/delivery-optimization-proxy.md
href: do/delivery-optimization-proxy.md?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json
- name: Delivery Optimization client-service communication
href: do/delivery-optimization-workflow.md
href: do/delivery-optimization-workflow.md?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json
- name: Windows 10 deployment considerations
href: planning/windows-10-deployment-considerations.md
- name: Windows 10 infrastructure requirements
@ -80,7 +80,7 @@
- name: Update Baseline
href: update/update-baseline.md
- name: Set up Delivery Optimization for Windows client updates
href: do/index.yml
href: do/waas-delivery-optimization-setup.md?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json
- name: Configure BranchCache for Windows client updates
href: update/waas-branchcache.md
- name: Prepare your deployment tools
@ -339,7 +339,7 @@
- name: Additional Windows Update settings
href: update/waas-wu-settings.md
- name: Delivery Optimization reference
href: do/waas-delivery-optimization-reference.md
href: do/waas-delivery-optimization-reference.md?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json
- name: Windows client in S mode
href: s-mode.md
- name: Switch to Windows client Pro or Enterprise from S mode

12
windows/deployment/breadcrumb/toc.yml
View File

@ -46,3 +46,15 @@ items:
- name: Deployment
tocHref: /windows/client-management/mdm
topicHref: /windows/deployment/
- name: Learn
tocHref: /
topicHref: /
items:
- name: Windows
tocHref: /windows/
topicHref: /windows/resources/
items:
- name: Deployment
tocHref: /windows/deployment/do
topicHref: /windows/deployment/

6
windows/deployment/do/TOC.yml
View File

@ -11,14 +11,12 @@
href: waas-delivery-optimization-faq.yml
- name: Configure Delivery Optimization for Windows
items:
- name: Windows Delivery Optimization settings
href: waas-delivery-optimization-setup.md#recommended-delivery-optimization-settings
- name: Set up Delivery Optimization for Windows
href: waas-delivery-optimization-setup.md
- name: Configure Delivery Optimization settings using Microsoft Intune
href: /mem/intune/configuration/delivery-optimization-windows
- name: Resources for Delivery Optimization
items:
- name: Set up Delivery Optimization for Windows
href: waas-delivery-optimization-setup.md
- name: Delivery Optimization reference
href: waas-delivery-optimization-reference.md
- name: Delivery Optimization client-service communication

120
windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
View File

@ -1,109 +1,124 @@
---
title: Allow LOB Win32 Apps on Intune-Managed S Mode Devices (Windows)
description: Using Windows Defender Application Control (WDAC) supplemental policies, you can expand the S mode base policy on your Intune-managed devices.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
title: Allow LOB Win32 apps on Intune-managed S Mode devices
description: Using Windows Defender Application Control (WDAC) supplemental policies, you can expand the S Mode base policy on your Intune-managed devices.
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
author: jsuther1974
ms.reviewer: isbrahm
ms.author: vinpa
manager: aaroncz
ms.date: 10/30/2019
ms.technology: itpro-security
ms.topic: article
ms.topic: how-to
---
# Allow Line-of-Business Win32 Apps on Intune-Managed S Mode Devices
# Allow line-of-business Win32 apps on Intune-managed S Mode devices
**Applies to:**
- Windows 10
- Windows 11
- Windows 10
- Windows 11
> [!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) 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 (WDAC) are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
Beginning with the Windows 10 November 2019 update (build 18363), Microsoft Intune enables customers to deploy and run business critical Win32 applications and Windows components that are normally blocked in S mode (ex. PowerShell.exe) on their Intune-managed Windows in S mode devices.
You can use Microsoft Intune to deploy and run critical Win32 applications and Windows components that are normally blocked in S mode on their Intune-managed Windows in S mode devices. For example, PowerShell.exe.
With Intune, IT Pros can now configure their managed S mode devices using a Windows Defender Application Control (WDAC) supplemental policy that expands the S mode base policy to authorize the apps their business uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
With Intune, you can configure managed S mode devices using a Windows Defender Application Control supplemental policy that expands the S mode base policy to authorize the apps your organization uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
For an overview and brief demo of this feature, see this video:
Refer to the below video for an overview and brief demo.
> [!VIDEO https://www.microsoft.com/videoplayer/embed/RE4mlcp]
## Policy Authorization Process
![Policy Authorization.](images/wdac-intune-policy-authorization.png)
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to WDAC PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, we recommend assigning it to a single test S-mode device to verify expected functioning before deploying the policy more broadly.
## Policy authorization process
1. Generate a supplemental policy with Windows Defender Application Control tooling
![Basic diagram of the policy authorization flow.](images/wdac-intune-policy-authorization.png)
This policy will expand the S mode base policy to authorize more applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, before deploying the policy more broadly, assign it to a single test S-mode device to verify expected functioning.
Refer to [Deploy multiple Windows Defender Application Control Policies](deploy-multiple-windows-defender-application-control-policies.md) for guidance on creating supplemental policies and [Deploy Windows Defender Application Control policy rules and file rules](select-types-of-rules-to-create.md) to choose the right type of rules to create for your policy.
1. Generate a supplemental policy with Windows Defender Application Control tooling.
Below are a basic set of instructions for creating an S mode supplemental policy:
- Create a new base policy using [New-CIPolicy](/powershell/module/configci/new-cipolicy?view=win10-ps&preserve-view=true)
This policy expands the S mode base policy to authorize more applications. Anything authorized by either the S mode base policy or your supplemental policy is allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
For more information on creating supplemental policies, see [Deploy multiple Windows Defender Application Control policies](deploy-multiple-windows-defender-application-control-policies.md). For more information on the right type of rules to create for your policy, see [Deploy Windows Defender Application Control policy rules and file rules](select-types-of-rules-to-create.md).
The following instructions are a basic set for creating an S mode supplemental policy:
- Create a new base policy using [New-CIPolicy](/powershell/module/configci/new-cipolicy?view=win10-ps&preserve-view=true).
```powershell
New-CIPolicy -MultiplePolicyFormat -ScanPath <path> -UserPEs -FilePath "<path>\SupplementalPolicy.xml" -Level FilePublisher -Fallback SignedVersion,Publisher,Hash
```
- Change it to a supplemental policy using [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo?view=win10-ps&preserve-view=true)
- Change it to a supplemental policy using [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo?view=win10-ps&preserve-view=true).
```powershell
Set-CIPolicyIdInfo -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784 -FilePath "<path>\SupplementalPolicy.xml"
```
Policies that are supplementing the S mode base policy must use **-SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784**, as this ID is the S mode policy ID.
- Put the policy in enforce mode using [Set-RuleOption](/powershell/module/configci/set-ruleoption?view=win10-ps&preserve-view=true)
For policies that supplement the S mode base policy, use `-SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784`. This ID is the S mode policy ID.
- Put the policy in enforce mode using [Set-RuleOption](/powershell/module/configci/set-ruleoption?view=win10-ps&preserve-view=true).
```powershell
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 –Delete
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 -Delete
```
This command deletes the 'audit mode' qualifier.
- Since you'll be signing your policy, you must authorize the signing certificate you'll use to sign the policy and optionally one or more extra signers that can be used to sign updates to the policy in the future. For more information, see Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the Windows Defender Application Control policy:
- Since you're signing your policy, you must authorize the signing certificate you use to sign the policy. Optionally, also authorize one or more extra signers that can be used to sign updates to the policy in the future. The next step in the overall process, **Sign the policy**, describes it in more detail.
To add the signing certificate to the Windows Defender Application Control policy, use [Add-SignerRule](/powershell/module/configci/add-signerrule?view=win10-ps&preserve-view=true).
```powershell
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
```
- Convert to .bin using [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy?view=win10-ps&preserve-view=true)
- Convert to `.bin` using [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy?view=win10-ps&preserve-view=true).
```powershell
ConvertFrom-CIPolicy -XmlFilePath "<path>\SupplementalPolicy.xml" -BinaryFilePath "<path>\SupplementalPolicy.bin>
```
2. Sign policy
2. Sign the policy.
Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the Device Guard Signing Service (DGSS) or your organization's custom Public Key Infrastructure (PKI). Refer to [Use the Device Guard Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md) for guidance on using DGSS and [Create a code signing cert for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for guidance on signing using an internal CA.
Supplemental S mode policies must be digitally signed. To sign your policy, use your organization's custom Public Key Infrastructure (PKI). For more information on signing using an internal CA, see [Create a code signing cert for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
Rename your policy to "{PolicyID}.p7b" after you've signed it. PolicyID can be found by inspecting the Supplemental Policy XML.
> [!TIP]
> For more information, see [Azure Code Signing, democratizing trust for developers and consumers](https://techcommunity.microsoft.com/t5/security-compliance-and-identity/azure-code-signing-democratizing-trust-for-developers-and/ba-p/3604669).
3. Deploy the signed supplemental policy using Microsoft Intune
After you've signed it, rename your policy to `{PolicyID}.p7b`. Get the **PolicyID** from the supplemental policy XML.
Go to the Azure portal online and navigate to the Microsoft Intune page, then go to the Client apps blade and select 'S mode supplemental policies'. Upload the signed policy to Intune and assign it to user or device groups. Intune will generate tenant- and device- specific authorization tokens. Intune then deploys the corresponding authorization token and supplemental policy to each device in the assigned group. Together, these tokens and policies expand the S mode base policy on the device.
3. Deploy the signed supplemental policy using Microsoft Intune.
> [!Note]
> When updating your supplemental policy, ensure that the new version number is strictly greater than the previous one. Using the same version number is not allowed by Intune. Refer to [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion?view=win10-ps&preserve-view=true) for information on setting the version number.
Go to the Microsoft Intune portal, go to the Client apps page, and select **S mode supplemental policies**. Upload the signed policy to Intune and assign it to user or device groups. Intune generates authorization tokens for the tenant and specific devices. Intune then deploys the corresponding authorization token and supplemental policy to each device in the assigned group. Together, these tokens and policies expand the S mode base policy on the device.
## Standard Process for Deploying Apps through Intune
![Deploying Apps through Intune.](images/wdac-intune-app-deployment.png)
Refer to [Intune Standalone - Win32 app management](/intune/apps-win32-app-management) for guidance on the existing procedure of packaging signed catalogs and app deployment.
> [!NOTE]
> When you update your supplemental policy, make sure that the new version number is strictly greater than the previous one. Intune doesn't allow using the same version number. For more information on setting the version number, see [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion?view=win10-ps&preserve-view=true).
## Optional: Process for Deploying Apps using Catalogs
![Deploying Apps using Catalogs.](images/wdac-intune-app-catalogs.png)
Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that will authorize all apps signed by that certificate, which may include apps you don't want to allow as well.
## Standard process for deploying apps through Intune
Instead of authorizing signers external to your organization, Intune has added new functionality to make it easier to authorize existing applications (without requiring repackaging or access to the source code) by using signed catalogs. This functionality works for apps that may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
![Basic diagram for deploying apps through Intune.](images/wdac-intune-app-deployment.png)
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using the DGSS or a custom PKI. Use the Add-SignerRule PowerShell cmdlet as shown above to authorize the catalog signing certificate in the supplemental policy. After that, IT Pros can use the standard Intune app deployment process outlined above. For more information on generating catalogs, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
For more information on the existing procedure of packaging signed catalogs and app deployment, see [Win32 app management in Microsoft Intune](/mem/intune/apps/apps-win32-app-management).
> [!Note]
> Every time an app updates, you will need to deploy an updated catalog. Because of this, IT Pros should try to avoid using catalog files for applications that auto-update and direct users not to update applications on their own.
## Optional: Process for deploying apps using catalogs
![Basic diagram for deploying Apps using catalogs.](images/wdac-intune-app-catalogs.png)
Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that authorizes all apps signed by that certificate, which may include apps you don't want to allow as well.
Instead of authorizing signers external to your organization, Intune has functionality to make it easier to authorize existing applications by using signed catalogs. This feature doesn't require repackaging or access to the source code. It works for apps that may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using a custom PKI. To authorize the catalog signing certificate in the supplemental policy, use the **Add-SignerRule** PowerShell cmdlet as shown above in step 1 of the [Policy authorization process](#policy-authorization-process). After that, use the [Standard process for deploying apps through Intune](#standard-process-for-deploying-apps-through-intune) outlined above. For more information on generating catalogs, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
> [!NOTE]
> Every time an app updates, you need to deploy an updated catalog. Try to avoid using catalog files for applications that auto-update, and direct users not to update applications on their own.
## Sample policy
Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Registry Editor. It also demonstrates how to specify your organization's code signing and policy signing certificates.
The following policy is a sample that allows kernel debuggers, PowerShell ISE, and Registry Editor. It also demonstrates how to specify your organization's code signing and policy signing certificates.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
@ -185,10 +200,12 @@ Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Regis
</Settings>
</SiPolicy>
```
## Policy removal
In order to revert users to an unmodified S mode policy, an IT Pro can remove a user or users from the targeted Intune group that received the policy, which will trigger a removal of both the policy and the authorization token from the device.
IT Pros also have the choice of deleting a supplemental policy through Intune.
## Policy removal
In order to revert users to an unmodified S mode policy, remove a user or users from the targeted Intune group that received the policy. This action triggers a removal of both the policy and the authorization token from the device.
You can also delete a supplemental policy through Intune.
```xml
<?xml version="1.0" encoding="utf-8"?>
@ -242,4 +259,5 @@ IT Pros also have the choice of deleting a supplemental policy through Intune.
```
## Errata
If an S-mode device with a policy authorization token and supplemental policy is rolled back from the 1909 update to the 1903 build, it will not revert to locked-down S mode until the next policy refresh. To achieve an immediate change to a locked-down S mode state, IT Pros should delete any tokens in %SystemRoot%\System32\CI\Tokens\Active.

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

@ -96,8 +96,6 @@
href: deploy-catalog-files-to-support-windows-defender-application-control.md
- name: Use signed policies to protect Windows Defender Application Control against tampering
href: use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
- name: "Optional: Use the Device Guard Signing Service v2"
href: use-device-guard-signing-portal-in-microsoft-store-for-business.md
- name: "Optional: Create a code signing cert for WDAC"
href: create-code-signing-cert-for-windows-defender-application-control.md
- name: Disable WDAC policies

182
windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md
View File

@ -1,15 +1,9 @@
---
title: Deploy catalog files to support Windows Defender Application Control (Windows)
title: Deploy catalog files to support Windows Defender Application Control
description: Catalog files simplify running unsigned applications in the presence of a Windows Defender Application Control (WDAC) policy.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
ms.topic: how-to
author: jsuther1974
ms.reviewer: jgeurten
ms.author: vinpa
@ -22,27 +16,27 @@ ms.technology: itpro-security
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
- Windows 10
- Windows 11
- Windows Server 2016 and later
> [!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. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
*Catalog files* can be important in your deployment of Windows Defender Application Control (WDAC) if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. You can also use catalog files to add your own signature to apps you get from independent software vendors (ISV) when you don't want to trust all code signed by that ISV. In this way, catalog files provide a convenient way for you to "bless" apps for use in your WDAC-managed environment. And, you can create catalog files for existing apps without requiring access to the original source code or needing any expensive repackaging.
You'll need to [obtain a code signing certificate for your own use](/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications#obtain-code-signing-certificates-for-your-own-use) and use it to sign the catalog file. Then, distribute the signed catalog file using your preferred content deployment mechanism.
You need to [obtain a code signing certificate for your own use](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md#obtain-code-signing-certificates-for-your-own-use) and use it to sign the catalog file. Then, distribute the signed catalog file using your preferred content deployment mechanism.
Finally, add a signer rule to your WDAC policy for your signing certificate. Then, any apps covered by your signed catalog files will be able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a WDAC policy that blocks all unsigned code (most malware is unsigned).
Finally, add a signer rule to your WDAC policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a WDAC policy that blocks all unsigned code, because most malware is unsigned.
## Create catalog files using Package Inspector
To create a catalog file for an existing app, you can use a tool called **Package Inspector** that comes with Windows.
1. Apply a WDAC policy in **audit mode** to the computer where you'll run Package Inspector. Package Inspector will use audit events to include hashes in the catalog file for any temporary installation files that are added and then removed from the computer during the installation process. The audit mode policy should **not** allow the app's binaries or you may miss some critical files that are needed in the catalog file.
1. Apply a policy in **audit mode** to the computer where you run Package Inspector. Package Inspector uses audit events to include hashes in the catalog file for any temporary installation files that are added and then removed from the computer during the installation process. The audit mode policy should **not** allow the app's binaries or you may miss some critical files that are needed in the catalog file.
> [!NOTE]
> You won't be able to complete this process if it's done on a system with an enforced WDAC policy, unless the enforced policy already allows the app to run.
> You won't be able to complete this process if it's done on a system with an enforced policy, unless the enforced policy already allows the app to run.
You can use this PowerShell sample to make a copy of the DefaultWindows_Audit.xml template:
@ -52,9 +46,9 @@ To create a catalog file for an existing app, you can use a tool called **Packag
$PolicyBinary = $env:USERPROFILE+"\Desktop\"+$PolicyId.substring(11)+".cip"
```
Then apply the policy as described in [Deploy WDAC policies with script](/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-script).
Then apply the policy as described in [Deploy Windows Defender Application Control policies with script](deployment/deploy-wdac-policies-with-script.md).
2. Start Package Inspector to monitor file creation on a **local drive** where you'll install the app, for example, drive C:
2. Start Package Inspector to monitor file creation on a **local drive** where you install the app, for example, drive C:
```powershell
PackageInspector.exe Start C:
@ -73,11 +67,11 @@ To create a catalog file for an existing app, you can use a tool called **Packag
7. Close and reopen the application to ensure that the scan has captured all binaries.
8. As appropriate, with Package Inspector still running, repeat the steps above for any other apps that you want to include in the catalog.
8. As appropriate, with Package Inspector still running, repeat the previous steps for any other apps that you want to include in the catalog.
9. When you've confirmed that the previous steps are complete, use the following commands to stop Package Inspector. A catalog file and catalog definition file will be created in the specified location. Use a naming convention for your catalog files to make it easier to manage your deployed catalog files over time. The filenames used in this example are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file).
9. When you've confirmed that the previous steps are complete, use the following commands to stop Package Inspector. It creates a catalog file and catalog definition file in the specified location. Use a naming convention for your catalog files to make it easier to manage your deployed catalog files over time. The filenames used in this example are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file).
For the last command, which stops Package Inspector, be sure to specify the same local drive you've been watching with Package Inspector, for example, C:.
For the last command, which stops Package Inspector, be sure to specify the same local drive you've been watching with Package Inspector, for example, `C:`.
```powershell
$ExamplePath=$env:userprofile+"\Desktop"
@ -89,33 +83,25 @@ To create a catalog file for an existing app, you can use a tool called **Packag
> [!NOTE]
> Package Inspector catalogs the hash values for each discovered file. If the applications that were scanned are updated, complete this process again to trust the new binaries' hash values.
When finished, the files will be saved to your desktop. You can view the \*.cdf file with a text editor and see what files were included by Package Inspector. You can also double-click the \*.cat file to see its contents and check for a specific file hash.
When finished, the tool saves the files to your desktop. You can view the `*.cdf` file with a text editor and see what files Package Inspector included. You can also double-click the `*.cat` file to see its contents and check for a specific file hash.
## Sign your Catalog file
## Sign your catalog file
Now that you've created a catalog file for your app, you're ready to sign it.
### Catalog signing with Device Guard Signing Service v2 (DGSS)
If you have an existing Microsoft Store for Business and Education account, you can use the DGSS to sign your catalog files. See [Submit-SigningJob](/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business#submit-signingjob).
### Catalog signing with SignTool.exe
If you purchased a code signing certificate or issued one from your own public key infrastructure (PKI), you can use SignTool.exe to sign your catalog files.
<br>
<details>
<summary>Expand this section for detailed instructions on signing catalog files with signtool.exe.</summary>
You need:
- SignTool.exe, found in the [Windows software development kit (SDK)](https://developer.microsoft.com/windows/downloads/windows-sdk/)
- The catalog file that you created earlier
- A code signing certificate issued from an internal certificate authority (CA) or a purchased code signing certificate
- SignTool.exe, found in the [Windows software development kit (SDK)](https://developer.microsoft.com/windows/downloads/windows-sdk/).
- The catalog file that you created earlier.
- A code signing certificate issued from an internal certificate authority (CA) or a purchased code signing certificate.
Import the code signing certificate that will be used to sign the catalog file into the signing user's personal store. Then, sign the existing catalog file by copying each of the following commands into an elevated Windows PowerShell session.
For the code signing certificate that you use to sign the catalog file, import it into the signing user's personal store. Then, sign the existing catalog file by copying each of the following commands into an elevated Windows PowerShell session.
1. Initialize the variables that will be used. Replace the *$ExamplePath* and *$CatFileName* variables as needed:
1. Initialize the variables to use. Replace the `$ExamplePath` and `$CatFileName` variables as needed:
```powershell
$ExamplePath=$env:userprofile+"\Desktop"
@ -129,37 +115,29 @@ Import the code signing certificate that will be used to sign the catalog file i
```
> [!NOTE]
>The *&lt;Path to signtool.exe&gt;* variable should be the full path to the Signtool.exe utility. *ContosoSigningCert* represents the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the computer on which you are attempting to sign the catalog file.
> The `<Path to signtool.exe>` variable should be the full path to the Signtool.exe utility. `ContosoSigningCert` represents the subject name of the certificate that you use to sign the catalog file. This certificate should be imported to your personal certificate store on the computer on which you are attempting to sign the catalog file.
>
>For additional information about Signtool.exe and all additional switches, visit the [Sign Tool page](/dotnet/framework/tools/signtool-exe).
> For more information about Signtool.exe and all additional switches, see [Sign Tool](/dotnet/framework/tools/signtool-exe).
3. Verify the catalog file's digital signature. Right-click the catalog file, and then select **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 1.
![Digital Signature list in file Properties.](images/dg-fig12-verifysigning.png)
Figure 1. Verify that the signing certificate exists
</details>
Figure 1. Verify that the signing certificate exists.
## Deploy the catalog file to your managed endpoints
Catalog files in Windows are stored under ***%windir%\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}***.
Catalog files in Windows are stored under `%windir%\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}`.
For testing purposes, you can manually copy signed catalog files to the folder above. For large-scale deployment of signed catalog files, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as Microsoft Configuration Manager.
For testing purposes, you can manually copy signed catalog files to this folder. For large-scale deployment of signed catalog files, use group policy file preferences or an enterprise systems management product such as Microsoft Configuration Manager.
### Deploy catalog files with Group Policy
### Deploy catalog files with group policy
To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate computers in your organization.
To simplify the management of catalog files, you can use group policy preferences to deploy catalog files to the appropriate computers in your organization.
<br>
<details>
<summary>Expand this section for detailed instructions on deploying catalog files using Group Policy.</summary>
The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called **WDAC Enabled PCs** with a GPO called **Contoso Catalog File GPO Test**.
The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called WDAC Enabled PCs with a GPO called **Contoso Catalog File GPO Test**.
**To deploy a catalog file with Group Policy:**
1. From either a domain controller or a client computer that has Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC) by running **GPMC.MSC** or by searching for Group Policy Management.
1. From either a domain controller or a client computer that has Remote Server Administration Tools installed, open the Group Policy Management Console by running **GPMC.MSC** or by searching for Group Policy Management.
2. Create a new GPO: right-click an OU, for example, the **WDAC Enabled PCs OU**, and then select **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
@ -168,33 +146,33 @@ The following process walks you through the deployment of a signed catalog file
![Group Policy Management, create a GPO.](images/dg-fig13-createnewgpo.png)
Figure 2. Create a new GPO
Figure 2. Create a new GPO.
3. Give the new GPO a name, for example, **Contoso Catalog File GPO Test**, or any name you prefer.
4. Open the Group Policy Management Editor: right-click the new GPO, and then select **Edit**.
5. Within the selected GPO, navigate to Computer Configuration\\Preferences\\Windows Settings\\Files. Right-click **Files**, point to **New**, and then select **File**, as shown in Figure 3.
5. Within the selected GPO, navigate to **Computer Configuration\\Preferences\\Windows Settings\\Files**. Right-click **Files**, point to **New**, and then select **File**, as shown in Figure 3.
![Group Policy Management Editor, New File.](images/dg-fig14-createnewfile.png)
Figure 3. Create a new file
Figure 3. Create a new file.
6. Configure the catalog file share.
To use this setting to provide consistent deployment of your catalog file (in this example, LOBApp-Contoso.cat), the source file should be on a share that is accessible to the computer account of every deployed computer. This example uses a share (on a computer running Windows 10) called \\\\Contoso-Win10\\Share. The catalog file being deployed is copied to this share.
To use this setting to provide consistent deployment of your catalog file (in this example, LOBApp-Contoso.cat), the source file should be on a share that is accessible to the computer account of every deployed computer. This example uses a share on a computer running Windows 10 called `\\Contoso-Win10\Share`. The catalog file being deployed is copied to this share.
7. To keep versions consistent, in the **New File Properties** dialog box (Figure 4), select **Replace** from the **Action** list so that the newest version is always used.
7. To keep versions consistent, in the **New File Properties** dialog box as shown in Figure 4, select **Replace** from the **Action** list so that the newest version is always used.
![File Properties, Replace option.](images/dg-fig15-setnewfileprops.png)
Figure 4. Set the new file properties
Figure 4. Set the new file properties.
8. In the **Source file(s)** box, type the name of your accessible share, with the catalog file name included (for example, \\\\Contoso-Win10\\share\\LOBApp-Contoso.cat).
8. In the **Source file(s)** box, type the name of your accessible share, with the catalog file name included. For example, `\\Contoso-Win10\share\LOBApp-Contoso.cat`.
9. In the **Destination File** box, type a path and file name, for example:
**C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**
`C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat`
For the catalog file name, use the name of the catalog you're deploying.
@ -202,22 +180,16 @@ The following process walks you through the deployment of a signed catalog file
11. Select **OK** to complete file creation.
12. Close the Group Policy Management Editor, and then update the policy on the test computer running Windows 10 or Windows 11, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists in C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the computer running Windows 10.
</details>
12. Close the Group Policy Management Editor, and then update the policy on the test computer running Windows 10 or Windows 11, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists in `C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}` on the computer running Windows 10.
### Deploy catalog files with Microsoft Configuration Manager
As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files and provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes.
<br>
<details>
<summary>Expand this section for detailed instructions on deploying catalog files using Configuration Manager.</summary>
As an alternative to group policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files and provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes.
Complete the following steps to create a new deployment package for catalog files:
> [!NOTE]
>The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection-specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
> The following example uses a network share named `\\Shares\CatalogShare` as a source for the catalog files. If you have collection-specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
1. Open the Configuration Manager console, and select the Software Library workspace.
@ -227,24 +199,28 @@ Complete the following steps to create a new deployment package for catalog file
![Create Package and Program Wizard.](images/dg-fig16-specifyinfo.png)
Figure 5. Specify information about the new package
Figure 5. Specify information about the new package.
4. Select **Next**, and then select **Standard program** as the program type.
5. On the **Standard Program** page, select a name, and then set the **Command Line** property to **XCopy \\\\Shares\\CatalogShare C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y**.
5. On the **Standard Program** page, select a name, and then set the **Command Line** property to the following command:
6. On the **Standard Program** page, select the following options (Figure 6):
```cmd
XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y
```
6. On the **Standard Program** page, select the following options, as shown in Figure 6:
- In **Name**, type a name such as **Contoso Catalog File Copy Program**.
- In **Command line**, browse to the program location.
- In **Startup folder**, type **C:\\Windows\\System32**.
- In **Startup folder**, type `C:\Windows\System32`.
- From the **Run** list, select **Hidden**.
- From the **Program can run** list, select **Whether or not a user is logged on**.
- From the **Drive mode** list, select **Runs with UNC name**.
![Standard Program page of wizard.](images/dg-fig17-specifyinfo.png)
Figure 6. Specify information about the standard program
Figure 6. Specify information about the standard program.
7. Accept the defaults for the rest of the wizard, and then close the wizard.
@ -252,9 +228,9 @@ After you create the deployment package, deploy it to a collection so that the c
1. In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then select **Deploy**.
2. On the **General** page, select the test collection to which the catalog files will be deployed, and then select **Next**.
2. On the **General** page, select the test collection, and then select **Next**.
3. On the **Content** page, select **Add** to select the distribution point that will serve content to the selected collection, and then select **Next**.
3. On the **Content** page, select **Add** to select the distribution point to serve content to the selected collection, and then select **Next**.
4. On the **Deployment Settings** page, select **Required** in the **Purpose** box.
@ -264,7 +240,7 @@ After you create the deployment package, deploy it to a collection so that the c
7. On the **Scheduling** page, select **Next**.
8. On the **User Experience** page (Figure 7), set the following options, and then select **Next**:
8. On the **User Experience** page as shown in Figure 7, set the following options, and then select **Next**:
- Select the **Software installation** check box.
@ -272,7 +248,7 @@ After you create the deployment package, deploy it to a collection so that the c
![Deploy Software Wizard, User Experience page.](images/dg-fig18-specifyux.png)
Figure 7. Specify the user experience
Figure 7. Specify the user experience.
9. On the **Distribution Points** page, in the **Deployment options** box, select **Run program from distribution point**, and then select **Next**.
@ -280,15 +256,9 @@ After you create the deployment package, deploy it to a collection so that the c
11. Close the wizard.
</details>
#### Inventory catalog files with Microsoft Configuration Manager
When catalog files have been deployed to the computers within your environment, whether by using Group Policy or Configuration Manager, you can inventory them with the software inventory feature of Configuration Manager.
<br>
<details>
<summary>Expand this section for detailed instructions on inventorying catalog files using Configuration Manager.</summary>
When catalog files have been deployed to the computers within your environment, whether by using group policy or Configuration Manager, you can inventory them with the software inventory feature of Configuration Manager.
You can configure software inventory to find catalog files on your managed systems by creating and deploying a new client settings policy.
@ -303,26 +273,26 @@ You can configure software inventory to find catalog files on your managed syste
![Create Custom Client Device Settings.](images/dg-fig19-customsettings.png)
Figure 8. Select custom settings
Figure 8. Select custom settings.
4. In the navigation pane, select **Software Inventory**, and then select **Set Types**, as shown in Figure 9.
![Software Inventory settings for devices.](images/dg-fig20-setsoftwareinv.png)
Figure 9. Set the software inventory
Figure 9. Set the software inventory.
5. In the **Configure Client Setting** dialog box, select the **Start** button to open the **Inventories File Properties** dialog box.
6. In the **Name** box, type a name such as **\*Contoso.cat**, and then select **Set**.
6. In the **Name** box, type a name such as `*Contoso.cat`, and then select **Set**.
> [!NOTE]
> When typing the name, follow your naming convention for catalog files.
7. In the **Path Properties** dialog box, select **Variable or path name**, and then type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}** in the box, as shown in Figure 10.
7. In the **Path Properties** dialog box, select **Variable or path name**, and then type `C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}` in the box, as shown in Figure 10.
![Path Properties, specifying a path.](images/dg-fig21-pathproperties.png)
Figure 10. Set the path properties
Figure 10. Set the path properties.
8. Select **OK**.
@ -341,42 +311,34 @@ At the time of the next software inventory cycle, when the targeted clients rece
> [!NOTE]
> If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
</details>
## Allow apps signed by your catalog signing certificate in your WDAC policy
Now that you have your signed catalog file, you can add a signer rule to your WDAC policy that will allow anything signed with that certificate. If you haven't yet created a WDAC policy, see [WDAC Design Guide](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-design-guide).
Now that you have your signed catalog file, you can add a signer rule to your policy that allows anything signed with that certificate. If you haven't yet created a WDAC policy, see the [Windows Defender Application Control design guide](windows-defender-application-control-design-guide.md).
<br>
<details>
<summary>Expand this section for detailed instructions on creating a signer rule for your catalog signer.</summary>
On a computer where the signed catalog file has been deployed, you can use [New-CiPolicyRule](/powershell/module/configci/new-cipolicyrule) to create a signer rule from any file included in that catalog. Then use [Merge-CiPolicy](/powershell/module/configci/merge-cipolicy) to add the rule to your policy XML. Be sure to replace the path values in the sample below.
On a computer where the signed catalog file has been deployed, you can use [New-CiPolicyRule](/powershell/module/configci/new-cipolicyrule) to create a signer rule from any file included in that catalog. Then use [Merge-CiPolicy](/powershell/module/configci/merge-cipolicy) to add the rule to your policy XML. Be sure to replace the path values in the following sample:
```powershell
$Rules = New-CIPolicyRule -DriverFilePath <path to the file covered by the signed catalog> -Level Publisher
Merge-CIPolicy -OutputFilePath <path to your WDAC policy XML> -PolicyPaths <path to your WDAC policy XML> -Rules $Rules
Merge-CIPolicy -OutputFilePath <path to your policy XML> -PolicyPaths <path to your policy XML> -Rules $Rules
```
Alternatively, you can use [Add-SignerRule](/powershell/module/configci/add-signerrule) to add a signer rule to your WDAC policy from the certificate file (.cer). You can easily save the .cer file from your signed catalog file.
Alternatively, you can use [Add-SignerRule](/powershell/module/configci/add-signerrule) to add a signer rule to your policy from the certificate file (.cer). You can easily save the .cer file from your signed catalog file.
1. Right-click the catalog file, and then select **Properties**.
2. On the **Digital Signatures** tab, select the signature from the list and then select **Details**.
3. Select **View Certificate** to view the properties of the leaf certificate.
4. Select the **Details** tab and select **Copy to File** which will run the Certificate Export Wizard.
4. Select the **Details** tab and select **Copy to File**. This action runs the Certificate Export Wizard.
5. Complete the wizard using the default option for **Export File Format** and specifying a location and file name to save the .cer file.
> [!NOTE]
> The steps listed above will select the lowest level of the certificate chain (the "leaf" certificate). Instead, you can choose to use the certificate's intermediate or root issuer certificate. To use a different certificate in the chain, switch to the **Certification Path** tab after step 3 above, then select the certificate level you want to use and select **View Certificate**. Then complete the remaining steps.
> These steps select the lowest level of the certificate chain, also called the "leaf" certificate. Instead, you can choose to use the certificate's intermediate or root issuer certificate. To use a different certificate in the chain, switch to the **Certification Path** tab after step 3 above, then select the certificate level you want to use and select **View Certificate**. Then complete the remaining steps.
The following example uses the .cer file to add a signer rule to both the user and kernel mode signing scenarios. Be sure to replace the path values in the sample below.
The following example uses the .cer file to add a signer rule to both the user and kernel mode signing scenarios. Be sure to replace the path values in the following sample:
```powershell
Add-SignerRule -FilePath <path to your WDAC policy XML> -CertificatePath <path to your certificate .cer file> -User -Kernel
Add-SignerRule -FilePath <path to your policy XML> -CertificatePath <path to your certificate .cer file> -User -Kernel
```
</details>
## Known issues using Package Inspector
Some of the known issues using Package Inspector to build a catalog file are:
@ -386,14 +348,14 @@ Some of the known issues using Package Inspector to build a catalog file are:
- Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this USN was the most recent one when you ran PackageInspector start). Then use fsutil.exe to read that starting location. Replace "RegKeyValue" in the following command with the value from the reg key:<br>
`fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt`
- The above command should return an error if the older USNs don't exist anymore due to overflow
- You can expand the USN Journal size using: `fsutil usn createjournal` with a new size and allocation delta. `Fsutil usn queryjournal` will show the current size and allocation delta, so using a multiple of that may help
- You can expand the USN Journal size using: `fsutil usn createjournal` with a new size and allocation delta. `Fsutil usn queryjournal` shows the current size and allocation delta, so using a multiple of that may help
- **CodeIntegrity - Operational event log is too small to track all files created by the installer**
- To diagnose whether Eventlog size is the issue, after running through Package Inspector:
- Open Event Viewer and expand the **Application and Services//Microsoft//Windows//CodeIntegrity//Operational**. Check for a 3076 audit block event for the initial installer launch.
- To increase the Event log size, in Event Viewer right-click the operational log, select Properties, and then set new values
- **Installer or app files that change hash each time the app is installed or run**
- Some apps generate files at run time whose hash value is different every time. You can diagnose this issue by reviewing the hash values in the 3076 audit block events (or 3077 enforcement events) that are generated. If each time you attempt to run the file you observe a new block event with a different hash, the package won't work with Package Inspector.
- Some apps generate files at run time whose hash value is different every time. You can diagnose this issue by reviewing the hash values in the 3076 audit block events (or 3077 enforcement events) that are generated. If each time you attempt to run the file you observe a new block event with a different hash, the package doesn't work with Package Inspector.
- **Files with an invalid signature blob or otherwise "unhashable" files**
- This issue arises when a signed file was modified in a way that invalidates the file's PE header. A file modified in this way is unable to be hashed according to the Authenticode spec.
- Although these "unhashable" files can't be included in the catalog file created by PackageInspector, you should be able to allow them by adding a hash ALLOW rule to your WDAC policy that uses the file's flat file hash.
- Although these "unhashable" files can't be included in the catalog file created by PackageInspector, you should be able to allow them by adding a hash ALLOW rule to your policy that uses the file's flat file hash.
- This issue affects some versions of InstallShield packages that use signed DLL files in custom actions. InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state.

27
windows/security/threat-protection/windows-defender-application-control/example-wdac-base-policies.md
View File

@ -1,15 +1,9 @@
---
title: Example Windows Defender Application Control (WDAC) base policies (Windows)
description: When creating a WDAC policy for an organization, start from one of the many available example base policies.
keywords: security, malware
ms.topic: article
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
title: Example Windows Defender Application Control base policies
description: When creating a Windows Defender Application Control (WDAC) policy for an organization, start from one of the many available example base policies.
ms.topic: reference
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
author: jsuther1974
ms.reviewer: jogeurte
ms.author: vinpa
@ -18,7 +12,7 @@ ms.date: 03/16/2023
ms.technology: itpro-security
---
# Windows Defender Application Control (WDAC) example base policies
# Windows Defender Application Control example base policies
**Applies to:**
@ -27,11 +21,9 @@ ms.technology: itpro-security
- Windows Server 2016 and above
> [!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) 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. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that can be used, or organizations that use the Device Guard Signing Service can download a starter policy from that service.
## Example Base Policies
When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that you can use.
| **Example Base Policy** | **Description** | **Where it can be found** |
|-------------------------|---------------------------------------------------------------|--------|
@ -40,13 +32,12 @@ When you create policies for use with Windows Defender Application Control (WDAC
| **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml |
| **DenyAllAudit.xml** | ***Warning: May cause long boot time on Windows Server 2019.*** Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml |
| **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [Device Guard Signing Service NuGet Package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client) |
| **MEM Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise WDAC policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example WDAC base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy)). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\SignedReputable.xml |
| **Microsoft Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise WDAC policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\SignedReputable.xml |
| **Example supplemental policy** | This example policy shows how to use supplemental policy to expand the DefaultWindows_Audit.xml allow a single Microsoft-signed file. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Supplemental.xml |
| **Microsoft Recommended Block List** | This policy includes a list of Windows and Microsoft-signed code that Microsoft recommends blocking when using WDAC, if possible. | [Microsoft recommended block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_UserMode_Blocklist.xml |
| **Microsoft recommended driver blocklist** | This policy includes rules to block known vulnerable or malicious kernel drivers. | [Microsoft recommended driver block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules) <br> %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_Driver_Blocklist.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/en-us/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows 11 SE** | This policy includes the rules used to enforce [Windows 11 SE](/education/windows/windows-11-se-overview), a version of Windows built for use in schools. | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSEPolicy.xml.xml |
> [!NOTE]

19
windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md
View File

@ -1,14 +1,8 @@
---
title: Use code signing for added control and protection with WDAC
description: Code signing can be used to better control win32 app authorization and add protection for your WDAC policies.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
description: Code signing can be used to better control Win32 app authorization and add protection for your Windows Defender Application Control (WDAC) policies.
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
author: jsuther1974
ms.reviewer: jogeurte
@ -18,7 +12,7 @@ ms.date: 11/29/2022
ms.technology: itpro-security
---
# Use code signing for added control and protection with WDAC
# Use code signing for added control and protection with Windows Defender Application Control
**Applies to:**
@ -27,11 +21,11 @@ ms.technology: itpro-security
- Windows Server 2016 and above
> [!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. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
## What is code signing and why is it important?
Code signing provides some important benefits to application security features like Windows Defender Application Control (WDAC). First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your WDAC policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Code signing provides some important benefits to application security features like Windows Defender Application Control (WDAC). First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Wherever possible, you should require all app binaries and scripts are code signed as part of your app acceptance criteria. And, you should ensure that internal line-of-business (LOB) app developers have access to code signing certificates controlled by your organization.
@ -48,9 +42,9 @@ To learn how to create and manage catalog files for existing apps, see [Deploy c
## Signed WDAC policies
While a WDAC policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your WDAC policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by WDAC and help protect against tampering or removal of a WDAC policy even by an admin user.
While a WDAC policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by WDAC and help protect against tampering or removal of a policy even by an admin user.
For more information on using signed WDAC policies, see [Use signed policies to protect WDAC against tampering](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering)
For more information on using signed policies, see [Use signed policies to protect Windows Defender Application Control against tampering](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering)
## Obtain code signing certificates for your own use
@ -58,5 +52,4 @@ Some ways to obtain code signing certificates for your own use, include:
- Purchase a code signing certificate from one of the [Microsoft Trusted Root Program participants](/security/trusted-root/participants-list).
- To use your own digital certificate or public key infrastructure (PKI) to issue code signing certificates, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
- Customers with existing Microsoft Store for Business and Education accounts can continue to use the ["Device Guard signing service v2"](/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business).
- Use Microsoft's [Azure Code Signing (ACS) service](https://aka.ms/AzureCodeSigning).

188
windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business.md
View File

@ -1,188 +0,0 @@
---
title: Use the Device Guard Signing Service v2 (Windows)
description: You can sign catalog files and WDAC policies with the Device Guard signing service.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.author: vinpa
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
author: jsuther1974
ms.reviewer: jogeurte
manager: aaroncz
ms.date: 11/30/2022
ms.technology: itpro-security
---
# Optional: Use the Device Guard Signing Service v2
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
> [!IMPORTANT]
> Microsoft Store for Business and Microsoft Store for Education will be retired in the first quarter of 2023. For more information about this change, see [Evolving the Microsoft Store for Business and Education](https://aka.ms/windows/msfb_evolution).
>
> You can continue to use the current Device Guard Signing Service v2 (DGSS) capabilities until that time. DGSS will be replaced by the [Azure Code Signing service (ACS)](https://aka.ms/AzureCodeSigning) and will support your Windows Defender Application Control (WDAC) policy and catalog file signing needs.
The Device Guard Signing Service v2 (DGSS) is a code signing service that comes with your existing Microsoft Store for Business and Education tenant account. You can use the DGSS to sign catalog files and Windows Defender Application Control (WDAC) policies.
## Set up permissions for DGSS signing in the Microsoft Store for Business and Education
To use DGSS, you need to assign yourself a role with the right permissions. The least privileged role with DGSS signing privilege is the **Device Guard signer** role. **Global Administrator** and **Billing account owner** can also sign with the DGSS.
## Install the DGSS client NuGet package
Download and install the [DGSS client utilities and PowerShell cmdlets NuGet package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/).
1. Download the [latest recommended version of nuget.exe](https://dist.nuget.org/win-x86-commandline/latest/nuget.exe).
2. From an elevated PowerShell or command window, run the following command:
```powershell
nuget.exe install Microsoft.Acs.Dgss.Client
```
3. Import the DGSS PowerShell module from the location where the Microsoft.Acs.Dgss.Client was installed in the previous step.
```powershell
# Update the path to the Microsoft.Acs.Dgss.Client.dll if needed
Import-Module $env:USERPROFILE\Downloads\Microsoft.Acs.Dgss.Client.1.0.11\PowerShell\Microsoft.Acs.Dgss.Client.dll
```
## DGSS PowerShell Commands
> [!NOTE]
> &lt;DGSSCommonParameters&gt; are parameters common across all commands and are documented below the command definitions.
### Get-DefaultPolicy
Gets the default .xml policy file associated with the current tenant.
**Usage:**
```powershell
Get-DefaultPolicy -OutFile filename [-PassThru] [<DGSSCommonParameters>]
```
**Parameters:**
- **OutFile** - string, mandatory - The filename where the default policy file should be persisted to disk. The file name should be an .xml file. If the file already exists, it will be overwritten. NOTE: The destination folder must already exist.
- **PassThru** - switch, optional - If present, returns an XmlDocument object returning the default policy file.
**Command running time:** The average running time is under 20 seconds but may be up to 3 minutes.
### Get-RootCertificate
Gets the root certificate for the current tenant. All Authenticode and policy signing certificates will eventually chain up to this root certificate.
**Usage:**
```powershell
Get-RootCertificate -OutFile filename [-PassThru] [<DGSSCommonParameters>]
```
**Parameters:**
- **OutFile** - string, mandatory - The filename where the root certificate file should be persisted to disk. The file name should be a .cer file. If the file already exists, it will be overwritten. NOTE: The destination folder must already exist.
- **PassThru** - switch, optional - If present, returns an X509Certificate2 object returning the default policy file.
**Command running time:** The average running time is under 20 seconds but may be up to 3 minutes.
### Get-SigningHistory
Gets information for the latest 100 files signed by the current tenant. Results are returned as a collection with elements in reverse chronological order (most recent to least recent).
**Usage:**
```powershell
Get-SigningHistory -OutFile filename [-PassThru] [<DGSSCommonParameters>]
```
**Parameters:**
- **OutFile** - string, mandatory - The filename where the signing history file should be persisted to disk. The file name should be an .xml file. If the file already exists, it will be overwritten. NOTE: The destination folder must already exist.
- **PassThru** - switch, optional - If present, returns XML objects returning the XML file.
**Command running time:** The average running time is under 10 seconds.
### Submit-SigningJob
Submits a file to the service for signing and timestamping. The module supports valid file type for Authenticode signing is Catalog file (.cat). Valid file type for policy signing is binary policy files with the extension (.bin) that have been created via the ConvertFrom-CiPolicy cmdlet. Otherwise, binary policy file may not be deployed properly.
**Usage:**
```powershell
Submit-SigningJob -InFile filename -OutFile filename [-NoTimestamp][- TimeStamperUrl "timestamper url"] [-JobDescription "description"] [<DGSSCommonParameters>]
```
**Parameters:**
- **InFile** - string, mandatory - The file to be signed, which must be a valid catalog file (.cat) or WDAC policy file with binary extension (.bin).
- **OutFile** - string, mandatory - The output file that should be generated by the signing process. If this file already exists, it will be overwritten. NOTE: The destination folder must already exist.
- **NoTimestamp** - switch, optional - If present, the signing operation will skip timestamping the output file, and it will be signed only. If not present (default) and TimeStamperUrl is present, the output file will be both signed and timestamped. If both NoTimestamp and TimeStamperUrl aren't present, the signing operation will skip timestamping the output file, and it will be signed only.
- **TimeStamperUrl** - string, optional - If this value is an invalid URL (and NoTimestamp not present), the module will throw an exception. To understand more about timestamping, see [Timestamping](/windows/msix/package/signing-package-overview#timestamping).
- **JobDescription** - string, optional - A short (< 100 chars), human-readable description of this submission. If the script is being called as part of an automated build process, you may want the process to pass a version number or changeset number for this field. This information will be provided as part of the results of the Get-SigningHistory command.
### Submit-SigningV1MigrationPolicy
Submits a file to the service for signing and timestamping. The only valid file type for policy signing is binary policy files with the extension (.bin) that have been created via the [ConvertFromCiPolicy](/powershell/module/configci/convertfrom-cipolicy) cmdlet. Otherwise, binary policy file may not be deployed properly. Note: Only use for DGSS V1 migration.
**Usage:**
```powershell
Submit-SigningV1MigrationPolicy -InFile filename -OutFile filename [-NoTimestamp][-TimeStamperUrl "timestamper url"] [-JobDescription "description"] [<DGSSCommonParameters>]
```
**Parameters:**
- **InFile** - string, mandatory - The file to be signed, which must be a WDAC policy file with binary extension (.bin).
- **OutFile** - string, mandatory - The output file that should be generated by the signing process. If this file already exists, it will be overwritten. NOTE: The destination folder must already exist.
- **NoTimestamp** - switch, optional - If present, the signing operation will skip timestamping the output file, and it will be signed only. If not present (default) and TimeStamperUrl is present, the output file will be both signed and timestamped. If both NoTimestamp and TimeStamperUrl aren't present, the signing operation will skip timestamping the output file, and it will be signed only.
- **TimeStamperUrl** - string, optional - If this value is an invalid URL (and NoTimestamp not present), the module will throw exception. To understand more about timestamping, see [Timestamping](/windows/msix/package/signing-package-overview#timestamping).
- **JobDescription** - string, optional - A short (< 100 chars), human-readable description of this submission. If the script is being called as part of an automated build process, you may want the process to pass a version number or changeset number for this field. This information will be provided as part of the results of the Get-SigningHistory command.
**Command running time:** The average running time is under 20 seconds but may be up to 3 minutes.
### Common parameters &lt;DGSSCommonParameters&gt;
In addition to cmdlet-specific parameters, each cmdlet understands the following common parameters.
**Usage:**
```powershell
... [-NoPrompt] [-Credential $creds] [-AppId AppId] [-Verbose]
```
**Parameters:**
- **NoPrompt** - switch, optional - If present, indicates that the script is running in a headless environment and that all UI should be suppressed. If UI must be displayed (for example, for authentication) when the switch is set, the operation will instead fail.
- **Credential + AppId** - PSCredential - A sign-in credential (username and password) and AppId.
## File and size limits
When you're uploading files for DGSS signing, there are a few limits for files and file size:
| Description | Limit |
|-------------------------------------------------------|----------|
| Maximum size for a policy or catalog file | 3.5 MB |
| Maximum size for multiple files (uploaded in a group) | 4 MB |
| Maximum number of files per upload | 15 files |
## File types
Catalog and policy files submitted to DGSS for signing must use specific file extensions:
| File | Required file extension |
|---------------|--------------------|
| catalog files | .cat |
| policy files | .bin |
## DGSS signing certificates
All certificates generated by the DGSS are unique per customer and are independent of the Microsoft production code signing certificate authorities. All Certification Authority (CA) keys are stored within the cryptographic boundary of Federal Information Processing Standards (FIPS) publication 140-2 compliant hardware security modules. After initial generation, root certificate keys and top level CA keys are removed from the online signing service, encrypted, and stored offline.

59
windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
View File

@ -1,15 +1,9 @@
---
title: Use signed policies to protect Windows Defender Application Control against tampering (Windows)
description: Signed WDAC policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
title: Use signed policies to protect Windows Defender Application Control against tampering
description: Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
ms.prod: windows-client
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
ms.topic: conceptual
audience: ITPro
author: jsuther1974
ms.reviewer: jogeurte
ms.author: vinpa
@ -27,32 +21,28 @@ ms.technology: itpro-security
- Windows Server 2016 and above
> [!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. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure (blue screen). With this goal in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to provide this protection for signed WDAC policies.
Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen. With this goal in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to provide this protection for signed WDAC policies.
If you don't currently have a code signing certificate you can use to sign your WDAC policies, see [Obtain code signing certificates for your own use](/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications#obtain-code-signing-certificates-for-your-own-use).
If you don't currently have a code signing certificate you can use to sign your policies, see [Obtain code signing certificates for your own use](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md#obtain-code-signing-certificates-for-your-own-use).
> [!WARNING]
> Boot failure (blue screen) may occur if your signing certificate doesn't follow these rules:
> Boot failure, or blue screen, may occur if your signing certificate doesn't follow these rules:
>
> - All policies, including base and supplemental, must be signed according to the [PKCS 7 Standard](https://datatracker.ietf.org/doc/html/rfc5652).
> - Use RSA keys with 2K, 3K, or 4K key size only. ECDSA isn't supported.
> - You can use SHA-256, SHA-384, or SHA-512 as the digest algorithm on Windows 11, as well as Windows 10 and Windows Server 2019 and above after applying the November 2022 cumulative security update. All other devices only support SHA-256.
> - Don't use UTF-8 encoding for certificate fields, like 'subject common name' and 'issuer common name'. These strings must be encoded as PRINTABLE_STRING, IA5STRING or BMPSTRING.
Before you attempt to deploy signed WDAC policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
Before you attempt to deploy a signed policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
> [!NOTE]
> When signing a Base policy that has existing Supplemental policies, you must also switch to signed policy for all of the Supplementals. Authorize the signed supplemental policies by adding a **&lt;SupplementalPolicySigner&gt;** rule to the Base policy.
> When signing a Base policy that has existing Supplemental policies, you must also switch to signed policy for all of the Supplementals. Authorize the signed supplemental policies by adding a `<SupplementalPolicySigner>` rule to the Base policy.
## Prepare your WDAC policy for signing
<br>
<details>
<summary>Expand this section for detailed instructions on preparing your WDAC policy files for signing.</summary>
1. Open an elevated Windows PowerShell session and initialize the variables that will be used:
1. Open an elevated Windows PowerShell session and initialize the variables to use:
```powershell
$PolicyPath=$env:userprofile+"\Desktop\"
@ -61,7 +51,7 @@ Before you attempt to deploy signed WDAC policy, you should first deploy an unsi
```
> [!NOTE]
> This example uses an enforced version of the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) article. If you are signing another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
> This example uses an enforced version of the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
2. Navigate to your desktop as the working directory:
@ -69,18 +59,19 @@ Before you attempt to deploy signed WDAC policy, you should first deploy an unsi
cd $PolicyPath
```
3. If your WDAC policy doesn't already include an **&lt;UpdatePolicySigner&gt;** rule for your policy signing certificate, you must add it. At least one **&lt;UpdatePolicySigner&gt;** rule must exist to convert your WDAC policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy). If you're using the Device Guard Signing Service v2 (DGSS) to sign your policy, you can find the policy signer rule in your tenant's default policy, which you can download from [Get-DefaultPolicy](/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business#get-defaultpolicy).
3. If your WDAC policy doesn't already include an `<UpdatePolicySigner>` rule for your policy signing certificate, you must add it. At least one `<UpdatePolicySigner>` rule must exist to convert your policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy).
Otherwise, use [Add-SignerRule](/powershell/module/configci/add-signerrule) and create an **&lt;UpdatePolicySigner&gt;** rule from your certificate file (.cer). DGSS users can download the root certificate file from [Get-RootCertificate](/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business#get-rootcertificate). If you purchased a code signing certificate or issued one from your own public key infrastructure (PKI), you can export the certificate file.
Use [Add-SignerRule](/powershell/module/configci/add-signerrule) and create an `<UpdatePolicySigner>` rule from your certificate file (.cer). If you purchased a code signing certificate or issued one from your own public key infrastructure (PKI), you can export the certificate file.
NOTE: If your policy doesn't allow Supplemental policies, you should omit the **-Supplemental** switch from the following command:
> [!NOTE]
> If your policy doesn't allow Supplemental policies, you should omit the **-Supplemental** switch from the following command:
```powershell
Add-SignerRule -FilePath $LamnaServerPolicy -CertificatePath <Path to exported .cer certificate> –Update -Supplemental
Add-SignerRule -FilePath $LamnaServerPolicy -CertificatePath <Path to exported .cer certificate> -Update -Supplemental
```
> [!IMPORTANT]
> Failing to perform this step will leave you unable to modify or disable this policy and will lead to boot failure. For more information about how to disable signed WDAC policies causing boot failure, see [Remove WDAC policies causing boot stop failures](/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies#remove-wdac-policies-causing-boot-stop-failures).
> Failing to perform this step will leave you unable to modify or disable this policy and will lead to boot failure. For more information about how to disable signed policies causing boot failure, see [Remove Windows Defender Application Control policies causing boot stop failures](disable-windows-defender-application-control-policies.md#remove-wdac-policies-causing-boot-stop-failures).
4. Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
@ -104,19 +95,13 @@ Before you attempt to deploy signed WDAC policy, you should first deploy an unsi
ConvertFrom-CIPolicy $LamnaServerPolicy $CIPolicyBin
```
</details>
## Sign your WDAC policy
### Policy signing with Device Guard Signing Service v2 (DGSS)
If you have an existing Microsoft Store for Business and Education account, you can use the DGSS to sign your WDAC policy. For more information, see [Submit-SigningJob](/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business#submit-signingjob).
## Sign your policy
### Policy signing with signtool.exe
If you purchased a code signing certificate or issued one from your own PKI, you can use [SignTool.exe](/windows/win32/seccrypto/signtool) to sign your WDAC policy files:
1. Import the .pfx code signing certificate into the user’s personal store on the computer where the signing will happen. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
1. Import the .pfx code signing certificate into the user's personal store on the computer where the signing will happen. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
2. Sign the WDAC policy by using SignTool.exe:
@ -125,9 +110,9 @@ If you purchased a code signing certificate or issued one from your own PKI, you
```
> [!NOTE]
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoSigningCert** is the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoSigningCert** is the subject name of the certificate that will be used to sign the policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
When complete, the commands should output a signed policy file with a .p7 extension. You must rename the file to *{GUID}*.cip where "{GUID}" is the &lt;PolicyId&gt; from your original WDAC policy XML.
When complete, the commands should output a signed policy file with a `.p7` extension. You must rename the file to `{GUID}.cip` where "{GUID}" is the &lt;PolicyId&gt; from your original WDAC policy XML.
## Verify and deploy the signed policy
@ -139,7 +124,7 @@ certutil.exe -asn <path to signed policy file>
Thoroughly test the signed policy on a representative set of computers before proceeding with deployment. Be sure to reboot the test computers at least twice after applying the signed WDAC policy to ensure you don't encounter a boot failure.
Once you've verified the signed policy, deploy it using your preferred deployment method. For information about deploying WDAC policies, see [Deploying WDAC policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
Once you've verified the signed policy, deploy it using your preferred deployment method. For more information about deploying policies, see [Deploying Windows Defender Application Control policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
> [!NOTE]
> Anti-tampering protection for signed WDAC policies takes effect after the first reboot once the signed WDAC policy is applied to a computer. This protection only applies to computers with UEFI Secure Boot enabled.
> Anti-tampering protection for signed policies takes effect after the first reboot once the signed policy is applied to a computer. This protection only applies to computers with UEFI Secure Boot enabled.