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

fixing spacing issues

Browse Source
This commit is contained in:
Brian Lich
2016-05-24 11:31:22 -07:00
parent a75ee08f72
commit fe3a71b6eb
21 changed files with 840 additions and 538 deletions
Download Patch File Download Diff File Expand all files Collapse all files

53
windows/keep-secure/edit-an-applocker-policy.md
View File

@ -2,70 +2,99 @@
title: Edit an AppLocker policy (Windows 10)
description: This topic for IT professionals describes the steps required to modify an AppLocker policy.
ms.assetid: dbc72d1f-3fe0-46c2-aeeb-96621fce7637
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Edit an AppLocker policy
**Applies to**
- Windows 10
This topic for IT professionals describes the steps required to modify an AppLocker policy.
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:
- [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-editapppolingpo"></a>Editing an AppLocker policy by using Group Policy
The steps to edit an AppLocker policy distributed by Group Policy include the following:
### Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker
policy to an XML file. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
### Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy maintenance
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
**Caution**  
Importing a policy onto another PC will overwrite the existing policy on that PC.
>**Caution:**  Importing a policy onto another PC will overwrite the existing policy on that PC.
 
### Step 3: Use AppLocker to modify and test the rule
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
- For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
- For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
**Caution**  
You should never edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed run, making changes to a live policy can create unexpected behavior. For info about testing policies, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
>**Caution:**  You should never edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed run, making changes to a live policy can create unexpected behavior. For info about testing policies, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
 
**Note**  
If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the GPO before exporting the policy.
>**Note:**  If you are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the GPO before exporting the policy.
 
## <a href="" id="bkmk-editapplolnotingpo"></a>Editing an AppLocker policy by using the Local Security Policy snap-in
The steps to edit an AppLocker policy distributed by using the Local Security Policy snap-in (secpol.msc) include the following tasks.
### Step 1: Import the AppLocker policy
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in (secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
**Caution**  
Importing a policy onto another PC will overwrite the existing policy on that PC.
>**Caution:**  Importing a policy onto another PC will overwrite the existing policy on that PC.
 
### Step 2: Identify and modify the rule to change, delete, or add
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
### Step 3: Test the effect of the policy
For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 4: Export the policy to an XML file and propagate it to all targeted computers
For procedures to export the updated policy from the reference computer to targeted computers, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Additional resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
 
 

19
windows/keep-secure/edit-applocker-rules.md
View File

@ -2,42 +2,55 @@
title: Edit AppLocker rules (Windows 10)
description: This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.
ms.assetid: 80016cda-b915-46a0-83c6-5e6b0b958e32
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Edit AppLocker rules
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.
For more info about these rule types, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
**To edit a publisher rule**
1. Open the AppLocker console, and then click the appropriate rule collection.
2. In the **Action** pane, right-click the publisher rule, and then click **Properties**.
3. Click the appropriate tab to edit the rule properties.
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group for which this rule should apply.
- Click the **Publisher** tab to configure the certificate's common name, the product name, the file name, or file version of the publisher.
- Click the **Exceptions** tab to create or edit exceptions.
- When you finish updating the rule, click **OK**.
**To edit a file hash rule**
1. Open the AppLocker console, and then click the appropriate rule collection.
2. Choose the appropriate rule collection.
3. In the **Action** pane, right-click the file hash rule, and then click **Properties**.
4. Click the appropriate tab to edit the rule properties.
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group in which this rule should apply.
- Click the **File Hash** tab to configure the files that should be used to enforce the rule. You can click **Browse Files** to add a specific file or click **Browse Folders** to add all files in a specified folder. To remove hashes individually, click **Remove**.
- When you finish updating the rule, click **OK**.
**To edit a path rule**
1. Open the AppLocker console, and then click the appropriate rule collection.
2. Choose the appropriate rule collection.
3. In the **Action** pane, right-click the path rule, and then click **Properties**.
4. Click the appropriate tab to edit the rule properties.
- Click the **General** tab to change the rule name, add a rule description, configure whether the rule is used to allow or deny applications, and set the security group in which this rule should apply.
- Click the **Path** tab to configure the path on the computer in which the rule should be enforced.
- Click the **Exceptions** tab to create exceptions for specific files in a folder.
- When you finish updating the rule, click **OK**.
 
 

94
windows/keep-secure/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
View File

@ -2,95 +2,99 @@
title: Enable computer and user accounts to be trusted for delegation (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enable computer and user accounts to be trusted for delegation security policy setting.
ms.assetid: 524062d4-1595-41f3-8ce1-9c85fd21497b
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Enable computer and user accounts to be trusted for delegation
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Enable computer and user accounts to be trusted for delegation** security policy setting.
## Reference
This policy setting determines which users can set the **Trusted for Delegation** setting on a user or computer object.
Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation.
Only administrators who have the **Enable computer and user accounts to be trusted for delegation** credential can set up delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to be trusted for delegation depends on the functionality level of the domain.
The user or machine object that is granted this right must have write access to the account control flags. A server process running on a device (or under a user context) that is trusted for delegation can access resources on another computer by using the delegated credentials of a client. However, the client account must have Write access to the account control flags on the object.
Constant: SeEnableDelegationPrivilege
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
- There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone devices.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not defined|
| Domain Controller Effective Default Settings | Administrators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## Policy management
This section describes features, tools and guidance to help you manage this policy.
Modifying this setting might affect compatibility with clients, services, and applications.
A restart of the device is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Misuse of the **Enable computer and user accounts to be trusted for delegation** user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain access to network resources and make it difficult to determine what has happened after a security incident.
Misuse of the **Enable computer and user accounts to be trusted for delegation** user right could allow unauthorized users to impersonate other users on the network. An attacker could exploit this privilege to gain access to network resources and make it difficult to determine what has happened
after a security incident.
### Countermeasure
The **Enable computer and user accounts to be trusted for delegation** user right should be assigned only if there is a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default.
**Note**  
There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone computers.
>**Note:**  There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone computers.
 
### Potential impact
None. Not defined is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

19
windows/keep-secure/enable-the-dll-rule-collection.md
View File

@ -2,24 +2,29 @@
title: Enable the DLL rule collection (Windows 10)
description: This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
ms.assetid: 88ef9561-6eb2-491a-803a-b8cdbfebae27
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Enable the DLL rule collection
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
The DLL rule collection includes the .dll and .ocx file formats.
For info about these rules, see [DLL rules in AppLocker](dll-rules-in-applocker.md).
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer
AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
**To enable the DLL rule collection**
1. From the AppLocker console, right-click **AppLocker**, and then click **Properties.**
2. Click the **Advanced** tab, select the **Enable the DLL rule collection** check box, and then click **OK**.
**Important**  
Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used by any of the allowed apps.
 
 
 
>**Important:**  Before you enforce DLL rules, make sure that there are allow rules for each DLL that is used by any of the allowed apps.

43
windows/keep-secure/encrypted-hard-drive.md
View File

@ -2,66 +2,93 @@
title: Encrypted Hard Drive (Windows 10)
description: Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Encrypted Hard Drive
**Applies to**
- Windows 10
Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.
By offloading the cryptographic operations to hardware, Encrypted Hard Drives increase BitLocker performance and reduce CPU usage and power consumption. Because Encrypted Hard Drives encrypt data quickly, enterprise devices can expand BitLocker deployment with minimal impact on productivity.
Encrypted Hard Drives are a new class of hard drives that are self-encrypting at a hardware level and allow for full disk hardware encryption. In Windows 8, Windows Server 2012, and later you can install to these devices without additional modification.
Some of the benefits of Encrypted Hard Drives include:
- **Better performance**: Encryption hardware, integrated into the drive controller, allows the drive to operate at full data rate with no performance degradation.
- **Strong security based in hardware**: Encryption is always "on" and the keys for encryption never leave the hard drive. User authentication is performed by the drive before it will unlock, independently of the operating system
- **Ease of use**: Encryption is transparent to the user because it is on by default. There is no user interaction needed to enable encryption. Encrypted Hard Drives are easily erased using on-board encryption key; there is no need to re-encrypt data on the drive.
- **Lower cost of ownership**: There is no need for new infrastructure to manage encryption keys, since BitLocker leverages your Active Directory Domain Services infrastructure to store recovery information. Your device operates more efficiently because processor cycles do not need to be used for the encryption process.
Encrypted Hard Drives are supported natively in the operating system through the following mechanisms:
- **Identification**: The operating system can identify that the drive is an Encrypted Hard Drive device type
- **Activation**: The operating system disk management utility can activate, create and map volumes to ranges/bands as appropriate
- **Configuration**: The operating system can create and map volumes to ranges/bands as appropriate
- **API**: API support for applications to manage Encrypted Hard Drives independently of BitLocker Drive Encryption (BDE)
- **BitLocker support**: Integration with the BitLocker Control Panel provides a seamless BitLocker end user experience.
**Warning**  
Self-Encrypting Hard Drives and Encrypted Hard Drives for Windows are not the same type of device. Encrypted Hard Drives for Windows require compliance for specific TCG protocols as well as IEEE 1667 compliance; Self-Encrypting Hard Drives do not have these requirements. It is important to confirm the device type is an Encrypted Hard Drive for Windows when planning for deployment.
>**Warning:**  Self-Encrypting Hard Drives and Encrypted Hard Drives for Windows are not the same type of device. Encrypted Hard Drives for Windows require compliance for specific TCG protocols as well as IEEE 1667 compliance; Self-Encrypting Hard Drives do not have these requirements. It is important to confirm the device type is an Encrypted Hard Drive for Windows when planning for deployment.
 
If you are a storage device vendor who is looking for more info on how to implement Encrypted Hard Drive, see the [Encrypted Hard Drive Device Guide](http://msdn.microsoft.com/library/windows/hardware/dn653989.aspx).
## System Requirements
To use Encrypted Hard Drive, the following system requirements apply:
For Encrypted Hard Drives used as **data drives**:
- The drive must be in an uninitialized state.
- The drive must be in a security inactive state.
For Encrypted Hard Drives used as **startup drives**:
- The drive must be in an uninitialized state.
- The drive must be in a security inactive state.
- The computer must be UEFI 2.3.1 based and have the EFI\_STORAGE\_SECURITY\_COMMAND\_PROTOCOL defined. (This protocol is used to allow programs running in the EFI boot services environment to send security protocol commands to the drive).
- The computer must have the Compatibility Support Module (CSM) disabled in UEFI.
- The computer must always boot natively from UEFI.
**Warning**  
All Encrypted Hard Drives must be attached to non-RAID controllers to function properly.
>**Warning:**  All Encrypted Hard Drives must be attached to non-RAID controllers to function properly.
 
## Technical overview
Rapid encryption in BitLocker directly addresses the security needs of enterprises while offering significantly improved performance. In versions of Windows earlier than Windows Server 2012, BitLocker required a two-step process to complete read/write requests. In Windows Server 2012, Windows 8, or later, Encrypted Hard Drives offload the cryptographic operations to the drive controller for much greater efficiency. When the operating system an Encrypted Hard Drive, it activates the security mode. This activation lets the drive controller generate a media key for every volume that the host computer creates. This media key, which is never exposed outside the disk, is used to rapidly encrypt or decrypt every byte of data that is sent or received from the disk.
## Configuring Encrypted Hard Drives as Startup drives
Configuration of Encrypted Hard Drives as startup drives is done using the same methods as standard hard drives. These methods include:
- **Deploy from media**: Configuration of Encrypted Hard Drives happens automatically through the installation process.
- **Deploy from network**: This deployment method involves booting a Windows PE environment and using imaging tools to apply a Windows image from a network share. Using this method, the Enhanced Storage optional component needs to be included in the Windows PE image. You can enable this component using Server Manager, Windows PowerShell, or the DISM command line tool. If this component is not present, configuration of Encrypted Hard Drives will not work.
- **Deploy from server**: This deployment method involves PXE booting a client with Encrypted Hard Drives present. Configuration of Encrypted Hard Drives happens automatically in this environment when the Enhanced Storage component is added to the PXE boot image. During deployment, the [TCGSecurityActivationDisabled](http://msdn.microsoft.com/library/windows/hardware/dn923247.aspx) setting in unattend.xml controls the encryption behavior of Encrypted Hard Drives.
- **Disk Duplication**: This deployment method involves use of a previously configured device and disk duplication tools to apply a Windows image to an Encrypted Hard Drive. Disks must be partitioned using at least Windows 8 or Windows Server 2012 for this configuration to work. Images made using disk duplicators will not work.
### Encrypted Hard Drive Architecture
Encrypted Hard Drives utilize two encryption keys on the device to control the locking and unlocking of data on the drive. These are the Data Encryption Key (DEK) and the Authentication Key (AK).
The Data Encryption Key is the key used to encrypt all of the data on the drive. The drive generates the DEK and it never leaves the device. It is stored in an encrypted format at a random location on the drive. If the DEK is changed or erased, data encrypted using the DEK is irrecoverable.
The Authentication Key is the key used to unlock data on the drive. A hash of the key is stored on drive and requires confirmation to decrypt the DEK.
When a computer with an Encrypted Hard Drive is in a powered off state, the drive locks automatically. As a computer powers on, the device remains in a locked state and is only unlocked after the Authentication Key decrypts the Data Encryption Key. Once the Authentication Key decrypts the Data Encryption Key, read-write operations can take place on the device.
When a computer with an Encrypted Hard Drive is in a powered off state, the drive locks automatically. As a computer powers on, the device remains in a locked state and is only unlocked after the Authentication Key decrypts the Data Encryption Key. Once the Authentication Key decrypts the Data
Encryption Key, read-write operations can take place on the device.
When writing data to the drive, it passes through an encryption engine before the write operation completes. Likewise, reading data from the drive requires the encryption engine to decrypt the data before passing that data back to the user. In the event that the DEK needs to be changed or erased, the data on the drive does not need to be re-encrypted. A new Authentication Key needs to be created and it will re-encrypt the DEK. Once completed, the DEK can now be unlocked using the new AK and read-writes to the volume can continue.
## Re-configuring Encrypted Hard Drives
Many Encrypted Hard Drive devices come pre-configured for use. If reconfiguration of the drive is required, use the following procedure after removing all available volumes and reverting the drive to an uninitialized state:
1. Open Disk Management (diskmgmt.msc)
2. Initialize the disk and select the appropriate partition style (MBR or GPT)
3. Create one or more volumes on the disk.
4. Use the BitLocker setup wizard to enable BitLocker on the volume.
 
 

13
windows/keep-secure/enforce-applocker-rules.md
View File

@ -2,22 +2,29 @@
title: Enforce AppLocker rules (Windows 10)
description: This topic for IT professionals describes how to enforce application control rules by using AppLocker.
ms.assetid: e1528b7b-77f2-4419-8e27-c9cc3721d96d
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Enforce AppLocker rules
**Applies to**
- Windows 10
This topic for IT professionals describes how to enforce application control rules by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to **Enforce rules** or **Audit only** on the rule collection.
When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of these rules first before deploying them to production.
To enforce AppLocker rules by configuring an AppLocker policy to **Enforce rules**, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
**Caution**  
AppLocker rules will be enforced immediately on the local device or when the Group Policy object (GPO) is updated by performing this procedure. If you want to see the effect of applying an AppLocker policy before setting the enforcement setting to **Enforce rules**, configure the policy to **Audit only**. For info about how to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)or [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
>**Caution:**  AppLocker rules will be enforced immediately on the local device or when the Group Policy object (GPO) is updated by performing this procedure. If you want to see the effect of applying an AppLocker policy before setting the enforcement setting to **Enforce rules**, configure the policy to **Audit only**. For info about how to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)or [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
 
 
 

85
windows/keep-secure/enforce-password-history.md
View File

@ -2,88 +2,85 @@
title: Enforce password history (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enforce password history security policy setting.
ms.assetid: 8b2ab871-3e52-4dd1-9776-68bb1e935442
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Enforce password history
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Enforce password history** security policy setting.
## Reference
The **Enforce password history** policy setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused.
Password reuse is an important concern in any organization. Many users want to reuse the same password for their account over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but they can reuse an old password, the effectiveness of a good password policy is greatly reduced.
Specifying a low number for **Enforce password history** allows users to continually use the same small number of passwords repeatedly. If you do not also set [Minimum password age](minimum-password-age.md), users can change their password as many times in a row as necessary to reuse their original password.
### Possible values
- User-specified number from 0 through 24
- Not defined
### Best practices
- Set **Enforce password history** to 24. This will help mitigate vulnerabilities that are caused by password reuse.
- Set [Maximum password age](maximum-password-age.md) to expire passwords between 60 and 90 days. Try to expire the passwords between major business cycles to prevent work loss.
- Configure [Minimum password age](minimum-password-age.md) so that you do not allow passwords to be changed immediately.
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default domain policy</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>0 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>24 passwords remembered</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default domain policy | 24 passwords remembered|
| Default domain controller policy | Not defined|
| Stand-alone server default settings | 0 passwords remembered|
| Domain controller effective default settings | 24 passwords remembered|
| Member server effective default settings | 24 passwords remembered|
| Effective GPO default settings on client computers | 24 passwords remembered|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If you do not also configure the [Minimum password age](minimum-password-age.md) policy setting, users might repeatedly change their passwords until they can reuse their original password.
**Note**  
After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised.
>**Note:**  After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised.
 
### Countermeasure
Configure the **Enforce password history** policy setting to 24 (the maximum setting) to help minimize the number of vulnerabilities that are caused by password reuse.
For this policy setting to be effective, you should also configure effective values for the [Minimum password age](minimum-password-age.md) and [Maximum password age](maximum-password-age.md) policy settings.
### Potential impact
The major impact of configuring the **Enforce password history** setting to 24 is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization, but this makes them easier for an attacker to guess. Also, an excessively low value for the [Maximum password age](maximum-password-age.md) policy setting is likely to increase administrative overhead because users who forget their passwords might ask the Help Desk to reset them frequently.
## Related topics
[Password Policy](password-policy.md)
 
 
- [Password Policy](password-policy.md)

86
windows/keep-secure/enforce-user-logon-restrictions.md
View File

@ -2,88 +2,88 @@
title: Enforce user logon restrictions (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Enforce user logon restrictions security policy setting.
ms.assetid: 5891cb73-f1ec-48b9-b703-39249e48a29f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Enforce user logon restrictions
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting.
## Reference
The **Enforce user logon restrictions** policy setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validating each request for a session ticket is optional because the extra step takes time, and that can slow network access to services.
The possible values for this Group Policy setting are:
- Enabled
- Disabled
- Not defined
### Best practices
- If this policy setting is disabled, users might be granted session tickets for services that they do not have the right to use.
It is advisable to set **Enforce user logon restrictions** to Enabled.
We recommend to set **Enforce user logon restrictions** to Enabled.
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**
### Default Values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy | Enabled|
| Default Domain Controller Policy | Not defined |
| Stand-Alone Server Default Settings| Not applicable |
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the device is not required for this policy setting to be effective.
### Group Policy
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
If you disable this policy setting, users could receive session tickets for services that they no longer have the right to use because the right was removed after they logged on.
### Countermeasure
Enable the **Enforce user logon restrictions** setting.
### Potential impact
None. This is the default configuration.
## Related topics
[Kerberos Policy](kerberos-policy.md)
 
 
- [Kerberos Policy](kerberos-policy.md)

9
windows/keep-secure/export-an-applocker-policy-to-an-xml-file.md
View File

@ -2,20 +2,23 @@
title: Export an AppLocker policy to an XML file (Windows 10)
description: This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.
ms.assetid: 979bd23f-6815-478b-a6a4-a25239cb1080
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Export an AppLocker policy to an XML file
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or testing.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To export an AppLocker policy to an XML file**
1. From the AppLocker console, right-click **AppLocker**, and then click **Export Policy**.
2. Browse to the location where you want to save the XML file.
3. In the **File name** box, type a file name for the XML file, and then click **Save**.
 
 

13
windows/keep-secure/file-system-global-object-access-auditing.md
View File

@ -2,20 +2,25 @@
title: File System (Global Object Access Auditing) (Windows 10)
description: This topic for the IT professional describes the Advanced Security Audit policy setting, File System (Global Object Access Auditing), which enables you to configure a global system access control list (SACL) on the file system for an entire computer.
ms.assetid: 4f215d61-0e23-46e4-9e58-08511105d25b
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# File System (Global Object Access Auditing)
**Applies to**
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **File System (Global Object Access Auditing)**, which enables you to configure a global system access control list (SACL) on the file system for an entire computer.
If you select the **Configure security** check box on the policy’s property page, you can add a user or group to the global SACL. This enables you to define computer system access control lists (SACLs) per object type for the file system. The specified SACL is then automatically applied to every file system object type.
If both a file or folder SACL and a global SACL are configured on a computer, the effective SACL is derived by combining the file or folder SACL and the global SACL. This means that an audit event is generated if an activity matches either the file or folder SACL or the global SACL.
This policy setting must be used in combination with the **File System** security policy setting under Object Access. For more information, see [Audit File System](audit-file-system.md).
## Related topics
[Advanced security audit policy settings](advanced-security-audit-policy-settings.md)
 
 
- [Advanced security audit policy settings](advanced-security-audit-policy-settings.md)

89
windows/keep-secure/force-shutdown-from-a-remote-system.md
View File

@ -2,92 +2,93 @@
title: Force shutdown from a remote system (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Force shutdown from a remote system security policy setting.
ms.assetid: 63129243-31ea-42a4-a598-c7064f48a3df
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Force shutdown from a remote system
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Force shutdown from a remote system** security policy setting.
## Reference
This security setting determines which users are allowed to shut down a device from a remote location on the network. This allows members of the Administrators group or specific users to manage computers (for tasks such as a restart) from a remote location.
Constant: SeRemoteShutdownPrivilege
### Possible values
- User-defined list of accounts
- Administrators
### Best practices
- Explicitly restrict this user right to members of the Administrators group or other specifically assigned roles that require this capability, such as non-administrative operations staff.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Administrators and Server Operators on domain controllers and Administrators on stand-alone servers.
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Server Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Server Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Server Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>Server Operators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
This policy setting must be applied on the computer that is being accessed remotely.
### Group Policy
This user right is defined in the Default Domain Controller Group Policy Object (GPO) and in the local security policy of workstations and servers.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Any user who can shut down a device could cause a denial-of-service condition to occur. Therefore, this user right should be tightly restricted.
### Countermeasure
Restrict the **Force shutdown from a remote system** user right to members of the Administrators group or other specifically assigned roles that require this capability, such as non-administrative operations staff.
### Potential impact
On a domain controller, if you remove the **Force shutdown from a remote system** user right from the Server Operator group, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

91
windows/keep-secure/generate-security-audits.md
View File

@ -2,95 +2,92 @@
title: Generate security audits (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Generate security audits security policy setting.
ms.assetid: c0e1cd80-840e-4c74-917c-5c2349de885f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Generate security audits
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Generate security audits** security policy setting.
## Reference
This policy setting determines which accounts can be used by a process to generate audit records in the security event log. The Local Security Authority Subsystem Service (LSASS) writes events to the log. You can use the information in the security event log to trace unauthorized device access.
Constant: SeAuditPrivilege
### Possible values
- User-defined list of accounts
- Local Service
- Network Service
### Best practices
- Because the audit log can potentially be an attack vector if an account is compromised, ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, this setting is Local Service and Network Service on domain controllers and stand-alone servers.
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Local Service</p>
<p>Network Service</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Local Service<br/>Network Service|
| Stand-Alone Server Default Settings | Local Service<br/>Network Service|
| Domain Controller Effective Default Settings | Local Service<br/>Network Service|
| Member Server Effective Default Settings | Local Service<br/>Network Service|
| Client Computer Effective Default Settings | Local Service<br/>Network Service|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
Misuse of this user right can result in the generation of many auditing events, potentially hiding evidence of an attack or causing a denial-of-service (DoS) if the [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md) security policy setting is enabled.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
A malicious user could use accounts that can write to the Security log to fill that log with meaningless events. If the computer is configured to overwrite events as needed, malicious users could use this method to remove evidence of their unauthorized activities. If the computer is configured to shut down when it is unable to write to the Security log, and it is not configured to automatically back up the log files, this method could be used to create a DoS condition.
### Countermeasure
Ensure that only the Local Service and Network Service accounts have the **Generate security audits** user right assigned to them.
### Potential impact
None. Restricting the **Generate security audits** user right to the Local Service and Network Service accounts is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

16
windows/keep-secure/how-applocker-works-techref.md
View File

@ -2,37 +2,47 @@
title: How AppLocker works (Windows 10)
description: This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
ms.assetid: 24bb1d73-0ff5-4af7-8b8a-2fa44d4ddbcd
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# How AppLocker works
**Applies to**
- Windows 10
This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
- [AppLocker architecture and components](applocker-architecture-and-components.md)
- [AppLocker processes and interactions](applocker-processes-and-interactions.md)
The following topics explain how AppLocker rules and policies work:
- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
- [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
- [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
- [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
- [Executable rules in AppLocker](executable-rules-in-applocker.md)
- [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
- [Script rules in AppLocker](script-rules-in-applocker.md)
- [DLL rules in AppLocker](dll-rules-in-applocker.md)
- [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
## Additional resources
- [AppLocker Design Guide](applocker-policies-design-guide.md)
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)
- [Administer AppLocker](administer-applocker.md)
 
 

36
windows/keep-secure/how-to-configure-security-policy-settings.md
View File

@ -2,59 +2,77 @@
title: Configure security policy settings (Windows 10)
description: Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.
ms.assetid: 63b0967b-a9fe-4d92-90af-67469ee20320
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Configure security policy settings
**Applies to**
- Windows 10
Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.
You must have Administrators rights on the local device, or you must have the appropriate permissions to update a Group Policy Object (GPO) on the domain controller to perform these procedures.
When a local setting is inaccessible, it indicates that a GPO currently controls that setting.
## <a href="" id="bkmk-local"></a>To configure a setting using the Local Security Policy console
1. To open Local Security Policy, on the **Start** screen, type **secpol.msc**, and then press ENTER.
2. Under **Security Settings** of the console tree, do one of the following:
- Click **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**.
- Click **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
3. When you find the policy setting in the details pane, double-click the security policy that you want to modify.
4. Modify the security policy setting, and then click **OK**.
**Note**  
- Some security policy settings require that the device be restarted before the setting takes effect.
- Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
 
## <a href="" id="bkmk-domain"></a>To configure a security policy setting using the Local Group Policy Editor console
You must have the appropriate permissions to install and use the Microsoft Management Console (MMC), and to update a Group Policy Object (GPO) on the domain controller to perform these procedures.
1. Open the Local Group Policy Editor (gpedit.msc).
2. In the console tree, click **Computer Configuration**, click **Windows Settings**, and then click **Security Settings**.
3. Do one of the following:
- Click **Account Policies** to edit the **Password Policy** or **Account Lockout Policy**.
- Click **Local Policies** to edit an **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
4. In the details pane, double-click the security policy setting that you want to modify.
**Note**  
   If this security policy has not yet been defined, select the **Define these policy settings** check box.
>**Note:**  If this security policy has not yet been defined, select the **Define these policy settings** check box.
 
5. Modify the security policy setting, and then click **OK**.
**Note**  If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console.
>**Note:**  If you want to configure security settings for many devices on your network, you can use the Group Policy Management Console.
 
## <a href="" id="bkmk-dc"></a>To configure a setting for a domain controller
The following procedure describes how to configure a security policy setting for only a domain controller (from the domain controller).
1. To open the domain controller security policy, in the console tree, locate *GroupPolicyObject \[ComputerName\]* Policy, click **Computer Configuration**, click **Windows Settings**, and then click **Security Settings**.
2. Do one of the following:
- Double-click **Account Policies** to edit the **Password Policy**, **Account Lockout Policy**, or **Kerberos Policy**.
- Click **Local Policies** to edit the **Audit Policy**, a **User Rights Assignment**, or **Security Options**.
3. In the details pane, double-click the security policy that you want to modify.
**Note**  
If this security policy has not yet been defined, select the **Define these policy settings** check box.
>**Note**  If this security policy has not yet been defined, select the **Define these policy settings** check box.
 
4. Modify the security policy setting, and then click **OK**.
**Important**  
- Always test a newly created policy in a test organizational unit before you apply it to your network.
- When you change a security setting through a GPO and click **OK**, that setting will take effect the next time you refresh the settings.
 
## Related topics
[Security policy settings reference](security-policy-settings-reference.md)
 
 
- [Security policy settings reference](security-policy-settings-reference.md)

284
windows/keep-secure/how-user-account-control-works.md
View File

@ -2,143 +2,311 @@
title: How User Account Control works (Windows 10)
description: User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware.
ms.assetid: 9f921779-0fd3-4206-b0e4-05a19883ee59
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: operate
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# How User Account Control works
**Applies to**
- Windows 10
User Account Control (UAC) is a fundamental component of Microsoft's overall security vision. UAC helps mitigate the impact of malware.
## UAC process and interactions
Each app that requires the administrator access token must prompt for consent. The one exception is the relationship that exists between parent and child processes. Child processes inherit the user's access token from the parent process. Both the parent and child processes, however, must have the same integrity level. Windows 10 protects processes by marking their integrity levels. Integrity levels are measurements of trust. A "high" integrity application is one that performs tasks that modify system data, such as a disk partitioning application, while a "low" integrity application is one that performs tasks that could potentially compromise the operating system, such as a Web browser. Apps with lower integrity levels cannot modify data in applications with higher integrity levels. When a standard user attempts to run an app that requires an administrator access token, UAC requires that the user provide valid administrator credentials.
In order to better understand how this process happens, let's look at the Windows logon process.
### Logon process
The following shows how the logon process for an administrator differs from the logon process for a standard user.
![uac windows logon process](images/uacwindowslogonprocess.gif)
By default, standard users and administrators access resources and run apps in the security context of standard users. When a user logs on to a computer, the system creates an access token for that user. The access token contains information about the level of access that the user is granted, including specific security identifiers (SIDs) and Windows privileges.
When an administrator logs on, two separate access tokens are created for the user: a standard user access token and an administrator access token. The standard user access token contains the same user-specific information as the administrator access token, but the administrative Windows privileges and SIDs are removed. The standard user access token is used to start apps that do not perform administrative tasks (standard user apps). The standard user access token is then used to display the desktop (explorer.exe). Explorer.exe is the parent process from which all other user-initiated processes inherit their access token. As a result, all apps run as a standard user unless a user provides consent or credentials to approve an app to use a full administrative access token.
A user that is a member of the Administrators group can log on, browse the Web, and read e-mail while using a standard user access token. When the administrator needs to perform a task that requires the administrator access token, Windows 10 automatically prompts the user for approval. This prompt is called an elevation prompt, and its behavior can be configured by using the Local Security Policy snap-in (Secpol.msc) or Group Policy. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
### The UAC User Experience
When UAC is enabled, the user experience for standard users is different from that of administrators in Admin Approval Mode. The recommended and more secure method of running Windows 10 is to make your primary user account a standard user account. Running as a standard user helps to maximize security for a managed environment. With the built-in UAC elevation component, standard users can easily perform an administrative task by entering valid credentials for a local administrator account. The default, built-in UAC elevation component for standard users is the credential prompt.
The alternative to running as a standard user is to run as an administrator in Admin Approval Mode. With the built-in UAC elevation component, members of the local Administrators group can easily perform an administrative task by providing approval. The default, built-in UAC elevation component for an administrator account in Admin Approval Mode is called the consent prompt.
**The consent and credential prompts**
With UAC enabled, Windows 10 prompts for consent or prompts for credentials of a valid local administrator account before starting a program or task that requires a full administrator access token. This prompt ensures that no malicious software can be silently installed.
**The consent prompt**
The consent prompt is presented when a user attempts to perform a task that requires a user's administrative access token. The following is an example of the UAC consent prompt.
![uac consent prompt](images/uacconsentprompt.gif)
**The credential prompt**
The credential prompt is presented when a standard user attempts to perform a task that requires a user's administrative access token. Administrators can also be required to provide their credentials by setting the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting value to **Prompt for credentials**.
The following is an example of the UAC credential prompt.
![uac credential prompt](images/uaccredentialprompt.gif)
**UAC elevation prompts**
The UAC elevation prompts are color-coded to be app-specific, enabling for immediate identification of an application's potential security risk. When an app attempts to run with an administrator's full access token, Windows 10 first analyzes the executable file to determine its publisher. Apps are first separated into three categories based on the file's publisher: Windows 10, publisher verified (signed), and publisher not verified (unsigned). The following diagram illustrates how Windows 10 determines which color elevation prompt to present to the user.
The elevation prompt color-coding is as follows:
- Red background with a red shield icon: The app is blocked by Group Policy or is from a publisher that is blocked.
- Blue background with a blue and gold shield icon: The application is a Windows 10 administrative app, such as a Control Panel item.
- Blue background with a blue shield icon: The application is signed by using Authenticode and is trusted by the local computer.
- Yellow background with a yellow shield icon: The application is unsigned or signed but is not yet trusted by the local computer.
**Shield icon**
Some Control Panel items, such as **Date and Time Properties**, contain a combination of administrator and standard user operations. Standard users can view the clock and change the time zone, but a full administrator access token is required to change the local system time. The following is a screen shot of the **Date and Time Properties** Control Panel item.
![uac shield icon](images/uacshieldicon.png)
The shield icon on the **Change date and time** button indicates that the process requires a full administrator access token and will display a UAC elevation prompt.
**Securing the elevation prompt**
The elevation process is further secured by directing the prompt to the secure desktop. The consent and credential prompts are displayed on the secure desktop by default in Windows 10. Only Windows processes can access the secure desktop. For higher levels of security, we recommend keeping the **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting enabled.
When an executable file requests elevation, the interactive desktop, also called the user desktop, is switched to the secure desktop. The secure desktop dims the user desktop and displays an elevation prompt that must be responded to before continuing. When the user clicks **Yes** or **No**, the desktop switches back to the user desktop.
Malware can present an imitation of the secure desktop, but when the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting is set to **Prompt for consent**, the malware does not gain elevation if the user clicks **Yes** on the imitation. If the policy setting is set to **Prompt for credentials**, malware imitating the credential prompt may be able to gather the credentials from the user. However, the malware does not gain elevated privilege and the system has other protections that mitigate malware from taking control of the user interface even with a harvested password.
While malware could present an imitation of the secure desktop, this issue cannot occur unless a user previously installed the malware on the PC. Because processes requiring an administrator access token cannot silently install when UAC is enabled, the user must explicitly provide consent by clicking **Yes** or by providing administrator credentials. The specific behavior of the UAC elevation prompt is dependent upon Group Policy.
## UAC Architecture
The following diagram details the UAC architecture.
![uac architecture](images/uacarchitecture.gif)
To better understand each component, review the table below:
Component
Description
**User**
User performs operation requiring privilege
If the operation changes the file system or registry, Virtualization is called. All other operations call ShellExecute.
ShellExecute
ShellExecute calls CreateProcess. ShellExecute looks for the ERROR\_ELEVATION\_REQUIRED error from CreateProcess. If it receives the error, ShellExecute calls the Application Information service to attempt to perform the requested task with the elevated prompt.
CreateProcess
If the application requires elevation, CreateProcess rejects the call with ERROR\_ELEVATION\_REQUIRED.
**System**
Application Information service
A system service that helps start apps that require one or more elevated privileges or user rights to run, such as local administrative tasks, and apps that require higher integrity levels. The Application Information service helps start such apps by creating a new process for the application with an administrative user's full access token when elevation is required and (depending on Group Policy) consent is given by the user to do so.
Elevating an ActiveX install
If ActiveX is not installed, the system checks the UAC slider level. If ActiveX is installed, the **User Account Control: Switch to the secure desktop when prompting for elevation** Group Policy setting is checked.
Check UAC slider level
UAC has four levels of notification to choose from and a slider to use to select the notification level:
- High
If the slider is set to **Always notify**, the system checks whether the secure desktop is enabled.
- Medium
If the slider is set to **Notify me only when programs try to make changes to my computer**, the **User Account Control: Only elevate executable files that are signed and validated** policy setting is checked:
- If the policy setting is enabled, the public key infrastructure (PKI) certification path validation is enforced for a given file before it is permitted to run.
- If the policy setting is not enabled (default), the PKI certification path validation is not enforced before a given file is permitted to run. The **User Account Control: Switch to the secure desktop when prompting for elevation** Group Policy setting is checked.
- Low
If the slider is set to **Notify me only when apps try to make changes to my computer (do not dim by desktop)**, the CreateProcess is called.
- Never Notify
If the slider is set to **Never notify me when**, UAC prompt will never notify when an app is trying to install or trying to make any change on the computer.
**Important**  
This setting is not recommended. This setting is the same as setting the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** policy setting to **Elevate without prompting**.
 
Secure desktop enabled
The **User Account Control: Switch to the secure desktop when prompting for elevation** policy setting is checked:
- If the secure desktop is enabled, all elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
- If the secure desktop is not enabled, all elevation requests go to the interactive user's desktop, and the per-user settings for administrators and standard users are used.
CreateProcess
CreateProcess calls AppCompat, Fusion, and Installer detection to assess if the app requires elevation. The file is then inspected to determine its requested execution level, which is stored in the application manifest for the file. CreateProcess fails if the requested execution level specified in the manifest does not match the access token and returns an error (ERROR\_ELEVATION\_REQUIRED) to ShellExecute.
AppCompat
The AppCompat database stores information in the application compatibility fix entries for an application.
Fusion
The Fusion database stores information from application manifests that describe the applications. The manifest schema is updated to add a new requested execution level field.
Installer detection
Installer detection detects setup files, which helps prevent installations from being run without the user's knowledge and consent.
**Kernel**
Virtualization
Virtualization technology ensures that non-compliant apps do not silently fail to run or fail in a way that the cause cannot be determined. UAC also provides file and registry virtualization and logging for applications that write to protected areas.
File system and registry
The per-user file and registry virtualization redirects per-computer registry and file write requests to equivalent per-user locations. Read requests are redirected to the virtualized per-user location first and to the per-computer location second.
<table>
<tr>
<th>Component</th>
<th>Description</th>
</tr>
<tr>
<td>
<p><b>User</b></p>
</td>
</tr>
<tr>
<td>
<p>User performs operation requiring privilege</p>
</td>
<td>
<p>If the operation changes the file system or registry, Virtualization is called. All other operations call ShellExecute.</p>
</td>
</tr>
<tr>
<td>
<p>ShellExecute</p>
</td>
<td>
<p>ShellExecute calls CreateProcess. ShellExecute looks for the ERROR_ELEVATION_REQUIRED error from CreateProcess. If it receives the error, ShellExecute calls the Application Information service to attempt to perform the requested task with the elevated prompt.</p>
</td>
</tr>
<tr>
<td>
<p>CreateProcess</p>
</td>
<td>
<p>If the application requires elevation, CreateProcess rejects the call with ERROR_ELEVATION_REQUIRED.</p>
</td>
</tr>
<tr>
<td>
<p><b>System</b></p>
</td>
</tr>
<tr>
<td>
<p>Application Information service</p>
</td>
<td>
<p>A system service that helps start apps that require one or more elevated privileges or user rights to run, such as local administrative tasks, and apps that require higher integrity levels. The Application Information service helps start such apps by creating a new process for the application with an administrative user's full access token when elevation is required and (depending on Group Policy) consent is given by the user to do so.</p>
</td>
</tr>
<tr>
<td>
<p>Elevating an ActiveX install</p>
</td>
<td>
<p>If ActiveX is not installed, the system checks the UAC slider level. If ActiveX is installed, the <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> Group Policy setting is checked.</p>
</td>
</tr>
<tr>
<td>
<p>Check UAC slider level</p>
</td>
<td>
<p>UAC has four levels of notification to choose from and a slider to use to select the notification level:</p>
<ul>
<li>
<p>High</p>
<p>If the slider is set to <b>Always notify</b>, the system checks whether the secure desktop is enabled.</p>
</li>
<li>
<p>Medium</p>
<p>If the slider is set to <b>Notify me only when programs try to make changes to my computer</b>, the <b>User Account Control: Only elevate executable files that are signed and validated</b> policy setting is checked:</p>
<ul>
<li>
<p>If the policy setting is enabled, the public key infrastructure (PKI) certification path validation is enforced for a given file before it is permitted to run.</p>
</li>
<li>
<p>If the policy setting is not enabled (default), the PKI certification path validation is not enforced before a given file is permitted to run. The <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> Group Policy setting is checked.</p>
</li>
</ul>
</li>
<li>
<p>Low</p>
<p>If the slider is set to <b>Notify me only when apps try to make changes to my computer (do not dim by desktop)</b>, the CreateProcess is called.</p>
</li>
<li>
<p>Never Notify</p>
<p>If the slider is set to <b>Never notify me when</b>, UAC prompt will never notify when an app is trying to install or trying to make any change on the computer.</p>
<div class="alert"><b>Important</b>  <p class="note">This setting is not recommended. This setting is the same as setting the <b>User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode</b> policy setting to <b>Elevate without prompting</b>.</p>
</div>
<div> </div>
</li>
</ul>
</td>
</tr>
<tr>
<td>
<p>Secure desktop enabled</p>
</td>
<td>
<p>The <b>User Account Control: Switch to the secure desktop when prompting for elevation</b> policy setting is checked: </p>
<ul>
<li>
<p>If the secure desktop is enabled, all elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.</p>
</li>
<li>
<p>If the secure desktop is not enabled, all elevation requests go to the interactive user's desktop, and the per-user settings for administrators and standard users are used.</p>
</li>
</ul>
</td>
</tr>
<tr>
<td>
<p>CreateProcess</p>
</td>
<td>
<p>CreateProcess calls AppCompat, Fusion, and Installer detection to assess if the app requires elevation. The file is then inspected to determine its requested execution level, which is stored in the application manifest for the file. CreateProcess fails if the requested execution level specified in the manifest does not match the access token and returns an error (ERROR_ELEVATION_REQUIRED) to ShellExecute.</p>
</td>
</tr>
<tr>
<td>
<p>AppCompat</p>
</td>
<td>
<p>The AppCompat database stores information in the application compatibility fix entries for an application.</p>
</td>
</tr>
<tr>
<td>
<p>Fusion</p>
</td>
<td>
<p>The Fusion database stores information from application manifests that describe the applications. The manifest schema is updated to add a new requested execution level field.</p>
</td>
</tr>
<tr>
<td>
<p>Installer detection</p>
</td>
<td>
<p>Installer detection detects setup files, which helps prevent installations from being run without the user's knowledge and consent.</p>
</td>
</tr>
<tr>
<td>
<p><b>Kernel</b></p>
</td>
</tr>
<tr>
<td>
<p>Virtualization</p>
</td>
<td>
<p>Virtualization technology ensures that non-compliant apps do not silently fail to run or fail in a way that the cause cannot be determined. UAC also provides file and registry virtualization and logging for applications that write to protected areas.</p>
</td>
</tr>
<tr>
<td>
<p>File system and registry</p>
</td>
<td>
<p>The per-user file and registry virtualization redirects per-computer registry and file write requests to equivalent per-user locations. Read requests are redirected to the virtualized per-user location first and to the per-computer location second.</p>
</td>
</tr>
</table>
 
The slider will never turn UAC completely off. If you set it to **Never notify**, it will:
- Keep the UAC service running.
- Cause all elevation request initiated by administrators to be auto-approved without showing a UAC prompt.
- Automatically deny all elevation requests for standard users.
**Important**  
In order to fully disable UAC you must disable the policy **User Account Control: Run all administrators in Admin Approval Mode**.
>**Important:**  In order to fully disable UAC you must disable the policy **User Account Control: Run all administrators in Admin Approval Mode**.
 
**Warning**  
Universal Windows apps will not work when UAC is disabled.
>**Warning:**  Universal Windows apps will not work when UAC is disabled.
 
### Virtualization
Because system administrators in enterprise environments attempt to secure systems, many line-of-business (LOB) applications are designed to use only a standard user access token. As a result, you do not need to replace the majority of apps when UAC is turned on.
Windows 10 includes file and registry virtualization technology for apps that are not UAC-compliant and that require an administrator's access token to run correctly. When an administrative apps that is not UAC-compliant attempts to write to a protected folder, such as Program Files, UAC gives the app its own virtualized view of the resource it is attempting to change. The virtualized copy is maintained in the user's profile. This strategy creates a separate copy of the virtualized file for each user that runs the non-compliant app.
Most app tasks operate properly by using virtualization features. Although virtualization allows a majority of applications to run, it is a short-term fix and not a long-term solution. App developers should modify their apps to be compliant as soon as possible, rather than relying on file, folder, and registry virtualization.
Virtualization is not an option in the following scenarios:
- Virtualization does not apply to apps that are elevated and run with a full administrative access token.
- Virtualization supports only 32-bit apps. Non-elevated 64-bit apps simply receive an access denied message when they attempt to acquire a handle (a unique identifier) to a Windows object. Native Windows 64-bit apps are required to be compatible with UAC and to write data into the correct locations.
- Virtualization is disabled if the app includes an app manifest with a requested execution level attribute.
### Request execution levels
An app manifest is an XML file that describes and identifies the shared and private side-by-side assemblies that an app should bind to at run time. The app manifest includes entries for UAC app compatibility purposes. Administrative apps that include an entry in the app manifest prompt the user for permission to access the user's access token. Although they lack an entry in the app manifest, most administrative app can run without modification by using app compatibility fixes. App compatibility fixes are database entries that enable applications that are not UAC-compliant to work properly.
All UAC-compliant apps should have a requested execution level added to the application manifest. If the application requires administrative access to the system, then marking the app with a requested execution level of "require administrator" ensures that the system identifies this program as an administrative app and performs the necessary elevation steps. Requested execution levels specify the privileges required for an app.
### Installer detection technology
Installation programs are apps designed to deploy software. Most installation programs write to system directories and registry keys. These protected system locations are typically writeable only by an administrator in Installer detection technology, which means that standard users do not have sufficient access to install programs. Windows 10 heuristically detects installation programs and requests administrator credentials or approval from the administrator user in order to run with access privileges. Windows 10 also heuristically detects updates and programs that uninstall applications. One of the design goals of UAC is to prevent installations from being run without the user's knowledge and consent because installation programs write to protected areas of the file system and registry.
Installer detection only applies to:
- 32-bit executable files.
- Applications without a requested execution level attribute.
- Interactive processes running as a standard user with UAC enabled.
Before a 32-bit process is created, the following attributes are checked to determine whether it is an installer:
- The file name includes keywords such as "install," "setup," or "update."
- Versioning Resource fields contain the following keywords: Vendor, Company Name, Product Name, File Description, Original Filename, Internal Name, and Export Name.
- Keywords in the side-by-side manifest are embedded in the executable file.
- Keywords in specific StringTable entries are linked in the executable file.
- Key attributes in the resource script data are linked in the executable file.
- There are targeted sequences of bytes within the executable file.
**Note**  
The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.
 
**Note**  
The User Account Control: Detect application installations and prompt for elevation policy setting must be enabled for installer detection to detect installation programs. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).
 
 
>**Note:**  The keywords and sequences of bytes were derived from common characteristics observed from various installer technologies.
 
>**Note:**  The User Account Control: Detect application installations and prompt for elevation policy setting must be enabled for installer detection to detect installation programs. For more info, see [User Account Control security policy settings](user-account-control-security-policy-settings.md).

104
windows/keep-secure/impersonate-a-client-after-authentication.md
View File

@ -2,111 +2,101 @@
title: Impersonate a client after authentication (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Impersonate a client after authentication security policy setting.
ms.assetid: 4cd241e2-c680-4b43-8ed0-3b391925cec5
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Impersonate a client after authentication
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Impersonate a client after authentication** security policy setting.
## Reference
This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.)
Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access.
The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do.
Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.
Constant: SeImpersonatePrivilege
### Possible values
- User-defined list of accounts
- Default values
- Not defined
### Best practices
- A user can impersonate an access token if any of the following conditions exist:
- The access token that is being impersonated is for this user.
- The user in this session logged on to the network with explicit credentials to create the access token.
- The requested level is less than Impersonate, such as Anonymous or Identify.
Because of these factors, users do not usually need to have this user right assigned.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not eefined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Local Service</p>
<p>Network Service</p>
<p>Service</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined |
| Default Domain Controller Policy| Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Stand-Alone Server Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Domain Controller Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Member Server Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Client Computer Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
An attacker with the **Impersonate a client after authentication** user right could create a service, mislead a client into connecting to the service, and then impersonate that computer to elevate the attacker's level of access to that of the device.
### Countermeasure
On member servers, ensure that only the Administrators and Service groups (Local Service, Network Service, and Service) have the **Impersonate a client after authentication** user right assigned to them.
### Potential impact
In most cases, this configuration has no impact. If you have installed optional components such as ASP.NET or IIS, you may need to assign the **Impersonate a client after authentication** user right to additional accounts that are required by those components, such as IUSR\_*&lt;ComputerName&gt;*, IIS\_WPG, ASP.NET, or IWAM\_*&lt;ComputerName&gt;*.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

14
windows/keep-secure/import-an-applocker-policy-from-another-computer.md
View File

@ -2,25 +2,29 @@
title: Import an AppLocker policy from another computer (Windows 10)
description: This topic for IT professionals describes how to import an AppLocker policy.
ms.assetid: b48cb2b2-8ef8-4cc0-89bd-309d0b1832f6
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Import an AppLocker policy from another computer
**Applies to**
- Windows 10
This topic for IT professionals describes how to import an AppLocker policy.
Before completing this procedure, you should have exported an AppLocker policy. For more information, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md).
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**Caution**  
Importing a policy will overwrite the existing policy on that computer.
>**Caution:**  Importing a policy will overwrite the existing policy on that computer.
 
**To import an AppLocker policy**
1. From the AppLocker console, right-click **AppLocker**, and then click **Import Policy**.
2. In the **Import Policy** dialog box, locate the file that you exported, and then click **Open**.
3. The **Import Policy** dialog box will warn you that importing a policy will overwrite the existing rules and enforcement settings. If acceptable, click **OK** to import and overwrite the policy.
4. The **AppLocker** dialog box will notify you of how many rules were overwritten and imported. Click **OK**.
 
 

13
windows/keep-secure/import-an-applocker-policy-into-a-gpo.md
View File

@ -2,26 +2,29 @@
title: Import an AppLocker policy into a GPO (Windows 10)
description: This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
ms.assetid: 0629ce44-f5e2-48a8-ba47-06544c73261f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Import an AppLocker policy into a GPO
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object (GPO).
AppLocker policies can be created as local security policies and modified like any other local security policy, or they can be created as part of a GPO and managed by using Group Policy. You can create AppLocker policies on any supported computer. For info about which Windows editions are supported, see [Requirements to Use AppLocker](requirements-to-use-applocker.md).
**Important**  
Follow your organization's standard procedures for updating GPOs. For info about specific steps to follow for AppLocker policies, see [Maintain AppLocker policies](maintain-applocker-policies.md).
>**Important:**  Follow your organization's standard procedures for updating GPOs. For info about specific steps to follow for AppLocker policies, see [Maintain AppLocker policies](maintain-applocker-policies.md).
 
To complete this procedure, you must have the **Edit Setting** permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
**To import an AppLocker policy into a GPO**
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
2. In the console tree under **Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Application Control Policies**, click **AppLocker**.
3. Right-click **AppLocker**, and then click **Import Policy**.
4. In the **Import Policy** dialog box, locate the XML policy file, and click **Open**.
5. The **AppLocker** dialog box will notify you of how many rules were imported. Click **OK**.
 
 

83
windows/keep-secure/increase-a-process-working-set.md
View File

@ -2,88 +2,87 @@
title: Increase a process working set (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Increase a process working set security policy setting.
ms.assetid: b742ad96-37f3-4686-b8f7-f2b48367105b
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Increase a process working set
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Increase a process working set** security policy setting.
## Reference
This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they are available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
Constant: SeIncreaseWorkingSetPrivilege
### Possible values
- User-defined list of accounts
- Not Defined
### Best practices
- You should make users aware that adverse performance issues may occur if they modify this security setting.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, standard users have this right.
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not Defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Users</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not Defined|
| Default Domain Controller Policy | Users|
| Stand-Alone Server Default Settings| Users|
| Domain Controller Effective Default Settings| Users|
| Member Server Effective Default Settings | Users|
| Client Computer Effective Default Settings | Users|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
Increasing the working set size for a process decreases the amount of physical memory that is available to the rest of the system.
### Countermeasure
Increase user’s awareness about the impact of increasing the working set of a process and how to recognize that their system is adversely affected if they change this setting.
### Potential impact
None. Allowing standard users to increase the working set of a process is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

86
windows/keep-secure/increase-scheduling-priority.md
View File

@ -2,90 +2,92 @@
title: Increase scheduling priority (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Increase scheduling priority security policy setting.
ms.assetid: fbec5973-d35e-4797-9626-d0d56061527f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Increase scheduling priority
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Increase scheduling priority** security policy setting.
## Reference
This policy setting determines which user accounts can increase the base priority class of a process. It is not a privileged operation to increase relative priority within a priority class. This user right is not required by administrative tools that are supplied with the operating system, but it might be required by software development tools.
Specifically, this security setting determines which accounts can use a process with Write Property access to another process to increase the run priority that is assigned to the other process. A user with this privilege can change the scheduling priority of a process through the Task Manager user interface.
Constant: SeIncreaseBasePriorityPrivilege
### Possible values
- User-defined list of accounts
- Not defined
- Administrators
### Best practices
- Allow the default value, Administrators, as the only account responsible for controlling process scheduling priorities.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Administrators on domain controllers and on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy| Administrators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators|
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
A user who is assigned this user right could increase the scheduling priority of a process to Real-Time, which would leave little processing time for all other processes and could lead to a denial-of-service condition.
### Countermeasure
Verify that only Administrators have the **Increase scheduling priority** user right assigned to them.
### Potential impact
None. Restricting the **Increase scheduling priority** user right to members of the Administrators group is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

126
windows/keep-secure/initialize-and-configure-ownership-of-the-tpm.md
View File

@ -2,156 +2,176 @@
title: Initialize and configure ownership of the TPM (Windows 10)
description: This topic for the IT professional describes how to initialize and set the ownership the Trusted Platform Module (TPM), turn the TPM on and off, and clear TPM keys.
ms.assetid: 1166efaf-7aa3-4420-9279-435d9c6ac6f8
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Initialize and configure ownership of the TPM
**Applies to**
- Windows 10
This topic for the IT professional describes how to initialize and set the ownership the Trusted Platform Module (TPM), turn the TPM on and off, and clear TPM keys. It also explains how to troubleshoot issues that you might encounter as a result of using these procedures.
## <a href="" id="bkmk-init"></a>About TPM initialization and ownership
The TPM must be initialized and ownership must be taken before it can be used to help secure your computer. The owner of the TPM is the user who possesses the owner password and is able to set it and change it. Only one owner password exists per TPM. The owner of the TPM can make full use of TPM capabilities. Taking ownership of the TPM can be done as part of the initialization process.
When you start the TPM Initialization Wizard, which is accessed through the TPM Microsoft Management Console (MMC), you can determine whether the computer's TPM has been initialized. You can also view the TPM properties.
This topic contains procedures for the following tasks:
- [Initialize the TPM and set ownership](#bkmk-initializetpm)
- [Troubleshoot TPM initialization](#bkmk-troubleshootinit)
- [Turn on or turn off the TPM](#bkmk-onoff)
- [Clear all the keys from the TPM](#bkmk-clear1)
- [Use the TPM cmdlets](#bkmk-tpmcmdlets)
## <a href="" id="bkmk-initializetpm"></a>Initialize the TPM and set ownership
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure. In addition, the computer must be equipped with a Trusted Computing Group-compliant BIOS.
**To start the TPM Initialization Wizard**
1. Open the TPM Management console (tpm.msc). If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
2. On the **Action** menu, click **Initialize TPM** to start the TPM Initialization Wizard.
3. If the TPM has never been initialized or is turned off, the TPM Initialization Wizard displays the **Turn on the TPM security hardware** dialog box. This dialog box provides guidance for initializing or turning on the TPM. Follow the instructions in the wizard.
**Note**  
If the TPM is already turned on, the TPM Initialization Wizard displays the **Create the TPM owner password** dialog box. Skip the remainder of this procedure and continue with the [To set ownership of the TPM](#bkmk-setownership) procedure.
>**Note:** If the TPM is already turned on, the TPM Initialization Wizard displays the **Create the TPM owner password** dialog box. Skip the remainder of this procedure and continue with the [To set ownership of the TPM](#bkmk-setownership) procedure.
 
**Note**  
If the TPM Initialization Wizard detects that you do not have a compatible BIOS, you cannot continue with the TPM Initialization Wizard, and you are alerted to consult the computer manufacturer's documentation for instructions to initialize the TPM.
>**Note:**  If the TPM Initialization Wizard detects that you do not have a compatible BIOS, you cannot continue with the TPM Initialization Wizard, and you are alerted to consult the computer manufacturer's documentation for instructions to initialize the TPM.
 
4. Click **Restart**.
5. Follow the BIOS screen prompts. An acceptance prompt is displayed to ensure that a user has physical access to the computer and that no malicious software is attempting to turn on the TPM.
**Note**  
BIOS screen prompts and the required keystrokes vary by computer manufacturer.
>**Note:**  BIOS screen prompts and the required keystrokes vary by computer manufacturer.
 
6. After the computer restarts, sign in to the computer with the same administrative credentials that you used to start this procedure.
7. The TPM Initialization Wizard automatically restarts. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
8. Continue with the next procedure to take ownership of the TPM.
To finish initializing the TPM for use, you must set an owner for the TPM. The process of taking ownership includes creating an owner password for the TPM.
**To set ownership of the TPM**
1. If you are not continuing immediately from the last procedure, start the TPM Initialization Wizard. If you need to review the steps to do so, see the previous procedure [To start the TPM Initialization Wizard](#bkmk-starttpminitwizard).
2. In the **Create the TPM owner password** dialog box, click **Automatically create the password (recommended)**.
3. In the **Save your TPM owner password** dialog box, click **Save the password**.
4. In the **Save As** dialog box, select a location to save the password, and then click **Save**. The password file is saved as *computer\_name.tpm*.
**Important**  
We highly recommend saving the TPM owner password to a removable storage device and storing it in a safe location.
>**Important:**  We highly recommend saving the TPM owner password to a removable storage device and storing it in a safe location.
 
5. Click **Print the password** if you want to print a copy of your password.
**Important**  
We highly recommend printing a copy of your TPM owner password and storing it in a safe location.
>**Important:**  We highly recommend printing a copy of your TPM owner password and storing it in a safe location.
 
6. Click **Initialize**.
**Note**  
The process of initializing the TPM might take a few minutes to complete.
>**Note:**  The process of initializing the TPM might take a few minutes to complete.
 
7. Click **Close**.
**Caution**  
Do not lose your password. If you do, you will be unable to make administrative changes unless you clear the TPM, which can result in data loss.
>**Caution:**  Do not lose your password. If you do, you will be unable to make administrative changes unless you clear the TPM, which can result in data loss.
 
## <a href="" id="bkmk-troubleshootinit"></a>Troubleshoot TPM initialization
Managing the Trusted Platform Module (TPM) is usually a straightforward procedure. If are unable to complete the initialization procedure, review the following information:
- If the TPM is not detected by Windows, verify that your computer hardware contains a Trusted Computing Group-compliant BIOS. Ensure that no BIOS settings have been used to hide the TPM from the operating system.
- If you are attempting to initialize the TPM as part of the BitLocker setup, check which TPM driver is installed on the computer. We recommend always using one of the TPM drivers that is provided by Microsoft and is protected with BitLocker. If a non-Microsoft TPM driver is installed, it may prevent the default TPM driver from loading and cause BitLocker to report that a TPM is not present on the computer. If you have a non-Microsoft driver installed, remove it and then try to initialize the TPM. The following table lists the three standard TPM drivers that are provided by Microsoft.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Driver name</th>
<th align="left">Manufacturer</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Trusted Platform Module 1.2</p></td>
<td align="left"><p>(Standard)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Broadcom Trusted Platform Module (A1), v1.2</p></td>
<td align="left"><p>Broadcom</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Broadcom Trusted Platform Module (A2), v1.2</p></td>
<td align="left"><p>Broadcom</p></td>
</tr>
</tbody>
</table>
| Driver name | Manufacturer |
| - | - |
| Trusted Platform Module 1.2 | (Standard)|
| Broadcom Trusted Platform Module (A1), v1.2 | Broadcom|
| Broadcom Trusted Platform Module (A2), v1.2 | Broadcom|
 
- If the TPM has been previously initialized and you do not have the owner password, you may have to clear or reset the TPM to the factory default values. For more information, see [Clear all the keys from the TPM](#bkmk-clear1).
**Caution**  
Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
> **Caution:**  Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
 
Because your TPM security hardware is a physical part of your computer, you may want to read the manuals or instructions that came with your computer, or search the manufacturer's website.
**Network connection**
You cannot complete the initialization of the Trusted Platform Module (TPM) when your computer is disconnected from your organization's network if either of the following conditions exist:
- An administrator has configured your computer to require that TPM recovery information be saved in Active Directory Domain Services (AD DS). This requirement can be configured through Group Policy.
- A domain controller cannot be reached. This can occur on a computer that is currently disconnected from the network, separated from the domain by a firewall, or experiencing a network component failure (such as an unplugged cable or a faulty network adapter).
In either case, an error message appears, and you cannot complete the initialization process. To avoid this issue, initialize the TPM while you are connected to the corporate network and you can contact a domain controller.
**Systems with multiple TPMs**
Some systems may have multiple TPMs and the active TPM may be toggled in the BIOS. Windows 10 does not support this behavior. If you switch TPMs, functionality that depends on the TPM will not work with the new TPM unless it is cleared and put through provisioning. Performing this clear may cause data loss, in particular of keys and certificates associated with the previous TPM. For example, toggling TPMs will cause Bitlocker to enter recovery mode. It is strongly recommended that, on systems with two TPMs, one TPM is selected to be used and the selection is not changed.
## <a href="" id="bkmk-onoff"></a>Turn on or turn off the TPM
Normally, the TPM is turned on as part of the TPM initialization process. You do not normally need to turn the TPM on or off. However, if necessary you can do so by using the TPM MMC.
### <a href="" id="turn-on-the-tpm-"></a>Turn on the TPM
If the TPM has been initialized but has never been used, or if you want to use the TPM after you have turned it off, you can use the following procedure to turn on the TPM.
**To turn on the TPM**
1. Open the TPM MMC (tpm.msc).
2. In the **Action** pane, click **Turn TPM On** to display the **Turn on the TPM Security Hardware** page. Read the instructions on this page.
3. Click **Shutdown** (or **Restart**), and then follow the BIOS screen prompts.
After the computer restarts, but before you sign in to Windows, you will be prompted to accept the reconfiguration of the TPM. This ensures that the user has physical access to the computer and that malicious software is not attempting to make changes to the TPM.
### <a href="" id="turn-off-the-tpm-"></a>Turn off the TPM
If you want to stop using the services that are provided by the TPM, you can use the TPM MMC to turn off the TPM. If you have the TPM owner password, physical access to the computer is not required to turn off the TPM. If you do not have the TPM owner password, you must have physical access to the computer to turn off the TPM.
If you want to stop using the services that are provided by the TPM, you can use the TPM MMC to turn off the TPM. If you have the TPM owner password, physical access to the computer is not required to turn off the TPM. If you do not have the TPM owner password, you must have physical access to the
computer to turn off the TPM.
**To turn off the TPM**
1. Open the TPM MMC (tpm.msc).
2. In the **Action** pane, click **Turn TPM Off** to display the **Turn off the TPM security hardware** page.
3. In the **Turn off the TPM security hardware** dialog box, select a method to enter your owner password and turning off the TPM:
- If you saved your TPM owner password on a removable storage device, insert it, and then click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, click **Browse** to locate the .tpm file that is saved on your removable storage device, click **Open**, and then click **Turn TPM Off**.
- If you do not have the removable storage device with your saved TPM owner password, click **I want to enter the password**. In the **Type your TPM owner password** dialog box, type your password (including hyphens), and then click **Turn TPM Off**.
- If you do not know your TPM owner password, click **I do not have the TPM owner password**, and follow the instructions that are provided in the dialog box and subsequent BIOS screens to turn off the TPM without entering the password.
## <a href="" id="bkmk-clear1"></a>Clear all the keys from the TPM
Clearing the TPM resets it to an unowned state. After clearing the TPM, you need to complete the TPM initialization process before using software that relies on the TPM, such as BitLocker Drive Encryption. By default, the TPM is initialized automatically.
**Important**  
Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
>**Important:**  Clearing the TPM can result in data loss. To avoid data loss, make sure that you have a backup or recovery method for any data that is protected or encrypted by the TPM.
 
After the TPM is cleared, it is also turned off.
To temporarily suspend TPM operations, turn off the TPM instead of clearing it.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
**To clear the TPM**
1. Open the TPM MMC (tpm.msc).
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
3. Under **Actions**, click **Clear TPM**.
**Warning**  
If the TPM is off, reinitialize it before clearing it.
>**Warning:**  If the TPM is off, reinitialize it before clearing it.
Clearing the TPM resets it to factory defaults and turns it off. You will lose all created keys and data that is protected by those keys.
 
4. In the **Clear the TPM security hardware** dialog box, select one of the following methods to enter your password and clear the TPM:
- If you have the removable storage device with your saved TPM owner password, insert it, and click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, use **Browse** to navigate to the .tpm file that is saved on your removable storage device. Click **Open**, and then click **Clear TPM**.
- If you do not have the removable storage device with your saved password, click **I want to enter the owner password**. In the **Type your TPM owner password** dialog box, type your password (including hyphens), and click **Clear TPM**.
- If you do not know your TPM owner password, click **I don't have the TPM owner password**, and follow the instructions that are provided to clear the TPM without entering the password.
**Note**  
If you have physical access to the computer, you can clear the TPM and perform a limited number of management tasks without entering the TPM owner password.
>**Note:**  If you have physical access to the computer, you can clear the TPM and perform a limited number of management tasks without entering the TPM owner password.
 
The status of your TPM is displayed under **Status** in TPM MMC.
## <a href="" id="bkmk-tpmcmdlets"></a>Use the TPM cmdlets
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
`dism /online /enable-feature /FeatureName:tpm-psh-cmdlets`
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx).
## Additional resources
For more info about TPM, see [Trusted Platform Module Technology Overview](trusted-platform-module-overview.md#bkmk-additionalresources).