mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-21 13:23:36 +00:00
added applocker topics
This commit is contained in:
@ -0,0 +1,19 @@
|
||||
---
|
||||
title: Administering AppLocker by using Mobile Device Management (MDM) (Windows 10)
|
||||
description: This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy.
|
||||
ms.assetid: 6d0c99e7-0284-4547-a30a-0685a9916650
|
||||
ms.prod: w10
|
||||
ms.mktglfcycl: deploy
|
||||
ms.sitesec: library
|
||||
ms.pagetype: security
|
||||
author: brianlic-msft
|
||||
ms.date: 03/01/2018
|
||||
---
|
||||
|
||||
# Administering AppLocker by using Mobile Device Management (MDM)
|
||||
|
||||
**Applies to**
|
||||
- Windows 10
|
||||
- Windows Server
|
||||
|
||||
|
@ -20,11 +20,15 @@ This topic for IT professionals describes the steps required to modify an AppLoc
|
||||
|
||||
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
|
||||
|
||||
There are two methods you can use to edit an AppLocker policy:
|
||||
There are three methods you can use to edit an AppLocker policy:
|
||||
|
||||
- [Editing an AppLocker policy by using Mobile Device Management (MDM)](#bkmk-editapppolinmdm)
|
||||
- [Editing an AppLocker policy by using Group Policy](#bkmk-editapppolingpo)
|
||||
- [Editing an AppLocker policy by using the Local Security Policy snap-in](#bkmk-editapplolnotingpo)
|
||||
|
||||
## <a href="" id="bkmk-editapppolinmdm"></a>Editing an AppLocker policy by using Mobile Device Management (MDM)
|
||||
|
||||
|
||||
## <a href="" id="bkmk-editapppolingpo"></a>Editing an AppLocker policy by using Group Policy
|
||||
|
||||
The steps to edit an AppLocker policy distributed by Group Policy include the following:
|
||||
|
@ -27,21 +27,26 @@ Common AppLocker maintenance scenarios include:
|
||||
- An app appears to be allowed but should be blocked.
|
||||
- A single user or small subset of users needs to use a specific app that is blocked.
|
||||
|
||||
There are two methods you can use to maintain AppLocker policies:
|
||||
There are three methods you can use to maintain AppLocker policies:
|
||||
|
||||
- [Maintaining AppLocker policies by using Mobile Device Management (MDM)](#bkmk-applkr-use-mdm)
|
||||
- [Maintaining AppLocker policies by using Group Policy](#bkmk-applkr-use-gp)
|
||||
- [Maintaining AppLocker policies on the local computer](#bkmk-applkr-use-locsnapin)
|
||||
|
||||
## <a href="" id="bkmk-applkr-use-mdm"></a>Maintaining AppLocker policies by using Mobile Device Management (MDM)
|
||||
|
||||
|
||||
|
||||
## <a href="" id="bkmk-applkr-use-gp"></a>Maintaining AppLocker policies by using Group Policy
|
||||
|
||||
For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following tasks.
|
||||
|
||||
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
|
||||
|
||||
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
|
||||
versions of GPOs.
|
||||
|
||||
>**Caution:** You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
|
||||
|
||||
## <a href="" id="bkmk-applkr-use-gp"></a>Maintaining AppLocker policies by using Group Policy
|
||||
|
||||
For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following tasks.
|
||||
|
||||
### Step 1: Understand the current behavior of the policy
|
||||
|
||||
|
@ -16,3 +16,92 @@ ms.date: 02/28/2018
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
As you deploy Windows Defender Application Control (WDAC) (also part of Windows Defender Device Guard), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics 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.
|
||||
Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded.
|
||||
ECDSA is not supported.
|
||||
|
||||
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
|
||||
|
||||
2. When connected, right-click **Certificate Templates**, and then click **Manage** to open the Certification Templates Console.
|
||||
|
||||

|
||||
|
||||
Figure 1. Manage the certificate templates
|
||||
|
||||
3. In the navigation pane, right-click the Code Signing certificate, and then click **Duplicate Template**.
|
||||
|
||||
4. On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
|
||||
|
||||
5. On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **WDAC Catalog Signing Certificate**.
|
||||
|
||||
6. On the **Request Handling** tab, select the **Allow private key to be exported** check box.
|
||||
|
||||
7. On the **Extensions** tab, select the **Basic Constraints** check box, and then click **Edit**.
|
||||
|
||||
8. In the **Edit Basic Constraints Extension** dialog box, select **Enable this extension**, as shown in Figure 2.
|
||||
|
||||

|
||||
|
||||
Figure 2. Select constraints on the new template
|
||||
|
||||
9. If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
|
||||
|
||||
10. On the **Subject Name** tab, select **Supply in the request**.
|
||||
|
||||
11. On the **Security** tab, verify that whatever account will be used to request the certificate has the right to enroll the certificate.
|
||||
|
||||
12. Click **OK** to create the template, and then close the Certificate Template Console.
|
||||
|
||||
When this certificate template has been created, you must publish it to the CA published template store. To do so, complete the following steps:
|
||||
|
||||
1. In the Certification Authority MMC snap-in, right-click **Certification Templates**, point to **New**, and then click **Certificate Template to Issue**, as shown in Figure 3.
|
||||
|
||||

|
||||
|
||||
Figure 3. Select the new certificate template to issue
|
||||
|
||||
A list of available templates to issue appears, including the template you just created.
|
||||
|
||||
2. Select the WDAC Catalog signing certificate, and then click **OK**.
|
||||
|
||||
Now that the template is available to be issued, you must request one from the computer running Windows 10 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, click **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
|
||||
|
||||
2. In the Certificates snap-in, right-click the Personal store folder, point to **All Tasks**, and then click **Request New Certificate**.
|
||||
|
||||
3. Click **Next** twice to get to the certificate selection list.
|
||||
|
||||
4. In the **Request Certificate** list, select your newly created code signing certificate, and then select the blue text that requests additional information, as shown in Figure 4.
|
||||
|
||||

|
||||
|
||||
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 click **Add**. When added, click **OK.**
|
||||
|
||||
6. Enroll and finish.
|
||||
|
||||
> **Note** If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
|
||||
|
||||
This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
|
||||
|
||||
1. Right-click the certificate, point to **All Tasks**, and then click **Export**.
|
||||
|
||||
2. Click **Next**, and then select **Yes, export the private key**.
|
||||
|
||||
3. Choose the default settings, and then select **Export all extended properties**.
|
||||
|
||||
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)
|
||||
|
||||
|
@ -17,3 +17,34 @@ ms.date: 02/27/2018
|
||||
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with Windows Defender Application Control (WDAC) as part of your overall application control strategy.
|
||||
|
||||
## Understanding Packaged apps and Packaged app installers
|
||||
|
||||
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
|
||||
With packaged apps, it is possible to control the entire app by using a single WDAC rule.
|
||||
|
||||
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the software’s publisher name, product name, and product version. Therefore, WDAC controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
|
||||
|
||||
### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows apps and packaged apps
|
||||
|
||||
WDAC policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
|
||||
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
|
||||
|
||||
- **Installing the apps** All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
|
||||
- **Changing the system state** Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your WDAC policies, it is important to understand whether an app that you are allowing can make system-wide changes.
|
||||
- **Acquiring the apps** Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
|
||||
|
||||
WDAC uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
|
||||
|
||||
## Using WDAC to manage packaged apps
|
||||
|
||||
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
|
||||
|
||||
1. Gather information about which Packaged apps are running in your environment.
|
||||
|
||||
2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy WDAC policy rules and file rules](select-types-of-rules-to-create.md).
|
||||
|
||||
3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
|
||||
|
||||
|
@ -18,8 +18,6 @@ ms.date: 02/27/2018
|
||||
- Windows 10
|
||||
- Windows Server 2016
|
||||
|
||||
# Use a Windows Defender Application Control policy to control specific plug-ins, add-ins, and modules
|
||||
|
||||
As of Windows 10, version 1703, you can use WDAC policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
|
||||
|
||||
| Approach (as of Windows 10, version 1703) | Guideline |
|
||||
|
Reference in New Issue
Block a user