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

Merge branch 'main' into pm-20221122-credential-guard

Browse Source
This commit is contained in:
Paolo Matarazzo 2022-12-05 13:17:01 -05:00 committed by GitHub
commit 12ebd7e34f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
19 changed files with 520 additions and 702 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
.openpublishing.redirection.json
View File

@ -705,6 +705,21 @@
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set",
"redirect_document_id": false
},
{
"source_path": "store-for-business/device-guard-signing-portal.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/use-device-guard-signing-portal-in-microsoft-store-for-business",
"redirect_document_id": false
},
{
"source_path": "store-for-business/add-unsigned-app-to-code-integrity-policy.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control",
"redirect_document_id": false
},
{
"source_path": "store-for-business/sign-code-integrity-policy-with-device-guard-signing.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering",
"redirect_document_id": false
},
{
"source_path": "windows/security/threat-protection/device-guard/device-guard-deployment-guide.md",
"redirect_url": "/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide",

119
store-for-business/add-unsigned-app-to-code-integrity-policy.md
View File

@ -1,119 +0,0 @@
---
title: Add unsigned app to code integrity policy (Windows 10)
description: When you want to add an unsigned app to a code integrity policy, you need to start with a code integrity policy created from a reference device.
ms.assetid: 580E18B1-2FFD-4EE4-8CC5-6F375BE224EA
ms.reviewer:
ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: store, security
ms.author: cmcatee
author: cmcatee-MSFT
manager: scotv
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 07/21/2021
---
# Add unsigned app to code integrity policy
> [!IMPORTANT]
> Microsoft Store for Business and Microsoft Store for Education will be retired in the first quarter of 2023. You can continue to use the current capabilities of free apps until that time. For more information about this change, see [Update to Endpoint Manager integration with the Microsoft Store on Windows](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/update-to-endpoint-manager-integration-with-the-microsoft-store/ba-p/3585077) and [FAQ: Supporting Microsoft Store experiences on managed devices](https://techcommunity.microsoft.com/t5/windows-management/faq-supporting-microsoft-store-experiences-on-managed-devices/m-p/3585286).
> [!IMPORTANT]
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
>
> Following are the major changes we are making to the service:
>
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download at [https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/).
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
>
> The following functionality will be available via these PowerShell cmdlets:
>
> - Get a CI policy
> - Sign a CI policy
> - Sign a catalog
> - Download root cert
> - Download history of your signing operations
>
> For any questions, please contact us at DGSSMigration@microsoft.com.
**Applies to**
- Windows 10
When you want to add an unsigned app to a code integrity policy, you need to start with a code integrity policy created from a reference device. Then, create the catalog files for your unsigned app, sign the catalog files, and then merge the default policy that includes your signing certificate with existing code integrity policies.
## Create a code integrity policy based on a reference device
To add an unsigned app to a code integrity policy, your code integrity policy must be created from golden image machine. For more information, see [Create a Device Guard code integrity policy based on a reference device](/windows/device-security/device-guard/device-guard-deployment-guide).
## Create catalog files for your unsigned app
Creating catalog files starts the process for adding an unsigned app to a code integrity policy.
Before you get started, be sure to review these best practices and requirements:
### Requirements
- You'll use Package Inspector during this process.
- Only perform this process with a code integrity policy running in audit mode. You should not perform this process on a system running an enforced Device Guard policy.
### Best practices
- **Naming convention** -- Using a naming convention makes it easier to find deployed catalog files. We'll use \*-Contoso.cat as the naming convention in this topic. For more information, see the section Inventorying catalog files by using Microsoft Endpoint Manager in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
- **Where to deploy code integrity policy** -- The [code integrity policy that you created](#create-a-code-integrity-policy-based-on-a-reference-device) should be deployed to the system on which you are running Package Inspector. This will ensure that the code integrity policy binaries are trusted.
Copy the commands for each step into an elevated Windows PowerShell session. You'll use Package Inspector to find and trust all binaries in the app.
### To create catalog files for your unsigned app
1. Start Package Inspector to scan the C drive.
`PackageInspector.exe Start C:`
2. Copy the installation media to the C drive.
Copying the installation media to the C drive ensures that Package Inspector finds and catalogs the installer. If you skip this step, the code integrity policy may trust the application to run, but not trust it to be installed.
3. Install and start the app.
All binaries that are used while Package Inspector is running will be part of the catalog files. After the installation, start the app and make sure that any product updates are installed and any downloadable content was found during the scan. Then, close and restart the app to make sure that the scan found all binaries.
4. Stop the scan and create definition and catalog files.
After app install is complete, stop the Package Inspector scan and create catalog and definition files on your desktop.
`$ExamplePath=$env:userprofile+"\Desktop"`
`$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
`$CatDefName=$ExamplePath+"\LOBApp.cdf"`
`PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
The Package Inspector scan catalogs the hash values for each binary file that is finds. If the app that was scanned are updated, do this process again to trust the new binaries hash values.
After you're done, the files are saved to your desktop. You still need to sign the catalog file so that it will be trusted within the code integrity policy.
## Catalog signing with Device Guard signing portal
To sign catalog files with the Device Guard signing portal, you need to be signed up with the Microsoft Store for Business.
Catalog signing is a vital step to adding your unsigned apps to your code integrity policy.
### To sign a catalog file with Device Guard signing portal
1. Sign in to the [Microsoft Store for Business](https://businessstore.microsoft.com) or [Store for Education](https://educationstore.microsoft.com).
2. Click **Settings**, click **Store settings**, and then click **Device Guard**.
3. Click **Upload** to upload your unsigned catalog files. These are the catalog files you created earlier in [Create catalog files for your unsigned app](#create-catalog-files-for-your-unsigned-app).
4. After the files are uploaded, click **Sign** to sign the catalog files.
5. Click Download to download each item:
- signed catalog file
- default policy
- root certificate for your organization
When you use the Device Guard signing portal to sign a catalog file, the signing certificate is added to the default policy. When you download the signed catalog file, you should also download the default policy and merge this code integrity policy with your existing code integrity policies to protect machines running the catalog file. You need to do this step to trust and run your catalog files. For more information, see the Merging code integrity policies in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
6. Open the root certificate that you downloaded, and follow the steps in **Certificate Import wizard** to install the certificate in your machine's certificate store.
7. Deploy signed catalogs to your managed devices. For more information, see Deploy catalog files with Group Policy, or Deploy catalog files with Microsoft Endpoint Manager in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).

201
store-for-business/device-guard-signing-portal.md
View File

@ -1,201 +0,0 @@
---
title: Device Guard signing (Windows 10)
description: Device Guard signing is a Device Guard feature that is available in the Microsoft Store for Business and Microsoft Store for Education.
ms.assetid: 8D9CD2B9-5FC6-4C3D-AA96-F135AFEEBB78
ms.reviewer:
manager: dansimp
ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: store, security
author: TrudyHa
ms.author: TrudyHa
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 07/21/2021
---
# Device Guard signing
**Applies to**
- Windows 10
> [!IMPORTANT]
> Microsoft Store for Business and Microsoft Store for Education will be retired in the first quarter of 2023. You can continue to use the current capabilities of free apps until that time. For more information about this change, see [Update to Endpoint Manager integration with the Microsoft Store on Windows](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/update-to-endpoint-manager-integration-with-the-microsoft-store/ba-p/3585077) and [FAQ: Supporting Microsoft Store experiences on managed devices](https://techcommunity.microsoft.com/t5/windows-management/faq-supporting-microsoft-store-experiences-on-managed-devices/m-p/3585286).
> [!IMPORTANT]
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
>
> Following are the major changes we are making to the service:
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download, https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/.
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
>
> The following functionality will be available via these PowerShell cmdlets:
> - Get a CI policy
> - Sign a CI policy
> - Sign a catalog
> - Download root cert
> - Download history of your signing operations
>
> For any questions, please contact us at DGSSMigration@microsoft.com.
Device Guard signing is a Device Guard feature that gives admins a single place to sign catalog files and code integrity policies. After admins have created catalog files for unsigned apps and signed the catalog files, they can add the signers to a code integrity policy. You can merge the code integrity policy with your existing policy to include your custom signing certificate. This allows you to trust the catalog files.
Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features use new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called configurable code integrity, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines. Also, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing allows organizations to trust individual third-party applications. For more information, see [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
## In this section
| Topic | Description |
| ----- | ----------- |
| [Add unsigned app to code integrity policy](add-unsigned-app-to-code-integrity-policy.md) | When you want to add an unsigned app to a code integrity policy, you need to start with a code integrity policy created from a reference device. Then, create the catalog files for your unsigned app, sign the catalog files, and then merge the default policy that includes your signing certificate with existing code integrity policies. |
| [Sign code integrity policy with Device Guard signing](sign-code-integrity-policy-with-device-guard-signing.md) | Signing code integrity policies prevents policies from being tampered with after they're deployed. You can sign code integrity policies with the Device Guard signing portal. |
## Device Guard Signing Service (v2) PowerShell Commands
> [!NOTE]
> [.. common ..] are parameters common across all commands that 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] [.. common ..]
```
- 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: create the folder first).
**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] [.. common ..]
```
- 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: create the folder first).
**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] [.. common ..]
```
- Parameters:
**OutFile** - string, mandatory - The filename where the signing history file should be persisted to disk. The file name should be a .xml file. If the file already exists, it will be overwritten (note: create the folder first).
**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"] [.. common ..]
```
- Parameters:
**InFile** - string, mandatory - The file to be signed. This should be a file of the types described in description above (.cat or .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: create the folder first)
**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 presents, the output file will be both signed and timestamped. If both NoTimestamp and TimeStamperUrl not present, the signing operation will skip timestamping the output file, and it will be signed only.
**TimeStamperUrl** - string, optional - If this value is invalid Url (and NoTimestamp not present), the module will throw exception. To understand more about timestamping, refer to [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 rocess the agent may wish 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 V1 migration.
- Usage:
```powershell
Submit-SigningV1MigrationPolicy -InFile filename -OutFile filename [-NoTimestamp][-TimeStamperUrl "timestamper url"] [-JobDescription "description"] [.. common ..]
```
- Parameters:
**InFile** - string, mandatory - The file to be signed. This should be a file of the types described in description above (.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]
> Create the folder first.
**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 presents, the output file will be both signed and timestamped. If both NoTimestamp and TimeStamperUrl not present, the signing operation will skip timestamping the output file, and it will be signed only.
**TimeStamperUrl** - string, optional - If this value is invalid Url (and NoTimestamp not present), the module will throw exception. To understand more about timestamping, refer to [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 the agent may wish 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 [.. common ..]**
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 (e.g., for
authentication) when the switch is set, the operation will instead fail.
**Credential + AppId** - PSCredential - A login credential (username and password) and AppId.
## File and size limits
When you're uploading files for Device Guard 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 have required files types.
| File | Required file type |
|---------------|--------------------|
| catalog files | .cat |
| policy files | .bin |
## Store for Business roles and permissions
Signing code integrity policies and access to Device Guard portal requires the Device Guard signer role.
## Device Guard signing certificates
All certificates generated by the Device Guard signing service 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.

63
store-for-business/sign-code-integrity-policy-with-device-guard-signing.md
View File

@ -1,63 +0,0 @@
---
title: Sign code integrity policy with Device Guard signing (Windows 10)
description: Signing code integrity policies prevents policies from being tampered with after they're deployed. You can sign code integrity policies with the Device Guard signing portal.
ms.assetid: 63B56B8B-2A40-44B5-B100-DC50C43D20A9
ms.reviewer:
manager: dansimp
ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: store, security
author: TrudyHa
ms.author: TrudyHa
ms.topic: conceptual
ms.localizationpriority: medium
ms.date: 07/21/2021
---
# Sign code integrity policy with Device Guard signing
> [!IMPORTANT]
> Microsoft Store for Business and Microsoft Store for Education will be retired in the first quarter of 2023. You can continue to use the current capabilities of free apps until that time. For more information about this change, see [Update to Endpoint Manager integration with the Microsoft Store on Windows](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/update-to-endpoint-manager-integration-with-the-microsoft-store/ba-p/3585077) and [FAQ: Supporting Microsoft Store experiences on managed devices](https://techcommunity.microsoft.com/t5/windows-management/faq-supporting-microsoft-store-experiences-on-managed-devices/m-p/3585286).
> [!IMPORTANT]
> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
>
> Following are the major changes we are making to the service:
> - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download, https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/.
> - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it).
> - DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download). Note that the certificate used to sign a file can be easily extracted from the signed file itself. As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
>
> The following functionality will be available via these PowerShell cmdlets:
> - Get a CI policy
> - Sign a CI policy
> - Sign a catalog
> - Download root cert
> - Download history of your signing operations
>
> For any questions, please contact us at DGSSMigration@microsoft.com.
**Applies to**
- Windows 10
Signing code integrity policies prevents policies from being tampered with after they're deployed. You can sign code integrity policies with the Device Guard signing portal.
## Sign your code integrity policy
Before you get started, be sure to review these best practices:
**Best practices**
- Test your code integrity policies on a group of devices before deploying them to a large group of devices.
- Use rule options 9 and 10 during testing. For more information, see the section Code integrity policy rules in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
**To sign a code integrity policy**
1. Sign in to the [Microsoft Store for Business](https://businessstore.microsoft.com) or [Microsoft Store for Education](https://educationstore.microsoft.com).
2. Click **Manage**, click **Store settings**, and then click **Device Guard**.
3. Click **Upload** to upload your code integrity policy.
4. After the files are uploaded, click **Sign** to sign the code integrity policy.
5. Click **Download** to download the signed code integrity policy.
When you sign a code integrity policy with the Device Guard signing portal, the signing certificate is added to the policy. This means you can't modify this policy. If you need to make changes, make them to an unsigned version of the policy, and then resign the policy.

6
windows/client-management/mdm/policy-csp-system.md
View File

@ -205,7 +205,7 @@ Windows diagnostic data is collected when the Allow Telemetry policy setting is
If you disable or don't configure this setting, Microsoft will be the controller of the Windows diagnostic data collected from the device and processed in accordance with Microsoft’s [privacy statement](https://go.microsoft.com/fwlink/?LinkId=521839) unless you have enabled policies like Allow Update Compliance Processing or Allow Desktop Analytics Processing.
Configuring this setting doesn't change the Windows diagnostic data collection level set for the device or the operation of optional analytics processor services like Desktop Analytics and Update Compliance.
Configuring this setting doesn't change the Windows diagnostic data collection level set for the device or the operation of optional analytics processor services like Desktop Analytics and Windows Update for Business reports.
See the documentation at [ConfigureWDD](https://aka.ms/ConfigureWDD) for information on this and other policies that will result in Microsoft being the processor of Windows diagnostic data.
@ -700,11 +700,11 @@ To enable this behavior, you must complete three steps:
1. Enable this policy setting.
2. Set **AllowTelemetry** to 1 – **Required (Basic)** or above.
3. Set the Configure the Commercial ID setting for your Update Compliance workspace.
3. If you're using Update Compliance rather than Windows Update for Business reports, set the Configure the Commercial ID setting for your Update Compliance workspace.
When these policies are configured, Windows diagnostic data collected from the device will be subject to Microsoft processor commitments.
If you disable or don't configure this policy setting, devices won't appear in Update Compliance.
If you disable or don't configure this policy setting, devices won't appear in Windows Update for Business reports or Update Compliance.
<!--/Description-->
<!--ADMXMapped-->

4
windows/deployment/update/deployment-service-overview.md
View File

@ -35,14 +35,14 @@ The service is privacy focused and backed by leading industry compliance certifi
## How it works
The deployment service complements existing Windows Update for Business capabilities, including existing device policies and [Update Compliance](update-compliance-monitor.md).
The deployment service complements existing Windows Update for Business capabilities, including existing device policies and [Windows Update for Businesss reports](wufb-reports-overview.md).
:::image type="content" source="media/wufbds-product-large.png" alt-text="Elements in following text.":::
Windows Update for Business comprises three elements:
- Client policy to govern update experiences and timing – available through Group Policy and CSPs
- Deployment service APIs to approve and schedule specific updates – available through the Microsoft Graph and associated SDKs (including PowerShell)
- Update Compliance to monitor update deployment – available through the Azure Marketplace
- Windows Update for Business reports to monitor update deployment
Unlike existing client policy, the deployment service doesn't interact with devices directly. The service is native to the cloud and all operations take place between various Microsoft services. It creates a direct communication channel between a management tool (including scripting tools such as Windows PowerShell) and the Windows Update service so that the approval and offering of content can be directly controlled by an IT Pro.

4
windows/deployment/update/includes/wufb-reports-recommend.md
View File

@ -5,10 +5,10 @@ manager: aaroncz
ms.prod: w10
ms.collection: M365-modern-desktop
ms.topic: include
ms.date: 11/04/2022
ms.date: 12/05/2022
ms.localizationpriority: medium
---
<!--This file is shared by all Update Compliance v1 articles. -->
> [!Important]
> If you're using Update Compliance, it's highly recommended that you start transitioning to Windows Update for Business reports. For more information, see [Windows Update for Business reports overview](..\wufb-reports-overview.md).
> Update Compliance no longer accepts new onboarding requests and new requests will fail. Instead, use [Windows Update for Business reports](..\wufb-reports-overview.md) to monitor compliance for updates. If you're currently using Update Compliance, you can continue to use it, but you can't change your `CommercialID`.

2
windows/deployment/update/index.md
View File

@ -33,7 +33,7 @@ Windows as a service provides a new way to think about building, deploying, and
| [Overview of Windows as a service](waas-overview.md) | Explains the differences in building, deploying, and servicing Windows client; introduces feature updates, quality updates, and the different servicing branches; compares servicing tools. |
| [Prepare servicing strategy for Windows client updates](waas-servicing-strategy-windows-10-updates.md) | Explains the decisions you need to make in your servicing strategy. |
| [Assign devices to servicing branches for Windows client updates](waas-servicing-channels-windows-10-updates.md) | Explains how to assign devices to the General Availability Channel for feature and quality updates, and how to enroll devices in Windows Insider. |
| [Monitor Windows Updates with Update Compliance](update-compliance-monitor.md) | Explains how to use Update Compliance to monitor and manage Windows Updates on devices in your organization. |
| [Monitor Windows Updates with Windows Update for Business reports](wufb-reports-overview.md) | Explains how to use Windows Update for Business reports to monitor and manage Windows Updates on devices in your organization. |
| [Optimize update delivery](../do/waas-optimize-windows-10-updates.md) | Explains the benefits of using Delivery Optimization or BranchCache for update distribution. |
| [Deploy updates using Windows Update for Business](waas-manage-updates-wufb.md) | Explains how to use Windows Update for Business to manage when devices receive updates directly from Windows Update. Includes walkthroughs for configuring Windows Update for Business using Group Policy and Microsoft Intune. |
| [Deploy Windows client updates using Windows Server Update Services (WSUS)](waas-manage-updates-wsus.md) | Explains how to use WSUS to manage Windows client updates. |

6
windows/deployment/update/safeguard-holds.md
View File

@ -31,9 +31,9 @@ IT admins managing updates using the [Windows Update for Business deployment ser
## Am I affected by a safeguard hold?
IT admins can use [Update Compliance](update-compliance-monitor.md) to monitor various update health metrics for devices in their organization. Update Compliance provides a [Safeguard Holds report](/windows/deployment/update/update-compliance-safeguard-holds), as well as [queries in the Feature Update Status report](/windows/deployment/update/update-compliance-feature-update-status), to provide you insight into the safeguard holds that are preventing devices from updating or upgrading.
IT admins can use [Windows Update for Business reports](wufb-reports-overview.md) to monitor various update health metrics for devices in their organization. The reports provide a list of [active Safeguard Holds](wufb-reports-workbook.md#bkmk_update-group-feature) to provide you insight into the safeguard holds that are preventing devices from updating or upgrading.
The Update Compliance reports identify safeguard holds by their 8-digit identifiers. For safeguard holds associated with publicly discussed known issues, you can find additional details about the issue on the [Windows release health](/windows/release-health/) dashboard by searching for the safeguard hold ID on the **Known issues** page for the relevant release.
Windows Update for Business reports identifies safeguard holds by their 8-digit identifiers. For safeguard holds associated with publicly discussed known issues, you can find additional details about the issue on the [Windows release health](/windows/release-health/) dashboard by searching for the safeguard hold ID on the **Known issues** page for the relevant release.
On devices that use Windows Update (but not Windows Update for Business), the **Windows Update** page in the Settings app displays a message stating that an update is on its way, but not ready for the device. Instead of the option to download and install the update, users will see this message:
@ -48,4 +48,4 @@ We recommend that you do not attempt to manually update until issues have been r
> [!CAUTION]
> Opting out of a safeguard hold can put devices at risk from known performance issues. We strongly recommend that you complete robust testing to ensure the impact is acceptable before opting out.
With that in mind, IT admins who stay informed with [Update Compliance](update-compliance-feature-update-status.md#safeguard-holds) and the [Windows release health](/windows/release-health/) dashboard can choose to temporarily [opt-out of the protection of all safeguard holds](safeguard-opt-out.md) and allow an update to proceed. We recommend opting out only in an IT environment and for validation purposes. If you do opt out of a hold, this condition is temporary. Once an update is complete, the protection of safeguard holds is reinstated automatically.
With that in mind, IT admins who stay informed with [Windows Update for Business reports](wufb-reports-overview.md) and the [Windows release health](/windows/release-health/) dashboard can choose to temporarily [opt-out of the protection of all safeguard holds](safeguard-opt-out.md) and allow an update to proceed. We recommend opting out only in an IT environment and for validation purposes. If you do opt out of a hold, this condition is temporary. Once an update is complete, the protection of safeguard holds is reinstated automatically.

6
windows/deployment/update/wufb-reports-configuration-intune.md
View File

@ -9,7 +9,7 @@ ms.author: mstewart
ms.localizationpriority: medium
ms.collection: M365-analytics
ms.topic: article
ms.date: 11/15/2022
ms.date: 12/05/2022
ms.technology: itpro-updates
---
@ -102,8 +102,12 @@ Create a configuration profile that will set the required policies for Windows U
The [Windows Update for Business reports Configuration Script](wufb-reports-configuration-script.md) is a useful tool for properly enrolling devices in Windows Update for Business reports, though it isn't strictly necessary. It checks to ensure that devices have the required services running and checks connectivity to the endpoints detailed in the section on [Manually configuring devices for Windows Update for Business reports](wufb-reports-configuration-manual.md). You can deploy the script as a Win32 app. For more information, see [Win32 app management in Microsoft Intune](/mem/intune/apps/apps-win32-app-management).
> [!NOTE]
> Using the script is optional when configuring devices through Intune. The script can be leveraged as a troubleshooting tool to ensure that devices are properly configured for Windows Update for Business reports.
When you deploy the configuration script as a Win32 app, you won't be able to retrieve the results of logs on the device without having access to the device, or saving results of the logs to a shared filesystem. We recommend deploying the script in pilot mode to a subset of devices that you can access. After following this guidance, you can deploy the configuration script in deployment mode as a Win32 app to all Windows Update for Business reports devices.
## Next steps
[Use Windows Update for Business reports](wufb-reports-use.md)

4
windows/deployment/update/wufb-reports-help.md
View File

@ -51,8 +51,8 @@ You can open support requests directly from the Azure portal. If the **Help + S
- **Issue type** - ***Technical***
- **Subscription** - Select the subscription used for Windows Update for Business reports
- **Service** - ***My services***
- **Service type** - ***Monitoring and Management***
- **Problem type** - ***Windows Update for Business reports***
- **Service type** - Select ***Windows Update for Business reports*** under ***Monitoring and Management***
1. Based on the information you provided, you'll be shown some **Recommended solutions** you can use to try to resolve the problem.
1. Complete the **Additional details** tab and then create the request on the **Review + create** tab.

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

@ -87,17 +87,17 @@
href: merge-windows-defender-application-control-policies.md
- name: Enforce WDAC policies
href: enforce-windows-defender-application-control-policies.md
- name: Use code signing to simplify application control for classic Windows applications
- name: Use code signing for added control and protection with WDAC
href: use-code-signing-to-simplify-application-control-for-classic-windows-applications.md
items:
- name: "Optional: Use the WDAC Signing Portal in the Microsoft Store for Business"
- name: Deploy catalog files to support WDAC
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: Deploy catalog files to support WDAC
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: Disable WDAC policies
href: disable-windows-defender-application-control-policies.md
- name: LOB Win32 Apps on S Mode

24
windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md
View File

@ -9,12 +9,13 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.reviewer: jogeurte
ms.author: vinpa
manager: aaroncz
ms.date: 02/28/2018
ms.date: 12/01/2022
ms.technology: itpro-security
---
@ -29,18 +30,17 @@ ms.technology: itpro-security
>[!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).
As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this signature, you'll either need a publicly issued code signing certificate or an internal CA. If you've purchased a code-signing certificate, you can skip this article and instead follow other articles listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md).
As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this signing, you'll either need a publicly issued code signing certificate or an internal CA. If you've purchased a code-signing certificate, you can skip this article, and instead follow other articles listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md).
If you have an internal CA, complete these steps to create a code signing certificate.
> [!WARNING]
> Boot failure (blue screen) may occur if your signing certificate does not follow these rules:
> When creating signing certificates for WDAC policy signing, Boot failure (blue screen) may occur if your signing certificate does not 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 SHA-256 only. ECDSA isn't supported.
> - 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.
> - Keys must be less than or equal to 4K key size
>
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
@ -86,7 +86,7 @@ When this certificate template has been created, you must publish it to the CA p
2. Select the WDAC Catalog signing certificate, and then select **OK**.
Now that the template is available to be issued, you must request one from the computer running Windows 10 and Windows 11 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
Now that the template is available to be issued, you must request one from the computer running Windows 10 or Windows 11 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
1. In MMC, from the **File** menu, select **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
@ -100,7 +100,7 @@ Now that the template is available to be issued, you must request one from the c
Figure 4. Get more information for your code signing certificate
5. In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then select **Add**. When added, select **OK.**
5. In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, specify a meaningful name for your certificate (in this example, we select **$ContosoSigningCert**), and then select **Add**. When added, select **OK.**
6. Enroll and finish.
@ -118,9 +118,3 @@ This certificate must be installed in the user's personal store on the computer
4. Set a password, select an export path, and then select **WDACCatSigningCert.pfx** as the file name.
When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
## Related topics
- [Windows Defender Application Control](windows-defender-application-control.md)
- [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md)

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

@ -9,12 +9,13 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: jgeurten
ms.author: vinpa
manager: aaroncz
ms.date: 02/28/2018
ms.date: 11/30/2022
ms.technology: itpro-security
---
@ -22,62 +23,62 @@ ms.technology: itpro-security
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
- Windows 10
- Windows 11
- 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).
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. To prepare to create WDAC policies that allow these trusted applications but block unsigned code (most malware is unsigned), you create a *catalog file* that contains information about the trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by WDAC in the same way as any other signed application. With this foundation, you can more easily block all unsigned applications, allowing only signed applications to run.
*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.
## Create catalog files
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.
The creation of a catalog file simplifies the steps to run unsigned applications in the presence of a Windows Defender Application Control policy.
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).
To create a catalog file, you use a tool called **Package Inspector**. You must also have a WDAC policy deployed in audit mode on the computer on which you run Package Inspector, so that Package Inspector can include any temporary installation files that are added and then removed from the computer during the installation process.
## Create catalog files using Package Inspector
> [!NOTE]
> When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention.
To create a catalog file for an existing app, you can use a tool called **Package Inspector** that comes with Windows.
1. Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you'll run Package Inspector.
Package Inspector doesn't always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode.
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.
> [!NOTE]
> This process should **not** be performed on a system with an enforced Windows Defender Application Control policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run the application unless the policy already allows it.
> 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.
2. Start Package Inspector, and then start scanning a local drive, for example, drive C:
You can use this PowerShell sample to make a copy of the DefaultWindows_Audit.xml template:
```powershell
Copy-Item -Path $env:windir\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml -Destination $env:USERPROFILE\Desktop\
$PolicyId = Set-CIPolicyIdInfo -FilePath $env:USERPROFILE\Desktop\DefaultWindows_Audit.xml -PolicyName "Package Inspector Audit Policy" -ResetPolicyID
$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).
2. Start Package Inspector to monitor file creation on a **local drive** where you'll install the app, for example, drive C:
```powershell
PackageInspector.exe Start C:
```
> [!NOTE]
> Package inspector can monitor installations on any local drive. Specify the appropriate drive on the local computer.
3. Copy the installation media to the local drive (typically drive C).
By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future WDAC policy may allow the application to run but not to be installed.
4. Install the application. Install it to the same drive that the application installer is located on (the drive you're scanning). Also, while Package Inspector is running, don't run any installations or updates that you don't want to capture in the catalog.
> [!IMPORTANT]
> Every binary that is run while Package Inspector is running will be captured in the catalog. Ensure that only trusted applications are run during this time.
> Every file that is written to the drive you are watching with Package Inspector will be included in the catalog that is created. Be aware of any other processes that may be running and creating files on the drive.
5. Start the application.
3. Copy the installation media to the drive you're watching with Package Inspector, so that the actual installer is included in the final catalog file. If you skip this step, you may allow the *app* to run, but not actually be able to install it.
6. Ensure that product updates are installed, and downloadable content associated with the application is downloaded.
4. Install the app.
7. Close and reopen the application.
5. Start the app to ensure that files created on initial launch are included in your catalog file.
This step is necessary to ensure that the scan has captured all binaries.
8. As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it's updated, and then close and reopen the application.
6. Use the app as you would normally, so that files created during normal use are included in your catalog file. For example, some apps may download more files on first use of a feature within the app. Be sure to also check for app updates if the app has that capability.
9. When you've confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate.
7. Close and reopen the application to ensure that the scan has captured all binaries.
For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have been scanning, for example, C:.
8. As appropriate, with Package Inspector still running, repeat the steps above 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).
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"
@ -87,42 +88,33 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
```
>[!NOTE]
>Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries' hash values.
>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 double-click the \*.cat file to see its contents, and you can view the \*.cdf file with a text editor.
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.
To trust the contents of the catalog file within a WDAC policy, the catalog must first be signed. Then, the signing certificate can be added to the WDAC policy, and the catalog file can be distributed to the individual client computers.
## Sign your Catalog file
### Resolving package failures
Now that you've created a catalog file for your app, you're ready to sign it.
Packages can fail for the following reasons:
### Catalog signing with Device Guard Signing Service v2 (DGSS)
- Package is too large for default USN Journal or Event Log sizes
- To diagnose whether USN journal size is the issue, after running through Package Inspector, click Start > install app > PackageInspector stop
- 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)
- `fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt`
- ReadJournal command should throw an error if the older USNs don't exist anymore due to overflow
- For USN Journal, log size can be expanded using: `fsutil usn createjournal` command with a new size and alloc delta. `Fsutil usn queryjournal` will give the current size and allocation delta, so using a multiple of that may help
- To diagnose whether Eventlog size is the issue, look at the Microsoft/Windows/CodeIntegrity/Operational log under Applications and Services logs in Event Viewer and ensure that there are entries present from when you began Package Inspector (You can use write time as a justification; if you started the install 2 hours ago and there are only entries from 30 minutes prior, the log is definitely too small)
- To increase Eventlog size, in Event Viewer you can right click the operational log, click properties, and then set new values (some multiple of what it was previously)
- Package files that change hash each time the package is installed
- Package Inspector is incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this hash-change by looking at the hash field in the 3077 block events when the package is failing in enforcement. If each time you attempt to run the package you get a new block event with a different hash, the package won't work with Package Inspector
- Files with an invalid signature blob or otherwise "unhashable" files
- This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec.
- Windows Defender Application Control uses Authenticode Hashes to validate files when they're running. If the file is unhashable via the authenticode SIP, there's no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it)
- Recent versions of InstallShield packages that use custom actions can hit this condition. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
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
### Catalog signing with SignTool.exe
To sign a catalog file you generated by using PackageInspector.exe, you need:
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.
- SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
<br>
<details>
<summary>Expand this section for detailed instructions on signing catalog files with signtool.exe.</summary>
- The catalog file that you generated previously
You need:
- An internal certification authority (CA) code signing certificate or 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
To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell session.
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.
1. Initialize the variables that will be used. Replace the *$ExamplePath* and *$CatFileName* variables as needed:
@ -131,74 +123,59 @@ To sign the existing catalog file, copy each of the following commands into an e
$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
```
2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user's personal store.
3. Sign the catalog file with Signtool.exe:
2. Sign the catalog file with Signtool.exe:
```powershell
<path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
<path to signtool.exe> sign /n "ContosoSigningCert" /fd sha256 /v $CatFileName
```
>[!NOTE]
>The *&lt;Path to signtool.exe&gt;* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* 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 *&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.
>
>For additional information about Signtool.exe and all additional switches, visit the [Sign Tool page](/dotnet/framework/tools/signtool-exe).
4. Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 1.
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
5. Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
</details>
For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, to copy the appropriate catalog files to all desired computers, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as Microsoft Configuration Manager, which also simplifies the management of catalog versions.
## Deploy the catalog file to your managed endpoints
## Add a catalog signing certificate to a Windows Defender Application Control policy
Catalog files in Windows are stored under ***%windir%\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}***.
After the catalog file is signed, add the signing certificate to a WDAC policy, as described in the following steps.
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.
1. If you haven't already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
### Deploy catalog files with Group Policy
2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder** by scanning the system and allowlisting by signer and original filename:
To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate computers in your organization.
```powershell
New-CIPolicy -Level FilePublisher -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs -MultiplePolicyFormat -Fallback SignedVersion,Publisher,Hash
```
<br>
<details>
<summary>Expand this section for detailed instructions on deploying catalog files using Group Policy.</summary>
> [!NOTE]
> Include the **-UserPEs** parameter to ensure that the policy includes user mode code integrity.
3. Use [Add-SignerRule](/powershell/module/configci/add-signerrule) to add the signing certificate to the WDAC policy, filling in the correct path and filenames for `<policypath>` and `<certificate_path>`:
```powershell
Add-SignerRule -FilePath <policypath> -CertificatePath <certificate_path> -User
```
If you used step 2 to create a new WDAC policy, and want information about merging policies together, see [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md).
## 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. The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called DG Enabled PCs with a GPO called **Contoso DG 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.
2. Create a new GPO: right-click an OU, for example, the **DG Enabled PCs OU**, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
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.
> [!NOTE]
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate).
> You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies.
![Group Policy Management, create a GPO.](images/dg-fig13-createnewgpo.png)
Figure 2. Create a new GPO
3. Give the new GPO a name, for example, **Contoso DG Catalog File GPO Test**, or any name you prefer.
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 click **Edit**.
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 click **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)
@ -224,144 +201,200 @@ To simplify the management of catalog files, you can use Group Policy preference
10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Enabling this option ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
11. Click **OK** to complete file creation.
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, 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.
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.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate WDAC policy.
</details>
## Deploy catalog files with Microsoft Configuration Manager
### 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. Complete the following steps to create a new deployment package for catalog files:
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>
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.
1. Open the Configuration Manager console, and select the Software Library workspace.
2. Navigate to Overview\\Application Management, right-click **Packages**, and then click **Create Package**.
2. Navigate to Overview\\Application Management, right-click **Packages**, and then select **Create Package**.
3. Name the package, set your organization as the manufacturer, and select an appropriate version number.
3. Name the package, set your organization as the manufacturer, and select an appropriate version number.
![Create Package and Program Wizard.](images/dg-fig16-specifyinfo.png)
Figure 5. Specify information about the new package
4. Click **Next**, and then select **Standard program** as the program type.
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 **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 (Figure 6):
6. On the **Standard Program** page, select the following options (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**.
- 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**.
- 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**.
- 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
7. Accept the defaults for the rest of the wizard, and then close the wizard.
7. Accept the defaults for the rest of the wizard, and then close the wizard.
After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you created to a test collection:
1. In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
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 click **Next**.
2. On the **General** page, select the test collection to which the catalog files will be deployed, and then select **Next**.
3. On the **Content** page, click **Add** to select the distribution point that will serve content to the selected collection, and then click **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**.
4. On the **Deployment Settings** page, select **Required** in the **Purpose** box.
4. On the **Deployment Settings** page, select **Required** in the **Purpose** box.
5. On the **Scheduling** page, click **New**.
5. On the **Scheduling** page, select **New**.
6. In the **Assignment Schedule** dialog box, select **Assign immediately after this event**, set the value to **As soon as possible**, and then click **OK**.
6. In the **Assignment Schedule** dialog box, select **Assign immediately after this event**, set the value to **As soon as possible**, and then select **OK**.
7. On the **Scheduling** page, click **Next**.
7. On the **Scheduling** page, select **Next**.
8. On the **User Experience** page (Figure 7), set the following options, and then click **Next**:
8. On the **User Experience** page (Figure 7), set the following options, and then select **Next**:
- Select the **Software installation** check box.
- Select the **Software installation** check box.
- Select the **Commit changes at deadline or during a maintenance window (requires restarts)** check box.
- Select the **Commit changes at deadline or during a maintenance window (requires restarts)** check box.
![Deploy Software Wizard, User Experience page.](images/dg-fig18-specifyux.png)
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 click **Next**.
9. On the **Distribution Points** page, in the **Deployment options** box, select **Run program from distribution point**, and then select **Next**.
10. On the **Summary** page, review the selections, and then click **Next**.
10. On the **Summary** page, review the selections, and then select **Next**.
11. Close the wizard.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate WDAC policy,.
</details>
## Inventory catalog files with Microsoft Configuration Manager
#### 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. The following process walks you through the enablement of software inventory to discover catalog files on your managed systems through the creation and deployment of a new client settings policy.
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>
You can configure software inventory to find catalog files on your managed systems by creating and deploying a new client settings policy.
>[!NOTE]
>A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process. In this example, *-Contoso* has been added to all catalog file names.
1. Open the Configuration Manager console, and select the Administration workspace.
1. Open the Configuration Manager console, and select the Administration workspace.
2. Navigate to **Overview\\Client Settings**, right-click **Client Settings**, and then click **Create Custom Client Device Settings**.
2. Navigate to **Overview\\Client Settings**, right-click **Client Settings**, and then select **Create Custom Client Device Settings**.
3. Name the new policy, and under **Select and then configure the custom settings for client devices**, select the **Software Inventory** check box, as shown in Figure 8.
3. Name the new policy, and under **Select and then configure the custom settings for client devices**, select the **Software Inventory** check box, as shown in Figure 8.
![Create Custom Client Device Settings.](images/dg-fig19-customsettings.png)
Figure 8. Select custom settings
4. In the navigation pane, click **Software Inventory**, and then click **Set Types**, as shown in Figure 9.
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
5. In the **Configure Client Setting** dialog box, click the **Start** button to open the **Inventories File Properties** dialog box.
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 click **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
8. Click **OK**.
8. Select **OK**.
9. Now that you've created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
9. Now that you've created the client settings policy, right-click the new policy, select **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you'll be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
2. Navigate to Overview\\Devices, and search for the device on which you want to view the inventoried files.
2. Navigate to Overview\\Devices, and search for the device on which you want to view the inventoried files.
3. Right-click the computer, point to **Start**, and then click **Resource Explorer**.
3. Right-click the computer, point to **Start**, and then select **Resource Explorer**.
4. In Resource Explorer, navigate to Software\\File Details to view the inventoried catalog files.
4. In Resource Explorer, navigate to Software\\File Details to view the inventoried catalog files.
>[!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.
## Related topics
</details>
- [Windows Defender Application Control](windows-defender-application-control.md)
## Allow apps signed by your catalog signing certificate in your WDAC policy
- [Windows Defender Application Control Design Guide](windows-defender-application-control-design-guide.md)
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).
- [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-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.
```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
```
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.
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.
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.
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.
```powershell
Add-SignerRule -FilePath <path to your WDAC 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:
- **USN journal size is too small to track all files created by the installer**
- To diagnose whether USN journal size is the issue, after running through Package Inspector:
- 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
- **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.
- **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.
- 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.

BIN
windows/security/threat-protection/windows-defender-application-control/images/dg-fig31-getmoreinfo.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 19 KiB

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

@ -1,6 +1,6 @@
---
title: Use code signing to simplify application control for classic Windows applications (Windows)
description: With embedded signing, your WDAC policies typically don't have to be updated when an app is updated. To set up this embedded signing, you can choose from various methods.
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
ms.prod: windows-client
@ -9,16 +9,17 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.reviewer: jogeurte
ms.author: vinpa
manager: aaroncz
ms.date: 05/03/2018
ms.date: 11/29/2022
ms.technology: itpro-security
---
# Use code signing to simplify application control for classic Windows applications
# Use code signing for added control and protection with WDAC
**Applies to:**
@ -29,45 +30,34 @@ ms.technology: itpro-security
> [!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).
This topic covers guidelines for using code signing control classic Windows apps.
## What is code signing and why is it important?
## Reviewing your applications: application signing and catalog files
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.
Typically, Windows Defender Application Control (WDAC) policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This purpose means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
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.
Catalog files can be useful for unsigned LOB applications that can't easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your Windows Defender Application Control policies typically don't have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
## Catalog signing
To obtain signed applications or embed signatures in your in-house applications, you can choose from various methods:
App binaries and scripts are typically either embed-signed or catalog-signed. Embedded signatures become part of the file itself and are carried with the file wherever it's copied or moved. Catalog signatures, on the other hand, are detached from the individual file(s). Instead, a separate "catalog file" is created that contains hash values for one or more files to be signed. This catalog file is then digitally signed and applied to any computer where you want the signature to exist. Any file whose hash value is included in the signed catalog inherits the signature from the catalog file. A file may have multiple signatures, including a mix of embedded and catalog signatures.
- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll up to our certificate authority (CA) or to your own.
- Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
- Using a non-Microsoft signing authority. ISV's and enterprises can use a trusted non-Microsoft signing authority to sign all of their own Classic Windows applications.
To use catalog signing, you can choose from the following options:
- Use the Windows Defender signing portal available in the Microsoft Store for Business and Education. The portal is a Microsoft web service that you can use to sign your Classic Windows applications.
- Create your own catalog files, which are described in the next section.
### Catalog files
Catalog files (which you can create in Windows 10 and Windows 11 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you don't want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by Windows Defender Application Control in the same way as any other signed application.
Catalog files are Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also.
After you've created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
You can use catalog files to easily add a signature to an existing application without needing access to the original source files and without any expensive repackaging. You can even use catalog files to add your own signature to an ISV app when you don't want to trust everything the ISV signs directly, themselves. Then you just deploy the signed catalog along with the app to all your managed endpoints.
> [!NOTE]
> Package Inspector only works on operating systems that support Windows Defender, such as Windows 10 and Windows 11 Enterprise, Windows 10 and Windows 11 Education, Windows 2016 Server, or Windows Enterprise IoT.
> Since catalogs identify the files they sign by hash, any change to the file may invalidate its signature. You will need to deploy updated catalog signatures any time the application is updated. Integrating code signing with your app development or app deployment processes is generally the best approach. Be aware of self-updating apps, as their app binaries may change without your knowledge.
For procedures for working with catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
To learn how to create and manage catalog files for existing apps, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
## Windows Defender Application Control policy formats and signing
## Signed WDAC policies
When you generate a Windows Defender Application Control policy, you're generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
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.
We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
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)
When the Windows Defender Application Control policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add more protection against administrative users changing or removing the policy.
## Obtain code signing certificates for your own use
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).

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

@ -1,6 +1,6 @@
---
title: Use the Device Guard Signing Portal in the Microsoft Store for Business (Windows)
description: You can sign code integrity policies with the Device Guard signing portal to prevent them from being tampered with after they're deployed.
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
@ -10,15 +10,16 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.topic: conceptual
ms.collection: M365-security-compliance
author: jsuther1974
ms.reviewer: isbrahm
ms.reviewer: jogeurte
manager: aaroncz
ms.date: 02/19/2019
ms.date: 11/30/2022
ms.technology: itpro-security
---
# Optional: Use the Device Guard Signing Portal in the Microsoft Store for Business
# Optional: Use the Device Guard Signing Service v2
**Applies to:**
@ -27,27 +28,162 @@ ms.technology: itpro-security
- Windows Server 2016 and above
> [!IMPORTANT]
> The existing web-based mechanism for the Device Guard Signing Service v1 will be retired on June 9, 2021. Please transition to the PowerShell based version of the service [(DGSS v2)](/microsoft-store/device-guard-signing-portal). For more details, see [Sign an MSIX package with Device Guard signing](/windows/msix/package/signing-package-device-guard-signing) and [Device Guard signing](/microsoft-store/device-guard-signing-portal).
> 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]
> 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).
> &lt;DGSSCommonParameters&gt; are parameters common across all commands and are documented below the command definitions.
You can sign code integrity policies with the Device Guard signing portal to prevent them from being tampered with after they're deployed.
### Get-DefaultPolicy
## Sign your code integrity policy
Before you get started, be sure to review these best practices:
Gets the default .xml policy file associated with the current tenant.
**Best practices**
**Usage:**
- Test your code integrity policies on a pilot group of devices before deploying them to production.
- Use rule options 9 and 10 during testing. For more information, see the section Code integrity policy rules in the [Deploy Windows Defender Application Control policy rules and file rules](./select-types-of-rules-to-create.md).
```powershell
Get-DefaultPolicy -OutFile filename [-PassThru] [<DGSSCommonParameters>]
```
**To sign a code integrity policy**
**Parameters:**
1. Sign in to the [Microsoft Store for Business](https://businessstore.microsoft.com) or [Microsoft Store for Education](https://educationstore.microsoft.com).
2. Click **Manage**, click **Store settings**, and then click **Device Guard**.
3. Click **Upload** to upload your code integrity policy.
4. After the files are uploaded, click **Sign** to sign the code integrity policy.
5. Click **Download** to download the signed code integrity policy.
- **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.
When you sign a code integrity policy with the Device Guard signing portal, the signing certificate is added to the policy. This means you can't modify this policy. If you need to make changes, make them to an unsigned version of the policy, and then sign the policy again.
**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.

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

@ -8,6 +8,7 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
ms.topic: conceptual
audience: ITPro
ms.collection: M365-security-compliance
author: jsuther1974
@ -29,89 +30,117 @@ ms.technology: itpro-security
> [!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).
Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies can't be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this idea of the policies in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to restrict users from updating or removing 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 (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).
> [!WARNING]
> Boot failure (blue screen) may occur if your signing certificate does not follow these rules:
> Boot failure (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 SHA-256 only. ECDSA isn't supported.
> - 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.
> - Keys must be less than or equal to 4K key size
>
Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run.
Signing WDAC policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward.
If you don't currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA.
Before PKCS #7-signing WDAC policies for the first time, ensure you enable rule options **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).
To sign a Windows Defender Application Control policy with SignTool.exe, you need the following components:
- SignTool.exe, found in the [Windows SDK](https://developer.microsoft.com/windows/downloads/windows-10-sdk/) (Windows 7 or later)
- The binary format of the WDAC policy that you generated in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) or another WDAC policy that you've created
- An internal CA code signing certificate or a purchased code signing certificate
If you don't have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (WDAC) policy, ensure you update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session:
1. Initialize the variables that will be used:
```powershell
$CIPolicyPath=$env:userprofile+"\Desktop\"
$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
```
> [!NOTE]
> This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are signing another policy, be sure to update the **$CIPolicyPath** variable with the correct information.
2. Import the .pfx code signing certificate. Import the code signing certificate that you'll use to sign the WDAC policy into the user’s personal store on the computer where the signing happens. 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).
3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
4. Navigate to your desktop as the working directory:
```powershell
cd $env:USERPROFILE\Desktop
```
5. Use [Add-SignerRule](/powershell/module/configci/add-signerrule) to add an update signer certificate to the WDAC policy:
```powershell
Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update
```
> [!NOTE]
> *&lt;Path to exported .cer certificate&gt;* should be the full path to the certificate that you exported in step 3.
Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed WDAC policies, see [Remove WDAC policies](disable-windows-defender-application-control-policies.md).
6. Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
```powershell
Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete
```
7. Reset the policy ID and use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the policy to binary format:
```powershell
$PolicyID= Set-CIPolicyIdInfo -FilePath $InitialCIPolicy -ResetPolicyID
$PolicyID = $PolicyID.Substring(11)
$CIPolicyBin = $env:userprofile + "\Desktop\" + $PolicyID + ".cip"
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
```
8. Sign ([PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652)) the WDAC policy by using SignTool.exe:
```powershell
<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin
```
> [!NOTE]
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** 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.
9. Validate the signed file. When complete, the commands should output a signed policy file called {PolicyID}.cip to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy WDAC policies, see [Deploy and manage Windows Defender Application Control with Group Policy](deployment/deploy-windows-defender-application-control-policies-using-group-policy.md).
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).
> [!NOTE]
> The device with the signed policy must be rebooted one time with Secure Boot enabled for the UEFI lock to be set.
> 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.
## 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:
```powershell
$PolicyPath=$env:userprofile+"\Desktop\"
$PolicyName="FixedWorkloadPolicy_Enforced"
$LamnaServerPolicy=$PolicyPath+$PolicyName+".xml"
```
> [!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.
2. Navigate to your desktop as the working directory:
```powershell
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).
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.
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
```
> [!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).
4. Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
```powershell
Set-RuleOption -FilePath $LamnaServerPolicy -Option 6 -Delete
```
5. (Optional) Use [Set-CIPolicyIdInfo](/powershell/module/configci/set-cipolicyidinfo) to reset the policy ID and change the policy name.
6. (Optional) Use [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion) to change the policy VersionEx.
> [!IMPORTANT]
> When updating a signed policy, the VersionEx of the updated policy must be greater than or equal to the current policy. Replacing a signed policy with a lower version will lead to boot failure.
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the policy to binary format:
```powershell
$PolicyID= Set-CIPolicyIdInfo -FilePath $LamnaServerPolicy -ResetPolicyID
$PolicyID = $PolicyID.Substring(11)
$CIPolicyBin = $env:userprofile + "\Desktop\" + $PolicyID + ".cip"
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).
### 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).
2. Sign the WDAC policy by using SignTool.exe:
```powershell
<Path to signtool.exe> sign -v -n "ContosoSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin
```
> [!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.
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
You can use certutil.exe to verify the signed file. Review the output to confirm the signature algorithm and encoding for certificate fields, like 'subject common name' and 'issuer common name' as described in the Warning at the top of this article.
```powershell
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).
> [!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.

2
windows/security/threat-protection/windows-defender-security-center/wdsc-hide-notifications.md
View File

@ -40,7 +40,7 @@ You can only use Group Policy to change these settings.
## Use Group Policy to hide non-critical notifications
You can hide notifications that describe regular events related to the health and security of the machine. These notifications are the ones that don't require an action from the machine's user. It can be useful to hide these notifications if you find they're too numerous or you have other status reporting on a larger scale (such as Update Compliance or Microsoft Configuration Manager reporting).
You can hide notifications that describe regular events related to the health and security of the machine. These notifications are the ones that don't require an action from the machine's user. It can be useful to hide these notifications if you find they're too numerous or you have other status reporting on a larger scale (such as Windows Update for Business reports or Microsoft Configuration Manager reporting).
These notifications can be hidden only by using Group Policy.