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

revert acronym changes

Browse Source
This commit is contained in:
Aaron Czechowski
2023-03-21 13:26:52 -07:00
parent 0a2d9c93f9
commit 84abdcd5a3
5 changed files with 40 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,6 +1,6 @@
---
title: Allow LOB Win32 apps on Intune-managed S Mode devices
description: Using Windows Defender Application Control supplemental policies, you can expand the S Mode base policy on your Intune-managed devices.
description: Using Windows Defender Application Control (WDAC) supplemental policies, you can expand the S Mode base policy on your Intune-managed devices.
ms.prod: windows-client
ms.localizationpriority: medium
author: jsuther1974
@ -20,11 +20,11 @@ ms.topic: how-to
- Windows 11
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
You can use Microsoft Intune to deploy and run critical Win32 applications and Windows components that are normally blocked in S mode on their Intune-managed Windows in S mode devices. For example, PowerShell.exe.
With Intune, you can configure managed S mode devices using an Application Control supplemental policy that expands the S mode base policy to authorize the apps your organization uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
With Intune, you can configure managed S mode devices using a Windows Defender Application Control supplemental policy that expands the S mode base policy to authorize the apps your organization uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is verified by Microsoft or your organization".
For an overview and brief demo of this feature, see this video:
@ -36,7 +36,7 @@ For an overview and brief demo of this feature, see this video:
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device groups. Because you need access to PowerShell cmdlets to generate your supplemental policy, you should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune, before deploying the policy more broadly, assign it to a single test S-mode device to verify expected functioning.
1. Generate a supplemental policy with Application Control tooling.
1. Generate a supplemental policy with Windows Defender Application Control tooling.
This policy expands the S mode base policy to authorize more applications. Anything authorized by either the S mode base policy or your supplemental policy is allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
@ -162,7 +162,7 @@ The following policy is a sample that allows kernel debuggers, PowerShell ISE, a
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="Example Name">
<ProductSigners>
<AllowedSigners>
<AllowedSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
<AllowedSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
</AllowedSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_CBD_0" />

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

@ -1,6 +1,6 @@
---
title: Deploy catalog files to support Windows Defender Application Control
description: Catalog files simplify running unsigned applications in the presence of a Windows Defender Application Control policy.
description: Catalog files simplify running unsigned applications in the presence of a Windows Defender Application Control (WDAC) policy.
ms.prod: windows-client
ms.localizationpriority: medium
ms.topic: how-to
@ -23,11 +23,11 @@ ms.technology: itpro-security
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
*Catalog files* can be important in your deployment of Windows Defender Application Control 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 Application Control-managed environment. And, you can create catalog files for existing apps without requiring access to the original source code or needing any expensive repackaging.
*Catalog files* can be important in your deployment of Windows Defender Application Control (WDAC) if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. You can also use catalog files to add your own signature to apps you get from independent software vendors (ISV) when you don't want to trust all code signed by that ISV. In this way, catalog files provide a convenient way for you to "bless" apps for use in your WDAC-managed environment. And, you can create catalog files for existing apps without requiring access to the original source code or needing any expensive repackaging.
You need to [obtain a code signing certificate for your own use](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md#obtain-code-signing-certificates-for-your-own-use) and use it to sign the catalog file. Then, distribute the signed catalog file using your preferred content deployment mechanism.
Finally, add a signer rule to your Application Control policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build an Application Control policy that blocks all unsigned code, because most malware is unsigned.
Finally, add a signer rule to your WDAC policy for your signing certificate. Then, any apps covered by your signed catalog files are able to run, even if the apps were previously unsigned. With this foundation, you can more easily build a WDAC policy that blocks all unsigned code, because most malware is unsigned.
## Create catalog files using Package Inspector
@ -46,7 +46,7 @@ To create a catalog file for an existing app, you can use a tool called **Packag
$PolicyBinary = $env:USERPROFILE+"\Desktop\"+$PolicyId.substring(11)+".cip"
```
Then apply the policy as described in [Deploy Application Control policies with script](deployment/deploy-wdac-policies-with-script.md).
Then apply the policy as described in [Deploy Windows Defender Application Control policies with script](deployment/deploy-wdac-policies-with-script.md).
2. Start Package Inspector to monitor file creation on a **local drive** where you install the app, for example, drive C:
@ -142,7 +142,7 @@ The following process walks you through the deployment of a signed catalog file
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 Application Control policies.
> 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)
@ -311,9 +311,9 @@ At the time of the next software inventory cycle, when the targeted clients rece
> [!NOTE]
> If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
## Allow apps signed by your catalog signing certificate in your Application Control policy
## Allow apps signed by your catalog signing certificate in your WDAC policy
Now that you have your signed catalog file, you can add a signer rule to your Application Control policy that allows anything signed with that certificate. If you haven't yet created an Application Control policy, see the [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 policy that allows anything signed with that certificate. If you haven't yet created a WDAC policy, see the [Windows Defender Application Control design guide](windows-defender-application-control-design-guide.md).
On a computer where the signed catalog file has been deployed, you can use [New-CiPolicyRule](/powershell/module/configci/new-cipolicyrule) to create a signer rule from any file included in that catalog. Then use [Merge-CiPolicy](/powershell/module/configci/merge-cipolicy) to add the rule to your policy XML. Be sure to replace the path values in the following sample:

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

@ -1,6 +1,6 @@
---
title: Example Windows Defender Application Control base policies
description: When creating a Windows Defender Application Control policy for an organization, start from one of the many available example base policies.
description: When creating a Windows Defender Application Control (WDAC) policy for an organization, start from one of the many available example base policies.
ms.topic: reference
ms.prod: windows-client
ms.localizationpriority: medium
@ -23,21 +23,21 @@ ms.technology: itpro-security
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
When you create policies for use with Windows Defender Application Control, start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that you can use.
When you create policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that you can use.
| **Example Base Policy** | **Description** | **Where it can be found** |
|-------------------------|---------------------------------------------------------------|--------|
| **DefaultWindows_\*.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for the [Microsoft Intune product family](https://www.microsoft.com/security/business/endpoint-management/microsoft-intune) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_\*.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\DefaultWindows_Audit.xml |
| **AllowMicrosoft.xml** | This example policy includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowMicrosoft.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\AllowMicrosoft.xml |
| **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity) using Application Control. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml |
| **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](https://support.microsoft.com/windows/core-isolation-e30ed737-17d8-42f3-a2a9-87521df09b78) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll_EnableHVCI.xml |
| **DenyAllAudit.xml** | ***Warning: May cause long boot time on Windows Server 2019.*** Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DenyAllAudit.xml |
| **Microsoft Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in Application Control integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise Application Control policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy)). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\SignedReputable.xml |
| **Microsoft Configuration Manager** | Customers who use Configuration Manager can deploy a policy with Configuration Manager's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
| **SmartAppControl.xml** | This example policy includes rules based on [Smart App Control](https://support.microsoft.com/topic/what-is-smart-app-control-285ea03d-fa88-4d56-882e-6698afdb7003) that are well-suited for lightly managed systems. This policy includes a rule that is unsupported for enterprise WDAC policies and must be removed. For more information about using this example policy, see [Create a custom base policy using an example base policy](create-wdac-policy-for-lightly-managed-devices.md#create-a-custom-base-policy-using-an-example-wdac-base-policy). | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\SmartAppControl.xml <br>%ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\SignedReputable.xml |
| **Example supplemental policy** | This example policy shows how to use supplemental policy to expand the DefaultWindows_Audit.xml allow a single Microsoft-signed file. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Supplemental.xml |
| **Microsoft Recommended Block List** | This policy includes a list of Windows and Microsoft-signed code that Microsoft recommends blocking when using Application Control, if possible. | [Microsoft recommended block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_UserMode_Blocklist.xml |
| **Microsoft Recommended Block List** | This policy includes a list of Windows and Microsoft-signed code that Microsoft recommends blocking when using WDAC, if possible. | [Microsoft recommended block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules) <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_UserMode_Blocklist.xml |
| **Microsoft recommended driver blocklist** | This policy includes rules to block known vulnerable or malicious kernel drivers. | [Microsoft recommended driver block rules](/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules) <br> %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies\RecommendedDriverBlock_Enforced.xml <br> %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\Recommended_Driver_Blocklist.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/en-us/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows S mode** | This policy includes the rules used to enforce [Windows S mode](https://support.microsoft.com/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85). | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSiPolicy.xml.xml |
| **Windows 11 SE** | This policy includes the rules used to enforce [Windows 11 SE](/education/windows/windows-11-se-overview), a version of Windows built for use in schools. | %ProgramFiles%\WindowsApps\Microsoft.WDAC.WDACWizard*\WinSEPolicy.xml.xml |
> [!NOTE]

14
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 for added control and protection with Application Control
description: Code signing can be used to better control Win32 app authorization and add protection for your Windows Defender Application Control policies.
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 Windows Defender Application Control (WDAC) policies.
ms.prod: windows-client
ms.localizationpriority: medium
ms.topic: conceptual
@ -12,7 +12,7 @@ ms.date: 11/29/2022
ms.technology: itpro-security
---
# Use code signing for added control and protection with Application Control
# Use code signing for added control and protection with Windows Defender Application Control
**Applies to:**
@ -25,7 +25,7 @@ ms.technology: itpro-security
## What is code signing and why is it important?
Code signing provides some important benefits to application security features like Windows Defender Application Control. First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Code signing provides some important benefits to application security features like Windows Defender Application Control (WDAC). First, it allows the system to cryptographically verify that a file hasn't been tampered with since it was signed and before any code is allowed to run. Second, it associates the file with a real-world identity, such as a company or an individual developer. This identity can make your policy trust decisions easier and allows for real-world consequences when code signing is abused or used maliciously. Although Windows doesn't require software developers to digitally sign their code, most major independent software vendors (ISV) do use code signing for much of their code. And metadata that a developer includes in a file's resource header (.RSRC), such as OriginalFileName or ProductName, can be combined with the file's signing certificate to limit the scope of trust decisions. For example, instead of allowing everything signed by Microsoft, you can choose to allow only files signed by Microsoft where ProductName is "Microsoft Teams". Then use other rules to authorize any other files that need to run.
Wherever possible, you should require all app binaries and scripts are code signed as part of your app acceptance criteria. And, you should ensure that internal line-of-business (LOB) app developers have access to code signing certificates controlled by your organization.
@ -40,11 +40,11 @@ You can use catalog files to easily add a signature to an existing application w
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).
## Signed Application Control policies
## Signed WDAC policies
While an Application Control policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by Application Control and help protect against tampering or removal of a policy even by an admin user.
While a WDAC policy begins as an XML document, it's then converted into a binary-encoded file before deployment. This binary version of your policy can be code signed like any other application binary, offering many of the same benefits as described above for signed code. Additionally, signed policies are treated specially by WDAC and help protect against tampering or removal of a policy even by an admin user.
For more information on using signed policies, see [Use signed policies to protect Application Control against tampering](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering)
For more information on using signed policies, see [Use signed policies to protect Windows Defender Application Control against tampering](/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering)
## Obtain code signing certificates for your own use

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

@ -1,6 +1,6 @@
---
title: Use signed policies to protect Windows Defender Application Control against tampering
description: Signed Windows Defender Application Control policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
description: Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows 10 and Windows 11.
ms.prod: windows-client
ms.localizationpriority: medium
ms.topic: conceptual
@ -23,9 +23,9 @@ ms.technology: itpro-security
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. For more information, see [Windows Defender Application Control feature availability](feature-availability.md).
Signed Windows Defender Application Control policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen. With this goal in mind, it's much more difficult to remove signed Application Control policies. SecureBoot must be enabled in order to provide this protection for signed Application Control policies.
Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of protection available in Windows. These policies are designed to detect administrative tampering of the policy, such as by malware running as admin, and will result in a boot failure or blue screen. With this goal in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to provide this protection for signed WDAC policies.
If you don't currently have a code signing certificate you can use to sign your Application Control policies, see [Obtain code signing certificates for your own use](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md#obtain-code-signing-certificates-for-your-own-use).
If you don't currently have a code signing certificate you can use to sign your policies, see [Obtain code signing certificates for your own use](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md#obtain-code-signing-certificates-for-your-own-use).
> [!WARNING]
> Boot failure, or blue screen, may occur if your signing certificate doesn't follow these rules:
@ -35,12 +35,12 @@ If you don't currently have a code signing certificate you can use to sign your
> - You can use SHA-256, SHA-384, or SHA-512 as the digest algorithm on Windows 11, as well as Windows 10 and Windows Server 2019 and above after applying the November 2022 cumulative security update. All other devices only support SHA-256.
> - Don't use UTF-8 encoding for certificate fields, like 'subject common name' and 'issuer common name'. These strings must be encoded as PRINTABLE_STRING, IA5STRING or BMPSTRING.
Before you attempt to deploy signed Application Control policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
Before you attempt to deploy a signed policy, you should first deploy an unsigned version of the policy to uncover any issues with the policy rules. We also recommend you enable rule options **9 - Enabled:Advanced Boot Options Menu** and **10 - Enabled:Boot Audit on Failure** to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
> [!NOTE]
> When signing a Base policy that has existing Supplemental policies, you must also switch to signed policy for all of the Supplementals. Authorize the signed supplemental policies by adding a `<SupplementalPolicySigner>` rule to the Base policy.
## Prepare your Application Control policy for signing
## Prepare your WDAC policy for signing
1. Open an elevated Windows PowerShell session and initialize the variables to use:
@ -51,7 +51,7 @@ Before you attempt to deploy signed Application Control policy, you should first
```
> [!NOTE]
> This example uses an enforced version of the Application Control policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
> This example uses an enforced version of the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) article. If you sign another policy, be sure to update the **$PolicyPath** and **$PolicyName** variables with the correct information.
2. Navigate to your desktop as the working directory:
@ -59,7 +59,7 @@ Before you attempt to deploy signed Application Control policy, you should first
cd $PolicyPath
```
3. If your Application Control policy doesn't already include an `<UpdatePolicySigner>` rule for your policy signing certificate, you must add it. At least one `<UpdatePolicySigner>` rule must exist to convert your policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy).
3. If your WDAC policy doesn't already include an `<UpdatePolicySigner>` rule for your policy signing certificate, you must add it. At least one `<UpdatePolicySigner>` rule must exist to convert your policy XML with [ConvertFrom-CiPolicy](/powershell/module/configci/convertfrom-cipolicy).
Use [Add-SignerRule](/powershell/module/configci/add-signerrule) and create an `<UpdatePolicySigner>` rule from your certificate file (.cer). If you purchased a code signing certificate or issued one from your own public key infrastructure (PKI), you can export the certificate file.
@ -71,7 +71,7 @@ Before you attempt to deploy signed Application Control policy, you should first
```
> [!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 Application Control policies causing boot failure, see [Remove Application Control policies causing boot stop failures](disable-windows-defender-application-control-policies.md#remove-wdac-policies-causing-boot-stop-failures).
> Failing to perform this step will leave you unable to modify or disable this policy and will lead to boot failure. For more information about how to disable signed policies causing boot failure, see [Remove Windows Defender Application Control policies causing boot stop failures](disable-windows-defender-application-control-policies.md#remove-wdac-policies-causing-boot-stop-failures).
4. Use [Set-RuleOption](/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
@ -99,11 +99,11 @@ Before you attempt to deploy signed Application Control policy, you should first
### 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 Application Control policy files:
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 Application Control policy by using SignTool.exe:
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
@ -112,7 +112,7 @@ If you purchased a code signing certificate or issued one from your own PKI, you
> [!NOTE]
> The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoSigningCert** is the subject name of the certificate that will be used to sign the 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 Application Control policy XML.
When complete, the commands should output a signed policy file with a `.p7` extension. You must rename the file to `{GUID}.cip` where "{GUID}" is the &lt;PolicyId&gt; from your original WDAC policy XML.
## Verify and deploy the signed policy
@ -122,9 +122,9 @@ You can use certutil.exe to verify the signed file. Review the output to confirm
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 Application Control policy to ensure you don't encounter a boot failure.
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 more information about deploying policies, see [Deploying Application Control policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
Once you've verified the signed policy, deploy it using your preferred deployment method. For more information about deploying policies, see [Deploying Windows Defender Application Control policies](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide).
> [!NOTE]
> Anti-tampering protection for signed Application Control policies takes effect after the first reboot once the signed policy is applied to a computer. This protection only applies to computers with UEFI Secure Boot enabled.
> Anti-tampering protection for signed policies takes effect after the first reboot once the signed policy is applied to a computer. This protection only applies to computers with UEFI Secure Boot enabled.