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

Merge remote-tracking branch 'refs/remotes/origin/jd-sandbox'

Browse Source
This commit is contained in:
jdeckerMS 2016-05-25 12:13:04 -07:00
commit aa43343bcc
46 changed files with 2208 additions and 2270 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
windows/keep-secure/optimize-applocker-performance.md
View File

@ -2,22 +2,31 @@
title: Optimize AppLocker performance (Windows 10)
description: This topic for IT professionals describes how to optimize AppLocker policy enforcement.
ms.assetid: a20efa20-bc98-40fe-bd81-28ec4905e0f6
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Optimize AppLocker performance
**Applies to**
- Windows 10
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
## Optimization of Group Policy
AppLocker policies can be implemented by organization unit (OU) using Group Policy. If so, your Group Policy infrastructure should be optimized and retested for performance when AppLocker policies are added to existing Group Policy Objects (GPOs) or new GPOs are created, as you do with adding any policies to your GPOs.
For more info, see the [Optimizing Group Policy Performance](http://go.microsoft.com/fwlink/p/?LinkId=163238) article in TechNet Magazine.
### AppLocker rule limitations
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number of rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the rule, such as the number of file hashes included in a single file hash condition.
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number of rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the rule, such as the number of file hashes included in a single file hash
condition.
### Using the DLL rule collection
When the DLL rule collection is enabled, AppLocker must check each DLL that an application loads. The more DLLs, the longer AppLocker requires to complete the evaluation.
 
 

12
windows/keep-secure/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
View File

@ -2,26 +2,32 @@
title: Packaged apps and packaged app installer rules in AppLocker (Windows 10)
description: This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
ms.assetid: 8fd44d08-a0c2-4c5b-a91f-5cb9989f971d
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Packaged apps and packaged app installer rules in AppLocker
**Applies to**
- Windows 10
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Windows Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
Typically, an app consists of multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:
- Publisher name
- Package name
- Package version
In summary, including AppLocker rules for Universal Windows apps in your policy design provides:
- The ability to control the installation and running of the app
- The ability to control all the components of the app with a single rule rather than controlling individual binaries within the app
- The ability to create application control policies that survive app updates
- Management of Universal Windows apps through Group Policy.
 
 

26
windows/keep-secure/passport-event-300.md
View File

@ -2,18 +2,22 @@
title: Event ID 300 - Passport successfully created (Windows 10)
description: This event is created when a Microsoft Passport for Enterprise is successfully created and registered with Azure Active Directory (Azure AD).
ms.assetid: 0DD59E75-1C5F-4CC6-BB0E-71C83884FF04
ms.pagetype: security
keywords: ["ngc"]
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: jdeckerMS
---
# Event ID 300 - Passport successfully created
**Applies to**
- Windows 10
- Windows 10 Mobile
This event is created when a Microsoft Passport for Enterprise is successfully created and registered with Azure Active Directory (Azure AD). Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request.
## Event details
| | |
|--------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@ -21,16 +25,18 @@ This event is created when a Microsoft Passport for Enterprise is successfully c
| **ID:** | 300 |
| **Source:** | Microsoft Azure Device Registration Service |
| **Version:** | 10 |
| **Message:** | The NGC key was successfully registered. Key ID: {4476694e-8e3b-4ef8-8487-be21f95e6f07}. UPN:test@contoso.com. Attestation: ATT\_SOFT. Client request ID: . Server request ID: db2da6bd-3d70-4b9b-b26b-444f669902da. Server response: {"kid":"4476694e-8e3b-4ef8-8487-be21f95e6f07","upn":"test@contoso.com"} |
| **Message:** | The NGC key was successfully registered. Key ID: {4476694e-8e3b-4ef8-8487-be21f95e6f07}. UPN:test@contoso.com. Attestation: ATT\_SOFT. Client request ID: . Server request ID: db2da6bd-3d70-4b9b-b26b-444f669902da.
Server response: {"kid":"4476694e-8e3b-4ef8-8487-be21f95e6f07","upn":"test@contoso.com"} |
 
## Resolve
This is a normal condition. No further action is required.
## Related topics
[Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
[Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
[Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
[Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
[Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
[Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)
 
 
- [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
- [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
- [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
- [Prepare people to use Microsoft Passport](prepare-people-to-use-microsoft-passport.md)
- [Microsoft Passport and password changes](microsoft-passport-and-password-changes.md)
- [Microsoft Passport errors during PIN creation](microsoft-passport-errors-during-pin-creation.md)

88
windows/keep-secure/password-must-meet-complexity-requirements.md
View File

@ -2,94 +2,98 @@
title: Password must meet complexity requirements (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Password must meet complexity requirements security policy setting.
ms.assetid: 94482ae3-9dda-42df-9782-2f66196e6afe
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Password must meet complexity requirements
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Password must meet complexity requirements** security policy setting.
## Reference
The **Passwords must meet complexity requirements** policy setting determines whether passwords must meet a series of guidelines that are considered important for a strong password. Enabling this policy setting requires passwords to meet the following requirements:
1. Passwords may not contain the user's samAccountName (Account Name) value or entire displayName (Full Name value). Both checks are not case sensitive.
The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed to not be included in the password. Tokens that are less than three characters are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
2. The password contains characters from three of the following categories:
- Uppercase letters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
- Lowercase letters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
- Base 10 digits (0 through 9)
- Non-alphanumeric characters (special characters) (for example, !, $, \#, %)
- Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.
Complexity requirements are enforced when passwords are changed or created.
The rules that are included in the Windows Server password complexity requirements are part of Passfilt.dll, and they cannot be directly modified.
Enabling the default Passfilt.dll may cause some additional Help Desk calls for locked-out accounts because users might not be used to having passwords that contain characters other than those found in the alphabet. However, this policy setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve.
Additional settings that can be included in a custom Passfilt.dll are the use of non–upper-row characters. Upper-row characters are those that are typed by holding down the SHIFT key and typing any of the digits from 1 through 10.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
Set **Passwords must meet complexity requirements** to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This makes a brute force attack difficult, but still not impossible.
The use of ALT key character combinations can greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements can result in unhappy users and an extremely busy Help Desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of this range can represent standard alphanumeric characters that do not add additional complexity to the password.)
Passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To prevent this, passwords should contain additional characters and meet complexity requirements.
### 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 Group Policy Object (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>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller 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>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| Enabled|
| Default domain controller policy| Enabled|
| Stand-alone server default settings | Disabled|
| Domain controller effective default settings | Enabled|
| Member server effective default settings | Enabled|
| Effective GPO default settings on client computers | Disabled|
 
## 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
Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.
### Countermeasure
Configure the **Passwords must meet complexity requirements** policy setting to Enabled and advise users to use a variety of characters in their passwords.
When combined with a [Minimum password length](minimum-password-length.md) of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it is difficult (but not impossible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.)
### Potential impact
If the default password complexity configuration is retained, additional Help Desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetical characters, or they might have problems entering passwords that contain accented characters or symbols on keyboards with different layouts. However, all users should be able to comply with the complexity requirement with minimal difficulty.
If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper-row symbols. (Upper-row symbols are those that require you to press and hold the SHIFT key and then press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments.
The use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in additional Help Desk requests. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 0128–0159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password.)
## Related topics
[Password Policy](password-policy.md)
 
 
- [Password Policy](password-policy.md)

65
windows/keep-secure/password-policy.md
View File

@ -2,66 +2,51 @@
title: Password Policy (Windows 10)
description: An overview of password policies for Windows and links to information for each policy setting.
ms.assetid: aec1220d-a875-4575-9050-f02f9c54a3b6
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Password Policy
**Applies to**
- Windows 10
An overview of password policies for Windows and links to information for each policy setting.
In many operating systems, the most common method to authenticate a user's identity is to use a secret passphrase or password. A secure network environment requires all users to use strong passwords, which have at least eight characters and include a combination of letters, numbers, and symbols. These passwords help prevent the compromise of user accounts and administrative accounts by unauthorized users who use manual methods or automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a successful password attack.
Introduced in Windows Server 2008 R2 and Windows Server 2008, Windows supports fine-grained password policies. This feature provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups.
To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.
Fine-grained password policies include attributes for all the settings that can be defined in the default domain policy (except Kerberos settings) in addition to account lockout settings. When you specify a fine-grained password policy, you must specify all of these settings. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain must be running at least Windows Server 2008 R2 or Windows Server 2008 to use fine-grained password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly.
You can enforce the use of strong passwords through an appropriate password policy. There are password policy settings that control the complexity and lifetime of passwords, such as the **Passwords must meet complexity requirements** policy setting.
You can configure the password policy settings in the following location by using the Group Policy Management Console:
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Password Policy**
If individual groups require distinct password policies, these groups should be separated into another domain or forest, based on additional requirements.
The following topics provide a discussion of password policy implementation and best practices considerations, policy location, default values for the server type or GPO, relevant differences in operating system versions, security considerations (including the possible vulnerabilities of each setting), countermeasures that you can take, and the potential impact for each setting.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Enforce password history](enforce-password-history.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Enforce password history</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Maximum password age](maximum-password-age.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum password age</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Minimum password age](minimum-password-age.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Minimum password age</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Minimum password length](minimum-password-length.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Minimum password length</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Password must meet complexity requirements](password-must-meet-complexity-requirements.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Password must meet complexity requirements</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Store passwords using reversible encryption](store-passwords-using-reversible-encryption.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Store passwords using reversible encryption</strong> security policy setting.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Enforce password history](enforce-password-history.md)| Describes the best practices, location, values, policy management, and security considerations for the **Enforce password history** security policy setting.|
| [Maximum password age](maximum-password-age.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum password age** security policy setting.|
| [Minimum password age](minimum-password-age.md) | Describes the best practices, location, values, policy management, and security considerations for the **Minimum password age** security policy setting.|
| [Minimum password length](minimum-password-length.md) | Describes the best practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting.|
| [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) | Describes the best practices, location, values, and security considerations for the **Password must meet complexity requirements** security policy setting.|
| [Store passwords using reversible encryption](store-passwords-using-reversible-encryption.md) | Describes the best practices, location, values, and security considerations for the **Store passwords using reversible encryption** security policy setting.|
 
## Related topics
[Configure security policy settings](how-to-configure-security-policy-settings.md)
- [Configure security policy settings](how-to-configure-security-policy-settings.md)
 
 

86
windows/keep-secure/perform-volume-maintenance-tasks.md
View File

@ -2,89 +2,91 @@
title: Perform volume maintenance tasks (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Perform volume maintenance tasks security policy setting.
ms.assetid: b6990813-3898-43e2-8221-c9c06d893244
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Perform volume maintenance tasks
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Perform volume maintenance tasks** security policy setting.
## Reference
This policy setting determines which users can perform volume or disk management tasks, such as defragmenting an existing volume, creating or removing volumes, and running the Disk Cleanup tool.
Use caution when assigning this user right. Users with this user right can explore disks and extend files in to memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data.
Constant: SeManageVolumePrivilege
### Possible values
- User-defined list of accounts
- Not Defined
### Best practices
- Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right.
### 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>DC 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|
| DC 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 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
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 the **Perform volume maintenance tasks** user right could delete a volume, which could result in the loss of data or a denial-of- service condition. Also, disk maintenance tasks can be used to modify data on the disk, such as user rights assignments that might lead to escalation of privileges.
### Countermeasure
Ensure that only the local Administrators group is assigned the **Perform volume maintenance tasks** user right.
### Potential impact
None. Restricting the **Perform volume maintenance tasks** user right to the local Administrators group is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

53
windows/keep-secure/plan-for-applocker-policy-management.md
View File

@ -2,71 +2,112 @@
title: Plan for AppLocker policy management (Windows 10)
description: This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
ms.assetid: dccc196f-6ae0-4ae4-853a-a3312b18751b
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Plan for AppLocker policy management
**Applies to**
- Windows 10
This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
## Policy management
Before you begin the deployment process, consider how the AppLocker rules will be managed. Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control how applications are allowed to run in your organization.
### Application and user support policy
Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively control how applications are allowed to run in your organization. Considerations include:
- What type of end-user support is provided for blocked applications?
- How are new rules added to the policy?
- How are existing rules updated?
- Are events forwarded for review?
**Help desk support**
If your organization has an established help desk support department in place, consider the following when deploying AppLocker policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
- How will the support department resolve application control issues between the end user and those who maintain the AppLocker rules?
**End-user support**
Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
**Using an intranet site**
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default URL is used.
The following image shows an example of the error message for a blocked app. You can use the **Set a support web link** policy setting to customize the **More information** link.
![applocker blocked application error message](images/blockedappmsg.gif)
For steps to display a custom URL for the message, see [Display a custom URL message when users try to run a blocked app](display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md).
**AppLocker event management**
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The AppLocker event log is located in the following path: **Applications and Services Logs\\Microsoft\\Windows\\AppLocker**. The AppLocker log includes three logs:
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The
AppLocker event log is located in the following path: **Applications and Services Logs\\Microsoft\\Windows\\AppLocker**. The AppLocker log includes three logs:
1. **EXE and DLL**. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll, and .ocx).
2. **MSI and Script**. Contains events for all files affected by the Windows Installer and script rule collections (.msi, .msp, .ps1, .bat, .cmd, .vbs, and .js).
3. **Packaged app-Deployment** or **Packaged app-Execution**, contains events for all Universal Windows apps affected by the packaged app and packed app installer rule collection (.appx).
Collecting these events in a central location can help you maintain your AppLocker policy and troubleshoot rule configuration problems. Event collection technologies such as those available in Windows allow administrators to subscribe to specific event channels and have the events from source computers aggregated into a forwarded event log on a Windows Server operating system collector. For more info about setting up an event subscription, see [Configure Computers to Collect and Forward Events](http://go.microsoft.com/fwlink/p/?LinkId=145012).
### Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions to your rule collections to ensure that the policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](http://go.microsoft.com/fwlink/p/?LinkId=145013) (http://go.microsoft.com/fwlink/p/?LinkId=145013).
**Caution**  
You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
>**Caution:**  You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
 
**New version of a supported app**
When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you are using publisher conditions and the version is not specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app has not altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path has not changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
**Recently deployed app**
To support a new app, you must add one or more rules to the existing AppLocker policy.
**App is no longer supported**
If your organization has determined that it will no longer support an application that has AppLocker rules associated with it, the easiest way to prevent users from running the app is to delete these rules.
**App is blocked but should be allowed**
A file could be blocked for three reasons:
- The most common reason is that no rule exists to allow the app to run.
- There may be an existing rule that was created for the file that is too restrictive.
- A deny rule, which cannot be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can troubleshoot the problem by using the **Test-AppLockerPolicy** Windows PowerShell cmdlet. For more info about troubleshooting an AppLocker policy, see [Testing and Updating an AppLocker Policy](http://go.microsoft.com/fwlink/p/?LinkId=160269) (http://go.microsoft.com/fwlink/p/?LinkId=160269).
## Next steps
After deciding how your organization will manage your AppLocker policy, record your findings.
- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the AppLocker policy, if necessary.
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
- **Policy maintenance.** Detail how rules will be added to the policy and in which GPO the rules are defined.
For information and steps how to document your processes, see [Document your application control management processes](document-your-application-control-management-processes.md).
 
 

295
windows/keep-secure/planning-and-deploying-advanced-security-audit-policies.md
View File

@ -2,290 +2,283 @@
title: Planning and deploying advanced security audit policies (Windows 10)
description: This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
ms.assetid: 7428e1db-aba8-407b-a39e-509671e5a442
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Planning and deploying advanced security audit policies
**Applies to**
- Windows 10
This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
This topic for the IT professional explains the options that security policy planners must consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit
policies.
Organizations invest a large portion of their information technology budgets on security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on your data, you should not consider the job complete unless you have a well-defined, timely auditing strategy to track the effectiveness of your defenses and identify attempts to circumvent them.
To be well defined and timely, an auditing strategy must provide useful tracking data for an organization's most important resources, critical behaviors, and potential risks. In a growing number of organizations, it must also provide absolute proof that IT operations comply with corporate and regulatory requirements.
Unfortunately, no organization has unlimited resources to monitor every resource and activity on a network. If you do not plan well, you will likely have gaps in your auditing strategy. However, if you try to audit every resource and activity, you may find yourself with far too much monitoring data, including thousands of benign audit entries that an analyst needs to sift through to identify the narrow set of entries that warrant closer examination. This could cause delays or even prevent auditors from identifying suspicious activity. Thus, too much monitoring can leave an organization as vulnerable as not enough monitoring.
Here are some features that can help you focus your effort:
- **Advanced audit policy settings**. You can apply and manage detailed audit policy settings through Group Policy.
- **"Reason for access" auditing**. You can specify and identify the permissions that were used to generate a particular object access security event.
- **Global object access auditing**. You can define system access control lists (SACLs) for an entire computer file system or registry.
To deploy these features and plan an effective security auditing strategy, you need to:
- Identify your most critical resources and the most important activities that need to be tracked.
- Identify the audit settings that can be used to track these activities.
- Assess the advantages and potential costs associated with each.
- Test these settings to validate your choices.
- Develop plans for deploying and managing your audit policy.
## About this guide
This document will guide you through the steps needed to plan a security auditing policy that uses Windows auditing features. This policy must identify and address vital business needs, including:
- Network reliability
- Regulatory requirements
- Protection of the organization's data and intellectual property
- Users, including employees, contractors, partners, and customers
- Client computers and applications
- Servers and the applications and services running on those servers
The audit policy also must identify processes for managing audit data after it has been logged, including:
- Collecting, evaluating, and reviewing audit data
- Storing and (if required) disposing of audit data
By carefully planning, designing, testing, and deploying a solution based on your organization's business requirements, you can provide the standardized functionality, security, and management control that your organization needs.
## Understanding the security audit policy design process
The process of designing and deploying a Windows security audit policy involves the following tasks, which are described in greater detail throughout this document:
- [Identifying your Windows security audit policy deployment goals](#bkmk-1)
This section helps define the business objectives that will guide your Windows security audit policy. It also helps you define the resources, users, and computers that will be the focus of your security auditing.
- [Mapping the security audit policy to groups of users, computers, and resources in your organization](#bkmk-2)
This section explains how to integrate security audit policy settings with domain Group Policy settings for different groups of users, computers, and resources. In addition, if your network includes multiple versions of Windows client and server operating systems, it also explains when to use basic audit policy settings and when to use advanced security audit policy settings.
- [Mapping your security auditing goals to a security audit policy configuration](#bkmk-3)
This section explains the categories of Windows security auditing settings that are available. It also identifies individual Windows security auditing policy settings that can be of particular value to address auditing scenarios.
- [Planning for security audit monitoring and management](#bkmk-4)
This section helps you plan to collect, analyze, and store Windows audit data. Depending on the number of computers and types of activity that you want to audit, Windows event logs can fill up quickly. In addition, this section explains how auditors can access and aggregate event data from multiple servers and desktop computers. It also explains how to address storage requirements, including how much audit data to store and how it must be stored.
- [Deploying the security audit policy](#bkmk-5)
This section provides recommendations and guidelines for the effective deployment of a Windows security audit policy. Configuring and deploying Windows audit policy settings in a test lab environment can help you confirm that the settings you have selected will produce the type of audit data you need. However, only a carefully staged pilot and incremental deployments based on your domain and organizational unit (OU) structure will enable you to confirm that the audit data you generate can be monitored and that it meets your organization's audit needs.
## <a href="" id="bkmk-1"></a>Identifying your Windows security audit policy deployment goals
A security audit policy must support and be a critical and integrated aspect of an organization's overall security design and framework.
Every organization has a unique set of data and network assets (such as customer and financial data and trade secrets), physical resources (such as desktop computers, portable computers, and servers), and users (which can include various internal groups such as finance and marketing, and external groups such as partners, customers, and anonymous users on the website). Not all of these assets, resources, and users justify the cost of an audit. Your task is to identify which assets, resources, and users provide the strongest justification for the focus of a security audit.
To create your Windows security audit plan, begin by identifying:
- The overall network environment, including the domains, OUs, and security groups.
- The resources on the network, the users of those resources, and how those resources are being used.
- Regulatory requirements.
### Network environment
An organization's domain and OU structure provide a fundamental starting point for thinking about how to apply a security audit policy because it likely provides a foundation of Group Policy Objects (GPOs) and logical grouping of resources and activities that you can use to apply the audit settings that you choose. It is also likely that certain portions of your domain and OU structure already provide logical groups of users, resources, and activities that justify the time and resources needed to audit them. For information about how to integrate a security audit policy with your domain and OU structure, see [Mapping security audit policy to groups of users, computers, and resources in your organization](#bkmk-2) later in this document.
In addition to your domain model, you should also find out whether your organization creates and maintains a systematic threat model. A good threat model can help you identify threats to key components in your infrastructure, so you can define and apply audit settings that enhance the organization's ability to identify and counter those threats.
**Important**  
Including auditing within your organization's security plan also makes it possible to budget your resources on the areas where auditing can achieve the most positive results.
>**Important:**  Including auditing within your organization's security plan also makes it possible to budget your resources on the areas where auditing can achieve the most positive results.
 
For additional details about how to complete each of these steps and how to prepare a detailed threat model, download the [IT Infrastructure Threat Modeling Guide](http://go.microsoft.com/fwlink/p/?LinkId=163432).
### Data and resources
For data and resource auditing, you need to identify the most important types of data and resources (such as patient records, accounting data, or marketing plans) that can benefit from the closer monitoring that Windows auditing can provide. Some of these data resources might already be monitored through auditing features in products such as Microsoft SQL Server and Exchange Server. If so, you may want to consider how Windows auditing features can enhance the existing audit strategy. As with the domain and OU structure discussed previously, security auditing should focus on your most critical resources. You also must consider how much audit data you will be able to manage.
You can record if these resources have high business impact, medium business impact, or low business impact, the cost to the organization if these data resources are accessed by unauthorized users, and the risk that this access can pose to the organization. The type of access by users (such as Read, Modify, or Copy) can also pose different levels of risk to an organization.
Increasingly, data access and use is governed by regulations, and a breach can result in severe penalties and a loss in credibility for the organization. If regulatory compliance plays a role in how you manage your data, be sure to also document this information.
The following table provides an example of a resource analysis for an organization.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Resource class</th>
<th align="left">Where stored</th>
<th align="left">Organizational unit</th>
<th align="left">Business impact</th>
<th align="left">Security or regulatory requirements</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Payroll data</p></td>
<td align="left"><p>Corp-Finance-1</p></td>
<td align="left"><p>Accounting: Read/Write on Corp-Finance-1</p>
<p>Departmental Payroll Managers: Write only on Corp-Finance-1</p></td>
<td align="left"><p>High</p></td>
<td align="left"><p>Financial integrity and employee privacy</p></td>
</tr>
<tr class="even">
<td align="left"><p>Patient medical records</p></td>
<td align="left"><p>MedRec-2</p></td>
<td align="left"><p>Doctors and Nurses: Read/Write on Med/Rec-2</p>
<p>Lab Assistants: Write only on MedRec-2</p>
<p>Accounting: Read only on MedRec-2</p></td>
<td align="left"><p>High</p></td>
<td align="left"><p>Strict legal and regulatory standards</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Consumer health information</p></td>
<td align="left"><p>Web-Ext-1</p></td>
<td align="left"><p>Public Relations Web Content Creators: Read/Write on Web-Ext-1</p>
<p>Public: Read only on Web-Ext-1</p></td>
<td align="left"><p>Low</p></td>
<td align="left"><p>Public education and corporate image</p></td>
</tr>
</tbody>
</table>
| Resource class | Where stored | Organizational unit | Business impact | Security or regulatory requirements |
| - | - | - | - | - |
| Payroll data| Corp-Finance-1| Accounting: Read/Write on Corp-Finance-1<br/>Departmental Payroll Managers: Write only on Corp-Finance-1| High| Financial integrity and employee privacy|
| Patient medical records| MedRec-2| Doctors and Nurses: Read/Write on Med/Rec-2<br/>Lab Assistants: Write only on MedRec-2<br/>Accounting: Read only on MedRec-2| High| Strict legal and regulatory standards|
| Consumer health information| Web-Ext-1| Public Relations Web Content Creators: Read/Write on Web-Ext-1<br/>Public: Read only on Web-Ext-1| Low| Public education and corporate image|
 
### Users
Many organizations find it useful to classify the types of users they have and base permissions on this classification. This same classification can help you identify which user activities should be the subject of security auditing and the amount of audit data they will generate.
Organizations can create distinctions based on the type of rights and permissions needed by users to perform their jobs. For example, under the classification Administrators, larger organizations might assign local administrator responsibilities for a single computer, for specific applications such as Exchange Server or SQL Server, or for an entire domain. Under Users, permissions and Group Policy settings can apply to as many as all users in an organization or as few as a subset of the employees in a given department.
Also, if your organization is subject to regulatory requirements, user activities such as accessing medical records or financial data may need to be audited to verify that you are complying with these requirements.
To effectively audit user activity, begin by listing the different types of users in your organization and the types of data they need access to—in addition to the data they should not have access to.
Also, if external users can access any of your organization's data, be sure to identify them, including if they belong to a business partner, customer, or general user, the data they have access to, and the permissions they have to access that data.
The following table illustrates an analysis of users on a network. Although our example contains a single column titled "Possible auditing considerations," you may want to create additional columns to differentiate between different types of network activity, such as logon hours and permission use.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Groups</th>
<th align="left">Data</th>
<th align="left">Possible auditing considerations</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Account administrators</p></td>
<td align="left"><p>User accounts and security groups</p></td>
<td align="left"><p>Account administrators have full privileges to create new user accounts, reset passwords, and modify security group memberships. We need a mechanism to monitor these changes.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Members of the Finance OU</p></td>
<td align="left"><p>Financial records</p></td>
<td align="left"><p>Users in Finance have Read/Write access to critical financial records, but no ability to change permissions on these resources. These financial records are subject to government regulatory compliance requirements.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>External partners</p></td>
<td align="left"><p>Project Z</p></td>
<td align="left"><p>Employees of partner organizations have Read/Write access to certain project data and servers relating to Project Z, but not to other servers or data on the network.</p></td>
</tr>
</tbody>
</table>
| Groups | Data | Possible auditing considerations |
| - | - | - |
| Account administrators| User accounts and security groups| Account administrators have full privileges to create new user accounts, reset passwords, and modify security group memberships. We need a mechanism to monitor these changes. |
| Members of the Finance OU| Financial records| Users in Finance have Read/Write access to critical financial records, but no ability to change permissions on these resources. These financial records are subject to government regulatory compliance requirements. |
| External partners | Project Z| Employees of partner organizations have Read/Write access to certain project data and servers relating to Project Z, but not to other servers or data on the network.|
 
### Computers
Security and auditing requirements and audit event volume can vary considerably for different types of computers in an organization. These requirements can be based on:
- If the computers are servers, desktop computers, or portable computers.
- The important applications the computers run, such as Exchange Server, SQL Server, or Forefront Identity Manager.
**Note**  
If the server applications (including Exchange Server and SQL Server) have audit settings. For more information about auditing in Exchange Server, see the [Exchange 2010 Security Guide](http://go.microsoft.com/fwlink/p/?linkid=128052). For more information about auditing in SQL Server 2008, see [Auditing (Database Engine)](http://go.microsoft.com/fwlink/p/?LinkId=163434). For SQL Server 2012, see [SQL Server Audit (Database Engine)](http://technet.microsoft.com/library/cc280386.aspx).
>**Note:**  If the server applications (including Exchange Server and SQL Server) have audit settings. For more information about auditing in Exchange Server, see the [Exchange 2010 Security Guide](http://go.microsoft.com/fwlink/p/?linkid=128052). For more information about auditing in SQL Server 2008, see [Auditing (Database Engine)](http://go.microsoft.com/fwlink/p/?LinkId=163434). For SQL Server 2012, see [SQL Server Audit (Database Engine)](http://technet.microsoft.com/library/cc280386.aspx).
 
- The operating system versions.
**Note**  
The operating system version determines which auditing options are available and the volume of audit event data.
>**Note:**  The operating system version determines which auditing options are available and the volume of audit event data.
 
- The business value of the data.
For example, a web server that is accessed by external users requires different audit settings than a root certification authority (CA) that is never exposed to the public Internet or even to regular users on the organization's network.
The following table illustrates an analysis of computers in an organization.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Type of computer and applications</th>
<th align="left">Operating system version</th>
<th align="left">Where located</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Servers hosting Exchange Server</p></td>
<td align="left"><p>Windows Server 2008 R2</p></td>
<td align="left"><p>ExchangeSrv OU</p></td>
</tr>
<tr class="even">
<td align="left"><p>File servers</p></td>
<td align="left"><p>Windows Server 2012</p></td>
<td align="left"><p>Separate resource OUs by department and (in some cases) by location</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Portable computers</p></td>
<td align="left"><p>Windows Vista and Windows 7</p></td>
<td align="left"><p>Separate portable computer OUs by department and (in some cases) by location</p></td>
</tr>
<tr class="even">
<td align="left"><p>Web servers</p></td>
<td align="left"><p>Windows Server 2008 R2</p></td>
<td align="left"><p>WebSrv OU</p></td>
</tr>
</tbody>
</table>
| Type of computer and applications | Operating system version | Where located |
| - | - | - |
| Servers hosting Exchange Server| Windows Server 2008 R2| ExchangeSrv OU|
| File servers | Windows Server 2012| Separate resource OUs by department and (in some cases) by location|
| Portable computers | Windows Vista and Windows 7| Separate portable computer OUs by department and (in some cases) by location|
| Web servers | Windows Server 2008 R2 | WebSrv OU|
 
### Regulatory requirements
Many industries and locales have strict and specific requirements for network operations and how resources are protected. In the health care and financial industries, for example, there are strict guidelines for who has access to records and how they are used. Many countries have strict privacy rules. To identify regulatory requirements, work with your organization's legal department and other departments responsible for these requirements. Then consider the security configuration and auditing options that can be used to comply with and verify compliance with these regulations.
For more info, see the [System Center Process Pack for IT GRC](http://technet.microsoft.com/library/dd206732.aspx).
## <a href="" id="bkmk-2"></a>Mapping the security audit policy to groups of users, computers, and resources in your organization
By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources. To map a security auditing policy to these defined groups in your organization, you should understand the following considerations for using Group Policy to apply security audit policy settings:
By using Group Policy, you can apply your security audit policy to defined groups of users, computers, and resources. To map a security auditing policy to these defined groups in your organization, you should understand the
following considerations for using Group Policy to apply security audit policy settings:
- The policy settings you identify can be applied by using one or more GPOs. To create and edit a GPO, use the Group Policy Management Console (GPMC). By using the GPMC to link a GPO to selected Active Directory sites, domains, and OUs, you apply the policy settings in the GPO to the users and computers in those Active Directory objects. An OU is the lowest-level Active Directory container to which you can assign Group Policy settings.
- For every policy setting that you select, you need to decide whether it should be enforced across the organization, or whether it should apply only to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers.
- By default, options set in GPOs that are linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, a GPO that is linked at a lower level can overwrite inherited policies.
For example, you might use a domain GPO to assign an organization-wide group of audit settings, but want a certain OU to get a defined group of additional settings. To accomplish this, you can link a second GPO to that specific lower-level OU. Therefore, a logon audit setting that is applied at the OU level will override a conflicting logon audit setting that is applied at the domain level (unless you have taken special steps to apply Group Policy loopback processing).
- Audit policies are computer policies. Therefore, they must be applied through GPOs that are applied to computer OUs, not to user OUs. However, in most cases you can apply audit settings for only specified resources and groups of users by configuring SACLs on the relevant objects. This enables auditing for a security group that contains only the users you specify.
For example, you could configure a SACL for a folder called Payroll Data on Accounting Server 1. This can audit attempts by members of the Payroll Processors OU to delete objects from this folder. The **Object Access\\Audit File System** audit policy setting applies to Accounting Server 1, but because it requires a corresponding resource SACL, only actions by members of the Payroll Processors OU on the Payroll Data folder generates audit events.
- Advanced security audit policy settings were introduced in Windows Server 2008 R2 or Windows 7 and can be applied to those operating systems and later. These advanced audit polices can only be applied by using Group Policy.
**Important**  
Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both basic and advanced audit policy settings can cause unexpected results in audit reporting.
>**Important:**  Whether you apply advanced audit policies by using Group Policy or by using logon scripts, do not use both the basic audit policy settings under **Local Policies\\Audit Policy** and the advanced settings under **Security Settings\\Advanced Audit Policy Configuration**. Using both basic and advanced audit policy settings can cause unexpected results in audit reporting.
If you use **Advanced Audit Policy Configuration** settings or use logon scripts to apply advanced audit policies, be sure to enable the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** policy setting under **Local Policies\\Security Options**. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored.
 
The following are examples of how audit policies can be applied to an organization's OU structure:
- Apply data activity settings to an OU that contains file servers. If your organization has servers that contain particularly sensitive data, consider putting them in a separate OU so that you can configure and apply a more precise audit policy to these servers.
- Apply user activity audit policies to an OU that contains all computers in the organization. If your organization places users in OUs based on the department they work in, consider configuring and applying more detailed security permissions on critical resources that are accessed by employees who work in more sensitive areas, such as network administrators or the legal department.
- Apply network and system activity audit policies to OUs that contain the organization's most critical servers, such as domain controllers, CAs, email servers, or database servers.
## <a href="" id="bkmk-3"></a>Mapping your security auditing goals to a security audit policy configuration
After you identify your security auditing goals, you can begin to map them to a security audit policy configuration. This audit policy configuration must address your most critical security auditing goals, but it also must address your organization's constraints, such as the number of computers that need to be monitored, the number of activities that you want to audit, the number of audit events that your desired audit configuration will generate, and the number of administrators available to analyze and act upon audit data.
To create your audit policy configuration, you need to:
1. Explore all of the audit policy settings that can be used to address your needs.
2. Choose the audit settings that will most effectively address the audit requirements identified in the previous section.
3. Confirm that the settings you choose are compatible with the operating systems running on the computers that you want to monitor.
4. Decide which configuration options (Success, Failure, or both Success and Failure) you want to use for the audit settings.
5. Deploy the audit settings in a lab or test environment to verify that they meet your desired results in terms of volume, supportability, and comprehensiveness. Then deploy the audit settings in a pilot production environment to ensure that your estimates of how much audit data your audit plan will generate are realistic and that you can manage this data.
### Exploring audit policy options
Security audit policy settings in the supported versions of Windows can be viewed and configured in the following locations:
- **Security Settings\\Local Policies\\Audit Policy**.
- **Security Settings\\Local Policies\\Security Options**.
- **Security Settings\\Advanced Audit Policy Configuration**. For more information, see [Advanced security audit policy settings](advanced-security-audit-policy-settings.md).
### Choosing audit settings to use
Depending on your goals, different sets of audit settings may be of particular value to you. For example, some settings under **Security Settings\\Advanced Audit Policy Configuration** can be used to monitor the following types of activity:
- Data and resources
- Users
- Network
**Important**  
Settings that are described in the Reference might also provide valuable information about activity audited by another setting. For example, the settings used to monitor user activity and network activity have obvious relevance to protecting your data resources. Likewise, attempts to compromise data resources have huge implications for overall network status, and potentially for how well you are managing the activities of users on the network.
>**Important:**  Settings that are described in the Reference might also provide valuable information about activity audited by another setting. For example, the settings used to monitor user activity and network activity have obvious relevance to protecting your data resources. Likewise, attempts to compromise data resources have huge implications for overall network status, and potentially for how well you are managing the activities of users on the network.
 
### Data and resource activity
For many organizations, compromising the organization's data resources can cause tremendous financial losses, in addition to lost prestige and legal liability. If your organization has critical data resources that need to be protected against any breach, the following settings can provide extremely valuable monitoring and forensic data:
For many organizations, compromising the organization's data resources can cause tremendous financial losses, in addition to lost prestige and legal liability. If your organization has critical data resources that need to be
protected against any breach, the following settings can provide extremely valuable monitoring and forensic data:
- Object Access\\[Audit File Share](audit-file-share.md). This policy setting allows you to track what content was accessed, the source (IP address and port) of the request, and the user account that was used for the access. The volume of event data generated by this setting will vary depending on the number of client computers that attempt to access the file share. On a file server or domain controller, volume may be high due to SYSVOL access by client computers for policy processing. If you do not need to record routine access by client computers that have permissions on the file share, you may want to log audit events only for failed attempts to access the file share.
- Object Access\\[Audit File System](audit-file-system.md). This policy setting determines whether the operating system audits user attempts to access file system objects. Audit events are only generated for objects (such as files and folders) that have configured SACLs, and only if the type of access requested (such as Write, Read, or Modify) and the account that is making the request match the settings in the SACL.
If success auditing is enabled, an audit entry is generated each time any account successfully accesses a file system object that has a matching SACL. If failure auditing is enabled, an audit entry is generated each time any user unsuccessfully attempts to access a file system object that has a matching SACL. The amount of audit data generated by the **Audit File System** policy setting can vary considerably, depending on the number of objects that have been configured to be monitored.
**Note**  
To audit user attempts to access all file system objects on a computer, use the Global Object Access Auditing settings [Registry (Global Object Access Auditing)](registry-global-object-access-auditing.md) or [File System (Global Object Access Auditing)](file-system-global-object-access-auditing.md).
>**Note:**  To audit user attempts to access all file system objects on a computer, use the Global Object Access Auditing settings [Registry (Global Object Access Auditing)](registry-global-object-access-auditing.md) or [File System (Global Object Access Auditing)](file-system-global-object-access-auditing.md).
 
- Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md). This policy setting determines whether the operating system generates audit events when a handle to an object is opened or closed. Only objects with configured SACLs generate these events, and only if the attempted handle operation matches the SACL.
Event volume can be high, depending on how SACLs are configured. When used together with the **Audit File System** or **Audit Registry** policy settings, the **Audit Handle Manipulation** policy setting can provide an administrator with useful "reason for access" audit data that details the precise permissions on which the audit event is based. For example, if a file is configured as a Read-only resource but a user attempts to save changes to the file, the audit event will log not only the event, but also the permissions that were used (or attempted to be used) to save the file changes.
- **Global Object Access Auditing**. A growing number of organizations are using security auditing to comply with regulatory requirements that govern data security and privacy. But demonstrating that strict controls are being enforced can be extremely difficult. To address this issue, the supported versions of Windows include two **Global Object Access Auditing** policy settings, one for the registry and one for the file system. When you configure these settings, they apply a global system access control SACL on all objects of that class on a system, which cannot be overridden or circumvented.
**Important**  
The **Global Object Access Auditing** policy settings must be configured and applied in conjunction with the **Audit File System** and **Audit Registry** audit policy settings in the **Object Access** category.
>**Important:**  The **Global Object Access Auditing** policy settings must be configured and applied in conjunction with the **Audit File System** and **Audit Registry** audit policy settings in the **Object Access** category.
 
### User activity
The settings in the previous section relate to activity involving the files, folders, and network shares that are stored on a network, and the settings in this section focus on the users, including employees, partners, and customers, who may try to access those resources.
In the majority of cases, these attempts will be legitimate and a network needs to make vital data readily available to legitimate users. However in other cases, employees, partners, and others may attempt to access resources that they have no legitimate reason to access. Security auditing can be used to track a wide variety of user activities on a particular computer to diagnose and resolve problems for legitimate users and identify and address illegitimate activities. The following are a few important settings that you should evaluate to track user activity on your network:
- Account Logon\\[Audit Credential Validation](audit-credential-validation.md). This is an extremely important policy setting because it enables you to track every successful and unsuccessful attempt to present credentials for a user logon. In particular, a pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer valid, or attempting to use a variety of credentials in succession in hope that one of these attempts will eventually be successful. These events occur on the computer that is authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
- Detailed Tracking\\[Audit Process Creation](audit-process-creation.md) and Detailed Tracking\\[Audit Process Termination](audit-process-termination.md). These policy settings can enable you to monitor the applications that a user opens and closes on a computer.
- DS Access\\[Audit Directory Service Access](audit-directory-service-access.md) and DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md). These policy settings provide a detailed audit trail of attempts to access create, modify, delete, move, or undelete objects in Active Directory Domain Services (AD DS). Only domain administrators have permissions to modify AD DS objects, so it is extremely important to identify malicious attempts to modify these objects. In addition, although domain administrators should be among an organization's most trusted employees, the use of **Audit Directory Service Access** and **Audit Directory Service Changes** settings allow you to monitor and verify that only approved changes are made to AD DS. These audit events are logged only on domain controllers.
- Logon/Logoff\\[Audit Account Lockout](audit-account-lockout.md). Another common security scenario occurs when a user attempts to log on with an account that has been locked out. It is important to identify these events and to determine whether the attempt to use an account that has been locked out is malicious.
- Logon/Logoff\\[Audit Logoff](audit-logoff.md) and Logon/Logoff\\[Audit Logon](audit-logon.md). Logon and logoff events are essential to tracking user activity and detecting potential attacks. Logon events are related to the creation of logon sessions, and they occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a shared resource, events are generated on the computer that hosts the resource that was accessed. Logoff events are generated when logon sessions are terminated.
**Note**  
There is no failure event for logoff activity because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record. Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown, and a logoff event is not generated.
>**Note:**  There is no failure event for logoff activity because failed logoffs (such as when a system abruptly shuts down) do not generate an audit record. Logoff events are not 100 percent reliable. For example, the computer can be turned off without a proper logoff and shutdown, and a logoff event is not generated.
 
- Logon/Logoff\\[Audit Special Logon](audit-special-logon.md). A special logon has administrator-equivalent rights and can be used to elevate a process to a higher level. It is recommended to track these types of logons. For more information about this feature, see [article 947223](http://go.microsoft.com/fwlink/p/?linkid=120183) in the Microsoft Knowledge Base.
- Object Access\\[Audit Certification Services](audit-certification-services.md). This policy setting allows you to track and monitor a wide variety of activities on a computer that hosts Active Directory Certificate Services (AD CS) role services to ensure that only authorized users are performing or attempting to perform these tasks, and that only authorized or desired tasks are being performed.
- Object Access\\[Audit File System](audit-file-system.md) and Object Access\\[Audit File Share](audit-file-share.md). These policy settings are described in the previous section.
- Object Access\\[Audit Handle Manipulation](audit-handle-manipulation.md). This policy setting and its role in providing "reason for access" audit data is described in the previous section.
- Object Access\\[Audit Registry](audit-registry.md). Monitoring for changes to the registry is one of the most critical means that an administrator has to ensure malicious users do not make changes to essential computer settings. Audit events are only generated for objects that have configured SACLs, and only if the type of access that is requested (such as Write, Read, or Modify) and the account making the request match the settings in the SACL.
**Important**  
On critical systems where all attempts to change registry settings need to be tracked, you can combine the **Audit Registry** policy setting with the **Global Object Access Auditing** policy settings to ensure that all attempts to modify registry settings on a computer are tracked.
>**Important:**  On critical systems where all attempts to change registry settings need to be tracked, you can combine the **Audit Registry** policy setting with the **Global Object Access Auditing** policy settings to ensure that all attempts to modify registry settings on a computer are tracked.
 
- Object Access\\[Audit SAM](audit-sam.md). The Security Accounts Manager (SAM) is a database that is present on computers running Windows that stores user accounts and security descriptors for users on the local computer. Changes to user and group objects are tracked by the **Account Management** audit category. However, user accounts with the proper user rights could potentially alter the files where the account and password information is stored in the system, bypassing any **Account Management** events.
- Privilege Use\\[Audit Sensitive Privilege Use](audit-sensitive-privilege-use.md). **Privilege Use** policy settings and audit events allow you to track the use of certain rights on one or more systems. If you configure this policy setting, an audit event is generated when sensitive rights requests are made.
### Network activity
The following network activity policy settings allow you to monitor security-related issues that are not necessarily covered in the data or user activity categories, but that can be equally important for network status and protection.
- **Account Management**. The policy settings in this category can be used to track attempts to create, delete, or modify user or computer accounts, security groups, or distribution groups. Monitoring these activities complements the monitoring strategies you select in the user activity and data activity sections.
- Account Logon\\[Audit Kerberos Authentication Service](audit-kerberos-authentication-service.md) and Account Logon\\[Audit Kerberos Service Ticket Operations](audit-kerberos-service-ticket-operations.md). Audit policy settings in the **Account Logon** category monitor activities that relate to the use of domain account credentials. These policy settings complement the policy settings in the **Logon/Logoff** category. The **Audit Kerberos Authentication Service** policy setting allows you to monitor the status of and potential threats to the Kerberos service. The Audit **Kerberos Service Ticket Operations** policy setting allows you to monitor the use of Kerberos service tickets.
**Note**  
**Account Logon** policy settings apply only to specific domain account activities, regardless of the computer that is accessed, whereas **Logon/Logoff** policy settings apply to the computer that hosts the resources being accessed.
>**Note:**  **Account Logon** policy settings apply only to specific domain account activities, regardless of the computer that is accessed, whereas **Logon/Logoff** policy settings apply to the computer that hosts the resources being accessed.
 
- Account Logon\\[Audit Other Account Logon Events](audit-other-account-logon-events.md). This policy setting can be used to track a number of different network activities, including attempts to create Remote Desktop connections, wired network connections, and wireless connections.
- **DS Access**. Policy settings in this category allow you to monitor the AD DS role services, which provide account data, validate logons, maintain network access permissions, and provide other services that are critical to the secure and proper functioning of a network. Therefore, auditing the rights to access and modify the configuration of a domain controller can help an organization maintain a secure and reliable network. In addition, one of the key tasks performed by AD DS is the replication of data between domain controllers.
@ -295,41 +288,65 @@ The following network activity policy settings allow you to monitor security-rel
- Policy Change\\[Audit Audit Policy Change](audit-audit-policy-change.md). This policy setting allows you to monitor changes to the audit policy. If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit policy settings so that their other activities on the network cannot be detected.
- Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md). This policy setting can be used to monitor a large variety of changes to an organization's IPsec policies.
- Policy Change\\[Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md). This policy setting determines if the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe), which is used by Windows Firewall. Changes to firewall rules are important for understanding the security state of the computer and how well it is protected against network attacks.
### Confirm operating system version compatibility
Not all versions of Windows support advanced audit policy settings or the use of Group Policy to apply and manage these settings. For more info, see [Which editions of Windows support advanced audit policy configuration](which-editions-of-windows-support-advanced-audit-policy-configuration.md).
The audit policy settings under **Local Policies\\Audit Policy** overlap with audit policy settings under **Security Settings\\Advanced Audit Policy Configuration**. However, the advanced audit policy categories and subcategories make it possible to focus your auditing efforts on the most critical activities while reducing the amount of audit data that is less important to your organization.
For example, **Local Policies\\Audit Policy** contains a single setting called [Audit account logon events](http://technet.microsoft.com/library/cc787176.aspx). When this setting is configured, it generates at least 10 types of audit events.
In comparison, the Account Logon category under **Security Settings\\Advanced Audit Policy Configuration** provides the following advanced settings, which allow you to focus your auditing:
- Credential Validation
- Kerberos Authentication Service
- Kerberos Service Ticket Operations
- Other Account Logon Events
These settings allow you to exercise much tighter control over which activities or events generate event data. Some activities and events will be more important to your organization, so define the scope of your security audit policy as narrowly as possible.
### Success, failure, or both
Whichever event settings you include in your plan, you also have to decide whether you want to log an event when the activity fails, when an activity succeeds, or both successes and failures. This is an important question, and the answer will be based on the criticality of the event and the implications of the decision on event volume.
For example, on a file server that is accessed frequently by legitimate users, you may be interested in logging an event only when an unsuccessful attempt to access data takes place, because this could be evidence of an unauthorized or malicious user. And in this instance, logging successful attempts to access the server would quickly fill the event log with benign events.
On the other hand, if the file share has extremely sensitive and valuable information, such as trade secrets, you may want to log every access attempt, whether successful or unsuccessful, so that you have an audit trail of every user who accessed the resource.
## <a href="" id="bkmk-4"></a>Planning for security audit monitoring and management
Networks can contain hundreds of servers running critical services or storing critical data, all of which need to be monitored. The number of client computers on the network can easily range into the tens or even hundreds of thousands. This may not be an issue if the ratio of servers or client computers per administrator is low. Even if an administrator who is responsible for auditing security and performance issues has relatively few computers to monitor, you need to decide how an administrator will obtain event data to review. Following are some options for obtaining the event data.
- Will you keep event data on a local computer until an administrator logs on to review this data? If so, then the administrator needs to have physical or remote access to the Event Viewer on each client computer or server, and the remote access and firewall settings on each client computer or server need to be configured to enable this access. In addition, you need to decide how often an administrator can visit each computer, and adjust the size of the audit log so that critical information is not deleted if the log reaches its maximum capacity.
- Will you collect event data so that it can be reviewed from a central console? If so, there are a number of computer management products, such as the Audit Collection Services in Operations Manager 2007 and 2012, which can be used to collect and filter event data. Presumably this solution enables a single administrator to review larger amounts of data than using the local storage option. But in some cases, this can make it more difficult to detect clusters of related events that can occur on a single computer.
In addition, whether you choose to leave audit data on an individual computer or consolidate it at a central location, you need to decide how large the log file should be and what should happen when the log reaches its maximum size. To configure these options, open Event Viewer, expand **Windows Logs**, right-click **Security**, and click **Properties**. You can configure the following properties:
- **Overwrite events as needed (oldest events first)**. This is the default option, which is an acceptable solution in most situations.
- **Archive the log when full, do not overwrite events**. This option can be used when all log data needs to be saved, but it also suggests that you may not be reviewing audit data frequently enough.
- **Do not overwrite events (Clear logs manually)**. This option stops the collection of audit data when the log file reaches its maximum size. Older data is retained at the expense of the most recent audit events. Use this option only if you do not want to lose any audit data, do not want to create an archive of the event log, and are committed to reviewing data before the maximum log size is reached.
You can also configure the audit log size and other key management options by using Group Policy settings. You can configure the event log settings in the following locations within the GPMC: **Computer Configuration\\Administrative Templates\\Windows Components\\Event Log Service\\Security**. These options include:
You can also configure the audit log size and other key management options by using Group Policy settings. You can configure the event log settings in the following locations within the GPMC: **Computer
Configuration\\Administrative Templates\\Windows Components\\Event Log Service\\Security**. These options include:
- **Maximum Log Size (KB)**. This policy setting specifies the maximum size of the log files. The user interfaces in the Local Group Policy Editor and Event Viewer allow you to enter values as large as 2 TB. If this setting is not configured, event logs have a default maximum size of 20 megabytes.
- **Log Access**. This policy setting determines which user accounts have access to log files and what usage rights are granted.
- **Retain old events**. This policy setting controls event log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events are not written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.
- **Backup log automatically when full**. This policy setting controls event log behavior when the log file reaches its maximum size and takes effect only if the **Retain old events** policy setting is enabled. If you enable these policy settings, the event log file is automatically closed and renamed when it is full. A new file is then started. If you disable or do not configure this policy setting and the **Retain old events** policy setting is enabled, new events are discarded and the old events are retained.
In addition, a growing number of organizations are being required to store archived log files for a number of years. You should consult with regulatory compliance officers in your organization to determine whether such guidelines apply to your organization. For more information, see the [IT Compliance Management Guide](http://go.microsoft.com/fwlink/p/?LinkId=163435).
## <a href="" id="bkmk-5"></a>Deploying the security audit policy
Before deploying the audit policy in a production environment, it is critical that you determine the effects of the policy settings that you have configured.
The first step in assessing your audit policy deployment is to create a test environment in a lab and use it to simulate the various use scenarios that you have identified to confirm that the audit settings you have selected are configured correctly and generate the type of results you intend.
However, unless you are able to run fairly realistic simulations of network usage patterns, a lab setup cannot provide you with accurate information about the volume of audit data that the audit policy settings you selected will generate and how effective your plan for monitoring audit data will be. To provide this type of information, you need to conduct one or more pilot deployments. These pilot deployments could involve:
- A single OU that contains critical data servers or an OU that contains all desktop computers in a specified location.
- A limited set of security audit policy settings, such as **Logon/Logoff** and **Account Logon**.
- A combination of limited OUs and audit policy settings—for example, targeting servers in only the Accounting OU with **Object Access** policy settings.
After you have successfully completed one or more limited deployments, you should confirm that the audit data that is collected is manageable with your management tools and administrators. When you have confirmed that the pilot deployment is effective, you need to confirm that you have the necessary tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until the production deployment is complete.
 
 

286
windows/keep-secure/prepare-your-organization-for-bitlocker-planning-and-policies.md
View File

@ -2,17 +2,22 @@
title: Prepare your organization for BitLocker Planning and policies (Windows 10)
description: This topic for the IT professional explains how can you plan your BitLocker deployment.
ms.assetid: 6e3593b5-4e8a-40ac-808a-3fdbc948059d
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Prepare your organization for BitLocker: Planning and policies
**Applies to**
- Windows 10
This topic for the IT professional explains how can you plan your BitLocker deployment.
When you design your BitLocker deployment strategy, define the appropriate policies and configuration requirements based on the business requirements of your organization. The following topics will help you collect information that you can use to frame your decision-making process about deploying and managing BitLocker systems.
- [Audit your environment](#bkmk-audit)
- [Encryption keys and authentication](#bkk-encrypt)
- [TPM hardware configurations](#bkmk-tpmconfigurations)
@ -23,244 +28,203 @@ When you design your BitLocker deployment strategy, define the appropriate polic
- [Active Directory Domain Services considerations](#bkmk-addscons)
- [FIPS support for recovery password protector](#bkmk-fipssupport)
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
## <a href="" id="bkmk-audit"></a>Audit your environment
To plan your enterprise deployment of BitLocker, you must first understand your current environment. Conduct an informal audit to define your current policies, procedures, and hardware environment. Begin by reviewing your existing corporate security policies as they relate to disk encryption software. If your organization is not currently using disk encryption software, none of these policies will exist. If you are using disk encryption software, then you might need to modify your organization's policies to address the capabilities of BitLocker.
Use the following questions to help you document your organization's current disk encryption security policies:
1. Are there policies to address which computers will use BitLocker and which computers will not use BitLocker?
2. What policies exist to control recovery password and recovery key storage?
3. What are the policies for validating the identity of users that need to perform BitLocker recovery?
4. What policies exist to control who in the organization has access to recovery data?
5. What policies exist to control computer decommissioning or retirement?
## <a href="" id="bkk-encrypt"></a>Encryption keys and authentication
BitLocker helps prevent unauthorized access to data on lost or stolen computers by:
- Encrypting the entire Windows operating system volume on the hard disk.
- Verifying the boot process integrity.
The trusted platform module (TPM)is a hardware component installed in many newer computers by the computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system was offline.
In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal identification number (PIN) or inserts a removable USB device, such as a flash drive, that contains a startup key. These additional security measures provide multifactor authentication and assurance that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.
On computers that do not have a TPM version 1.2 or higher, you can still use BitLocker to encrypt the Windows operating system volume. However, this implementation will require the user to insert a USB startup key to start the computer or resume from hibernation, and does not provide the pre-startup system integrity verification offered by BitLocker working with a TPM.
**BitLocker key protectors**
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Key protector</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>TPM</p></td>
<td align="left"><p>A hardware device used to help establish a secure root-of-trust. BitLocker only supports TPM version 1.2 or higher.</p></td>
</tr>
<tr class="even">
<td align="left"><p>PIN</p></td>
<td align="left"><p>A user-entered numeric key protector that can only be used in addition to the TPM.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Enhanced PIN</p></td>
<td align="left"><p>A user-entered alphanumeric key protector that can only be used in addition to the TPM.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Startup key</p></td>
<td align="left"><p>An encryption key that can be stored on most removable media. This key protector can be used alone on non-TPM computers, or in conjunction with a TPM for added security.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Recovery password</p></td>
<td align="left"><p>A 48-digit number used to unlock a volume when it is in recovery mode. Numbers can often be typed on a regular keyboard, if the numbers on the normal keyboard are not responding you can always use the function keys (F1-F10) to input the numbers.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Recovery key</p></td>
<td align="left"><p>An encryption key stored on removable media that can be used for recovering data encrypted on a BitLocker volume.</p></td>
</tr>
</tbody>
</table>
| Key protector | Description |
| - | - |
| TPM | A hardware device used to help establish a secure root-of-trust. BitLocker only supports TPM version 1.2 or higher.|
| PIN | A user-entered numeric key protector that can only be used in addition to the TPM.|
| Enhanced PIN | A user-entered alphanumeric key protector that can only be used in addition to the TPM.|
| Startup key | An encryption key that can be stored on most removable media. This key protector can be used alone on non-TPM computers, or in conjunction with a TPM for added security.|
| Recovery password | A 48-digit number used to unlock a volume when it is in recovery mode. Numbers can often be typed on a regular keyboard, if the numbers on the normal keyboard are not responding you can always use the function keys (F1-F10) to input the numbers.|
| Recovery key| An encryption key stored on removable media that can be used for recovering data encrypted on a BitLocker volume.|
 
**BitLocker authentication methods**
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Authentication method</th>
<th align="left">Requires user interaction</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>TPM only</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>TPM validates early boot components.</p></td>
</tr>
<tr class="even">
<td align="left"><p>TPM + PIN</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>TPM validates early boot components. The user must enter the correct PIN before the start-up process can continue, and before the drive can be unlocked. The TPM will enter lockout if the incorrect PIN is entered repeatedly to protect the PIN from brute force attacks. The number of repeated attempts that will trigger a lockout is variable.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>TPM + Network key</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>The TPM successfully validates early boot components, and a valid encrypted network key has been provided from the WDS server. This authentication method provides automatic unlock of operating system volumes at system reboot while still maintaining multifactor authentication.</p></td>
</tr>
<tr class="even">
<td align="left"><p>TPM + startup key</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>The TPM successfully validates early boot components, and a USB flash drive containing the startup key has been inserted.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Startup key only</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>The user is prompted to insert the USB flash drive that holds the recovery key and/or startup key and reboot the computer.</p></td>
</tr>
</tbody>
</table>
| Authentication method | Requires user interaction | Description |
| - | - | - |
| TPM only| No| TPM validates early boot components.|
| TPM + PIN | Yes| TPM validates early boot components. The user must enter the correct PIN before the start-up process can continue, and before the drive can be unlocked. The TPM will enter lockout if the incorrect PIN is entered repeatedly to protect the PIN from brute force attacks. The number of repeated attempts that will trigger a lockout is variable.|
| TPM + Network key | No | The TPM successfully validates early boot components, and a valid encrypted network key has been provided from the WDS server. This authentication method provides automatic unlock of operating system volumes at system reboot while still maintaining multifactor authentication. |
| TPM + startup key| Yes| The TPM successfully validates early boot components, and a USB flash drive containing the startup key has been inserted.|
| Startup key only | Yes| The user is prompted to insert the USB flash drive that holds the recovery key and/or startup key and reboot the computer.|
 
**Will you support computers without TPM version 1.2 or higher?**
Determine whether you will support computers that do not have a TPM version 1.2 or higher in your environment. If you choose to support BitLocker on this type of computer, a user must use a USB startup key to boot the system. This requires additional support processes similar to multifactor authentication.
**What areas of your organization need a baseline level of data protection?**
The TPM-only authentication method will provide the most transparent user experience for organizations that need a baseline level of data protection to meet security policies. It has the lowest total cost of ownership. TPM-only might also be more appropriate for computers that are unattended or that must reboot unattended.
However, TPM-only authentication method offers the lowest level of data protection. This authentication method protects against attacks that modify early boot components, but the level of protection can be affected by potential weaknesses in hardware or in the early boot components. BitLocker’s multifactor authentication methods significantly increase the overall level of data protection.
**What areas of your organization need a more secure level of data protection?**
If there are areas of your organization where data residing on user computers is considered highly-sensitive, consider the best practice of deploying BitLocker with multifactor authentication on those systems. Requiring the user to input a PIN significantly increases the level of protection for the system. You can also use BitLocker Network Unlock to allow these computers to automatically unlock when connected to a trusted wired network that can provide the Network Unlock key.
**What multifactor authentication method does your organization prefer?**
The protection differences provided by multifactor authentication methods cannot be easily quantified. Consider each authentication method's impact on Helpdesk support, user education, user productivity, and automated systems management processes.
## <a href="" id="bkmk-tpmconfigurations"></a>TPM hardware configurations
In your deployment plan, identify what TPM-based hardware platforms will be supported. Document the hardware models from an OEM of your choice, so that their configurations can be tested and supported. TPM hardware requires special consideration during all aspects of planning and deployment.
### TPM states of existence
For each of the TPM states of existence, the TPM can transition into another state (for example, moving from disabled to enabled). The states are not exclusive.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">State</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Enabled</p></td>
<td align="left"><p>Most features of the TPM are available.</p>
<p>The TPM may be enabled and disabled multiple times within a boot period, if ownership is taken.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Disabled</p></td>
<td align="left"><p>The TPM restricts most operations. Exceptions include the ability to report TPM capabilities, extend and reset Platform Configuration Register (PCR) functions, and to perform hashing and basic initialization.</p>
<p>The TPM may be enabled and disabled multiple times within a boot period.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Activated</p></td>
<td align="left"><p>Most features of the TPM are available. The TPM may be activated and deactivated only through physical presence which requires a reboot.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Deactivated</p></td>
<td align="left"><p>Similar to disabled, with the exception that ownership can be taken while deactivated and enabled. The TPM may be activated and deactivated only through physical presence which requires a reboot.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Owned</p></td>
<td align="left"><p>Most features of the TPM are available. The TPM has an endorsement key and storage root key, and the owner knows information about owner authorization data.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Un-owned</p></td>
<td align="left"><p>The TPM does not have a storage root key and may or may not have an endorsement key.</p></td>
</tr>
</tbody>
</table>
| State | Description |
| - | - |
| Enabled| Most features of the TPM are available.<br/>The TPM may be enabled and disabled multiple times within a boot period, if ownership is taken.|
| Disabled | The TPM restricts most operations. Exceptions include the ability to report TPM capabilities, extend and reset Platform Configuration Register (PCR) functions, and to perform hashing and basic initialization.<br/>The TPM may be enabled and disabled multiple times within a boot period.|
| Activated| Most features of the TPM are available. The TPM may be activated and deactivated only through physical presence which requires a reboot.|
| Deactivated| Similar to disabled, with the exception that ownership can be taken while deactivated and enabled. The TPM may be activated and deactivated only through physical presence which requires a reboot.|
| Owned| Most features of the TPM are available. The TPM has an endorsement key and storage root key, and the owner knows information about owner authorization data.|
| Un-owned| The TPM does not have a storage root key and may or may not have an endorsement key.|
 
**Important**  
BitLocker cannot use the TPM until it is in the following state: enabled, activated, and owned. When the TPM is in this state and only when it is in this state, all operations are available.
>**Important:**  BitLocker cannot use the TPM until it is in the following state: enabled, activated, and owned. When the TPM is in this state and only when it is in this state, all operations are available.
 
The state of the TPM exists independent of the computer’s operating system. Once the TPM is enabled, activated, and owned, the state of the TPM is preserved if the operating system is reinstalled.
### Endorsement keys
For a TPM to be usable by BitLocker, it must contain an endorsement key, which is an RSA key pair. The private half of the key pair is held inside the TPM and is never revealed or accessible outside the TPM. If the TPM does not contain an endorsement key, BitLocker will force the TPM to generate one automatically as part of BitLocker setup.
An endorsement key can be created at various points in the TPM’s lifecycle, but needs to be created only once for the lifetime of the TPM. If an endorsement key does not exist for the TPM, it must be created before TPM ownership can be taken.
For more information about the TPM and the TCG, see the Trusted Computing Group: Trusted Platform Module (TPM) Specifications (<http://go.microsoft.com/fwlink/p/?linkid=69584>).
## <a href="" id="bkmk-nontpm"></a>Non-TPM hardware configurations
Devices that do not include a TPM can still be protected by drive encryption. Windows To Go workspaces can be BitLocker protected using a startup password and PCs without a TPM can use a startup key.
Use the following questions to identify issues that might affect your deployment in a non-TPM configuration:
- Are password complexity rules in place?
- Do you have budget for USB flash drives for each of these computers?
- Do your existing non-TPM devices support USB devices at boot time?
Test your individual hardware platforms with the BitLocker system check option while you are enabling BitLocker. The system check will ensure that BitLocker can read the recovery information from a USB device and encryption keys correctly before it encrypts the volume. CD and DVD drives cannot act as a block storage device and cannot be used to store the BitLocker recovery material.
## <a href="" id="bkmk-disk"></a>Disk configuration considerations
To function correctly, BitLocker requires a specific disk configuration. BitLocker requires two partitions that meet the following requirements:
- The operating system partition contains the operating system and its support files; it must be formatted with the NTFS file system
- The system partition (or boot partition) contains the files that are needed to load Windows after the BIOS or UEFI firware has prepared the system hardware. BitLocker is not enabled on this partition. For BitLocker to work, the system partition must not be encrypted and must be on a different partition than the operating system. On UEFI platforms the system partition must be formatted with the FAT 32 file system. On BIOS platforms the system partition must be formatted with the NTFS file system. It should be at least 350 MB in size
Windows setup will automatically configure the disk drives of your computer to support BitLocker encryption.
Windows Recovery Environment (Windows RE) is an extensible recovery platform that is based on Windows Pre-installation Environment (Windows PE). When the computer fails to start, Windows automatically transitions into this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an unbootable Windows installation. Windows RE also contains the drivers and tools that are needed to unlock a volume protected by BitLocker by providing a recovery key or recovery password. To use Windows RE in conjunction with BitLocker, the Windows RE boot image must reside on a volume that is not protected by BitLocker.
Windows RE can also be used from boot media other than the local hard disk. If you choose not to install Windows RE on the local hard disk of BitLocker-enabled computers, you can use alternate boot methods, such as Windows Deployment Services, CD-ROM, or USB flash drive, for recovery.
## <a href="" id="bkmk-prov"></a>BitLocker provisioning
In Windows Vista and Windows 7, BitLocker was provisioned post installation for system and data volumes through either the manage-bde command line interface or the Control Panel user interface. With newer operating systems, BitLocker can be easily provisioned before the operating system is installed. Preprovisioning requires that the computer have a TPM.
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the BitLocker control panel applet or Windows Explorer. A status of "Waiting For Activation" with a yellow exclamation icon means that the drive was preprovisioned for BitLocker. This status means that there was only a clear protector used when encrypting the volume. In this case, the volume is not protected and needs to have a secure key added to the volume before the drive is considered fully protected. Administrators can use the control panel options, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be updated.
When using the control panel options, administrators can choose to **Turn on BitLocker** and follow the steps in the wizard to add a protector, such as a PIN for an operating system volume (or a password if no TPM exists), or a password or smart card protector to a data volume. Then the drive security window is presented prior to changing the volume status.
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation Environment (WinPE). This is done with a randomly generated clear key protector applied to the formatted volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space Only option this step takes only a few seconds and so incorporates well into regular deployment processes.
## <a href="" id="bkk-used"></a>Used Disk Space Only encryption
The BitLocker Setup wizard provides administrators the ability to choose the Used Disk Space Only or Full encryption method when enabling BitLocker for a volume. Administrators can use the new BitLocker Group Policy setting to enforce either Used Disk Space Only or Full disk encryption.
Launching the BitLocker Setup wizard prompts for the authentication method to be used (password and smart card are available for data volumes). Once the method is chosen and the recovery key is saved, you are asked to choose the drive encryption type, either Used Disk Space Only or Full drive encryption.
Used Disk Space Only means that only the portion of the drive that contains data will be encrypted, unused space will remain unencrypted. This causes the encryption process to be much faster, especially for new PCs and data drives. When BitLocker is enabled with this method as data is added to the drive the portion of the drive used will be encrypted, so there is never unencrypted data stored on the drive.
Full drive encryption means that the entire drive will be encrypted, regardless of whether data is stored on it or not. This is useful for drives that have been repurposed and may contain data remnants from their previous use.
## <a href="" id="bkmk-addscons"></a>Active Directory Domain Services considerations
BitLocker integrates with Active Directory Domain Services (AD DS) to provide centralized key management. By default, no recovery information is backed up to Active Directory. Administrators can configure Group Policy settings to enable backup of BitLocker or TPM recovery information. Before configuring these settings verify that access permissions have been granted to perform the backup.
By default, domain administrators are the only users that will have access to BitLocker recovery information. When you plan your support process, define what parts of your organization need access to BitLocker recovery information. Use this information to define how the appropriate rights will be delegated in your AD DS environment.
It is a best practice to require backup of recovery information for both the TPM and BitLocker to AD DS. You can implement this practice by configuring the Group Policy settings below for your BitLocker-protected computers.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">BitLocker Group Policy setting</th>
<th align="left">Configuration</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>BitLocker Drive Encryption: Turn on BitLocker backup to Active Directory Domain Services</p></td>
<td align="left"><p>Require BitLocker backup to AD DS (Passwords and key packages)</p></td>
</tr>
<tr class="even">
<td align="left"><p>Trusted Platform Module Services: Turn on TPM backup to Active Directory Domain Services</p></td>
<td align="left"><p>Require TPM backup to AD DS</p></td>
</tr>
</tbody>
</table>
| BitLocker Group Policy setting | Configuration |
| - | - |
| BitLocker Drive Encryption: Turn on BitLocker backup to Active Directory Domain Services| Require BitLocker backup to AD DS (Passwords and key packages)|
| Trusted Platform Module Services: Turn on TPM backup to Active Directory Domain Services | Require TPM backup to AD DS|
 
The following recovery data will be saved for each computer object:
- **Recovery password**
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to unlock a volume when BitLocker enters recovery mode.
- **Key package data**
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-protected volume if the disk is severely damaged. Each key package will only work with the volume it was created on, which can be identified by the corresponding volume ID.
- **TPM owner authorization password hash**
When ownership of the TPM is taken a hash of the ownership password can be taken and stored in AD DS. This information can then be used to reset ownership of the TPM.
Starting in Windows 8, a change to how the TPM owner authorization value is stored in AD DS was implemented in the AD DS schema. The TPM owner authorization value is now stored in a separate object which is linked to the Computer object. This value was stored as a property in the Computer object itself for the default Windows Server 2008 R2 and later schemas.
To take advantage of this integration, you must upgrade your domain controllers to Windows Server 2012 or extend the Active Directory schema and configure BitLocker-specific Group Policy objects.
**Note**  
The account that you use to update the Active Directory schema must be a member of the Schema Admins group.
>**Note:**  The account that you use to update the Active Directory schema must be a member of the Schema Admins group.
 
Windows Server 2012 domain controllers have the default schema to backup TPM owner authorization information in the separate object. If you are not upgrading your domain controller to Windows Server 2012 you need to extend the schema to support this change.
**To support Windows 8 and later computers that are managed by a Windows Server 2003 or Windows 2008 domain controller**
There are two schema extensions that you can copy down and add to your AD DS schema:
- **TpmSchemaExtension.ldf**
This schema extension brings parity with the Windows Server 2012 schema. With this change, the TPM owner authorization information is stored in a separate TPM object linked to the corresponding computer object. Only the Computer object that has created the TPM object can update it. This means that any subsequent updates to the TPM objects will not succeed in dual boot scenarios or scenarios where the computer is reimaged resulting in a new AD computer object being created. To support such scenarios, an update to the schema was created.
- **TpmSchemaExtensionACLChanges.ldf**
This schema update modifies the ACLs on the TPM object to be less restrictive so that any subsequent operating system which takes ownership of the computer object can update the owner authorization value in AD DS. However, this is less secure as any computer in the domain can now update the OwnerAuth of the TPM object (although it cannot read the OwnerAuth) and DOS attacks can be made from within the enterprise. The recommended mitigation in such a scenario is to do regular backup of TPM objects and enable auditing to track changes for these objects.
To download the schema extensions, see [AD DS schema extensions to support TPM backup](ad-ds-schema-extensions-to-support-tpm-backup.md).
If you have a Windows Server 2012 domain controller in your environment, the schema extensions are already in place and do not need to be updated.
**Caution**  
To configure Group Policy objects to backup TPM and BitLocker information in AD DS at least one of the domain controllers in your forest must be running at least Windows Server 2008 R2.
>**Caution:**  To configure Group Policy objects to backup TPM and BitLocker information in AD DS at least one of the domain controllers in your forest must be running at least Windows Server 2008 R2.
If Active Directory backup of the TPM owner authorization value is enabled in an environment without the required schema extensions, the TPM provisioning will fail and the TPM will remain in a Not Ready state for computers running Windows 8 and later.
 
**Setting the correct permissions in AD DS**
To initialize the TPM successfully so that you can turn on BitLocker requires that the correct permissions for the SELF account in be set in AD DS for the **ms-TPMOwnerInformation** attribute. The following steps detail setting these permissions as required by BitLocker:
1. Open **Active Directory Users and Computers**.
2. Select the organizational unit (OU) which contains the computer accounts that will have BitLocker turned on.
3. Right-click the OU and click **Delegate Control** to open the **Delegation of Control** wizard.
@ -270,26 +234,32 @@ To initialize the TPM successfully so that you can turn on BitLocker requires th
7. On the **Active Directory Object Type** page, choose **Only the following objects in the folder** and then check **Computer Objects** and then click **Next**.
8. On the **Permissions** page, for **Show these permissions**, check **General**, **Property-specific**, and **Creation/deletion of specific child objects**. Scroll down the **Permissions** list and check both **Write msTPM-OwnerInformation** and **Write msTPM-TpmInformationForComputer** then click **Next**.
9. Click **Finish** to apply the permissions settings.
## <a href="" id="bkmk-fipssupport"></a>FIPS support for recovery password protector
Functionality introduced in Windows Server 2012 R2 and Windows 8.1, allows BitLocker to be fully functional in FIPS mode.
**Note**  
The United States Federal Information Processing Standard (FIPS) defines security and interoperability requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key generation and for key management. The National Institute of Standards and Technology (NIST) uses the Cryptographic Module Validation Program (CMVP) to determine whether a particular implementation of a cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation. An algorithm that has not been submitted cannot be considered FIPS-compliant even if the implementation produces identical data as a validated implementation of the same algorithm. 
>**Note:**  The United States Federal Information Processing Standard (FIPS) defines security and interoperability requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key generation and for key management. The National Institute of Standards and Technology (NIST) uses the Cryptographic Module Validation Program (CMVP) to determine whether a particular implementation of a cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation. An algorithm that has not been submitted cannot be considered FIPS-compliant even if the implementation produces identical data as a validated implementation of the same algorithm. 
 
Prior to these supported versions of Windows, when Windows was in FIPS mode, BitLocker prevented the creation or use of recovery passwords and instead forced the user to use recovery keys. For more information about these issues, see the support article [kb947249](http://support.microsoft.com/kb/947249).
But on computers running these supported systems with BitLocker enabled:
- FIPS-compliant recovery password protectors can be created when Windows is in FIPS mode. These protectors use the FIPS 140 NIST SP800-132 algorithm.
- Recovery passwords created in FIPS mode on Windows 8.1 can be distinguished from recovery passwords created on other systems.
- Recovery unlock using the FIPS-compliant algorithm based recovery password protector work in all cases that currently work for recovery passwords.
- When FIPS-compliant recovery passwords unlock volumes, the volume is unlocked to allow read/write access even while in FIPS mode.
- FIPS-compliant recovery password protectors can be exported and stored in AD a while in FIPS mode.
The BitLocker Group Policy settings for recovery passwords work the same for all Windows versions that support BitLocker, whether in FIPs mode or not.
However, you cannot use recovery passwords generated on a system in FIPS mode for systems earlier than Windows Server 2012 R2 and Windows 8.1. Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; so recovery keys should be used instead.
## More information
[Trusted Platform Module](trusted-platform-module-overview.md)
[TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
[BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
[BitLocker](bitlocker-overview.md)
[BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
[BitLocker basic deployment](bitlocker-basic-deployment.md)
 
 
- [Trusted Platform Module](trusted-platform-module-overview.md)
- [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md)
- [BitLocker frequently asked questions (FAQ)](bitlocker-frequently-asked-questions.md)
- [BitLocker](bitlocker-overview.md)
- [BitLocker Group Policy settings](bitlocker-group-policy-settings.md)
- [BitLocker basic deployment](bitlocker-basic-deployment.md)

85
windows/keep-secure/profile-single-process.md
View File

@ -2,89 +2,90 @@
title: Profile single process (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Profile single process security policy setting.
ms.assetid: c0963de4-4f5e-430e-bfcd-dfd68e66a075
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Profile single process
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Profile single process** security policy setting.
## Reference
This policy setting determines which users can view a sample performance of an application process. Typically, you do not need this user right to use the performance reporting tools included in the operating system. However, you do need this user right if the system’s monitor components are configured to collect data through Windows Management Instrumentation (WMI).
Constant: SeProfileSingleProcessPrivilege
### Possible values
- User-defined list of accounts
- Administrators
- Not Defined
### Best practices
- This right should not be granted to individual users. It should be granted only for trusted applications that monitor other programs.
### 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 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
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
The **Profile single process** user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They could also identify other users who are logged on to a computer.
### Countermeasure
Ensure that only the local Administrators group is assigned the **Profile single process** user right.
### Potential impact
If you remove the **Profile single process** user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

86
windows/keep-secure/profile-system-performance.md
View File

@ -2,90 +2,92 @@
title: Profile system performance (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the Profile system performance security policy setting.
ms.assetid: ffabc3c5-9206-4105-94ea-84f597a54b2e
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Profile system performance
**Applies to**
- Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, policy management, and security considerations for the **Profile system performance** security policy setting.
## Reference
This security setting determines which users can use Windows performance monitoring tools to monitor the performance of system processes.
Constant: SeSystemProfilePrivilege
### Possible values
- User-defined list of accounts
- Administrators
- Not defined
### Best practices
- Ensure that only the local Administrators group is assigned the **Profile system performance** user right.
### 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 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></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 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.
Depending on your version of Windows and your environment, you might need to add this user right to the Local System account or the Local Service account if you encounter access errors when you use the Administrators account.
### 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
The **Profile system performance** user right poses a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers might also be able to determine what processes are active on the computer so that they could identify countermeasures to avoid, such as anti-virus software or an intrusion detection system.
### Countermeasure
Ensure that only the local Administrators group is assigned the **Profile system performance** user right.
### Potential impact
None. Restricting the **Profile system performance** user right to the local Administrators group is the default configuration.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

446
windows/keep-secure/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
View File

@ -2,232 +2,331 @@
title: Control the health of Windows 10-based devices (Windows 10)
description: This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices.
ms.assetid: 45DB1C41-C35D-43C9-A274-3AD5F31FE873
ms.pagetype: security; devices
keywords: ["security", "BYOD", "malware", "device health attestation", "mobile"]
keywords: security, BYOD, malware, device health attestation, mobile
ms.prod: W10
ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: security; devices
author: arnaudjumelet
---
# Control the health of Windows 10-based devices
**Applies to**
- Windows 10
This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices.
## Introduction
In Bring Your Own Device (BYOD) scenarios, employees bring commercially available devices to access both work-related resources and their personal data. Users want to use the device of their choice to access the organization’s applications, data, and resources not only from the internal network but also from anywhere. This phenomenon is also known as the consumerization of IT.
Users want to have the best productivity experience when accessing corporate applications and working on organization data from their devices. That means they will not tolerate being prompted to enter their work credentials each time they access an application or a file server. From a security perspective, it also means that users will manipulate corporate credentials and corporate data on unmanaged devices.
With the increased use of BYOD, there will be more unmanaged and potentially unhealthy systems accessing corporate services, internal resources, and cloud apps.
Even managed devices can be compromised and become harmful. Organizations need to detect when security has been breached and react as early as possible in order to protect high-value assets.
As Microsoft moves forward, security investments are increasingly focused on security preventive defenses and also on detection and response capabilities.
Windows 10 is an important component of an end-to-end security solution that focuses not only on the implementation of security preventive defenses, but adds device health attestation capabilities to the overall security strategy.
## Description of a robust end-to-end security solution
Today’s computing threat landscape is increasing at a speed never encountered before. The sophistication of criminal attacks is growing, and there is no doubt that malware now targets both consumers and professionals in all industries.
During recent years, one particular category of threat has become prevalent: advanced persistent threats (APTs). The term APT is commonly used to describe any attack that seems to target individual organizations on an on-going basis. In fact, this type of attack typically involves determined adversaries who may use any methods or techniques necessary.
With the BYOD phenomena, a poorly maintained device represents a target of choice. For an attacker, it’s an easy way to breach the security network perimeter, gain access to, and then steal high-value assets.
The attackers target individuals, not specifically because of who they are, but because of who they work for. An infected device will bring malware into an organization, even if the organization has hardened the perimeter of networks or has invested in its defensive posture. A defensive strategy is not sufficient against these threats.
### A different approach
Rather than the traditional focus on the prevention of compromise, an effective security strategy assumes that determined adversaries will successfully breach any defenses. It means that it’s necessary to shift focus away from preventative security controls to detection of, and response to, security issues. The implementation of the risk management strategy, therefore, balances investment in prevention, detection, and response.
Because mobile devices are increasingly being used to access corporate information, some way to evaluate device security or health is required. This section describes how to provision device health assessment in such a way that high-value assets can be protected from unhealthy devices.
Devices that are used to access corporate resources must be trusted. An efficient end-to-end security approach is able to evaluate device health and use the current security state when granting access to a high-value asset.
![figure 1](images/hva-fig1-endtoend1.png)
A robust design needs to establish the user’s identity, strengthen the authentication method if needed, and learn behavior like the network location the user regularly connects from. Also, a modern approach must be able to release sensitive content only if user devices are determined to be healthy and secure.
The following figure shows a solution built to assess device health from the cloud. The device authenticates the user through a connection to an identity provider in the cloud. If the managed asset contains highly confidential information, the conditional access engine of the identity provider may elect to verify the security compliance of the mobile device before access is granted. The user’s device is able to prove its health status that can be sent at any time or when mobile device management (MDM) requests it.
![figure 2](images/hva-fig2-assessfromcloud2.png)
Windows devices can be protected from low-level rootkits and bootkits by using low-level hardware technologies such as Unified Extensible Firmware Interface (UEFI) Secure Boot.
Secure Boot is a firmware validation process that helps prevent rootkit attacks; it is part of the UEFI specification. The intent of UEFI is to define a standard way for the operating system to communicate with modern hardware, which can perform faster and with more efficient input/output (I/O) functions than older, software interrupt-driven BIOS systems.
A device health attestation module can communicate measured boot data that is protected by a Trusted Platform Module (TPM) to a remote service. After the device successfully boots, boot process measurement data is sent to a trusted cloud service (Health Attestation Service) using a more secure and tamper-resistant communication channel.
Remote health attestation service performs a series of checks on the measurements. It validates security related data points, including boot state (Secure Boot, Debug Mode, and so on), and the state of components that manage security (BitLocker, Device Guard, and so on). It then conveys the health state of the device by sending a health encrypted blob back to the device.
An MDM solution typically applies configuration policies and deploys software to devices. MDM defines the security baseline and knows the level of compliance of the device with regular checks to see what software is installed and what configuration is enforced, as well as determining the health status of the device.
An MDM solution asks the device to send device health information and forward the health encrypted blob to the remote health attestation service. The remote health attestation service verifies device health data, checks that MDM is communicating to the same device, and then issues a device health report back to the MDM solution.
An MDM solution evaluates the health assertions and, depending on the health rules belonging to the organization, can decide if the device is healthy. If the device is healthy and compliant, MDM passes that information to the identity provider so the organization’s access control policy can be invoked to grant access.
Access to content is then authorized to the appropriate level of trust for whatever the health status and other conditional elements indicate.
Depending on the requirements and the sensitivity of the managed asset, device health status can be combined with user identity information when processing an access request. Access to content is then authorized to the appropriate level of trust. The Conditional Access engine may be structured to allow additional verification as needed by the sensitivity of the managed asset. For example, if access to high-value data is requested, additional security authentication may need to be established by querying the user to answer a phone call before access is granted.
### <a href="" id="microsoft-s-security-investments-in-windows-10"></a>Microsoft’s security investments in Windows 10
In Windows 10, there are three pillars of investments:
- **Secure identities.** Microsoft is part of the FIDO Alliance which aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system as well as for services like on-premises resources and cloud resources.
- **Information protection.** Microsoft is making investments to allow organizations to have better control over who has access to important data and what they can do with that data. With Windows 10, organizations can take advantage of policies that specify which applications are considered to be corporate applications and can be trusted to access secure data.
- **Threat resistance.** Microsoft is helping organizations to better secure enterprise assets against the threats of malware and attacks by using security defenses relying on hardware.
### Protect, control, and report on the security status of Windows 10-based devices
This section is an overview that describes different parts of the end-to-end security solution that helps protect high-value assets and information from attackers and malware.
![figure 3](images/hva-fig3-endtoendoverview3.png)
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Number</th>
<th align="left">Part of the solution</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>1</strong></p></td>
<td align="left"><p>Windows 10-based device</p></td>
<td align="left"><p>The first time a Windows 10-based device is powered on, the out-of-box experience (OOBE) screen is displayed. During setup, the device can be automatically registered into Azure Active Directory (AD) and enrolled in MDM.</p>
<p>A Windows 10-based device with TPM 2.0 can report health status at any time by using the Health Attestation Service available with all editions of Windows 10.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>2</strong></p></td>
<td align="left"><p>Identity provider</p></td>
<td align="left"><p>Azure AD contains users, registered devices, and registered application of organization’s tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.</p>
<p>Azure AD is more than a repository. Azure AD is able to authenticate users and devices and can also authorize access to managed resources. Azure AD has a conditional access control engine that leverages the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>3</strong></p></td>
<td align="left"><p>Mobile device management</p></td>
<td align="left"><p>Windows 10 has MDM support that enables the device to be managed out-of-box without deploying any agent.</p>
<p>MDM can be Microsoft Intune or any third-party MDM solution that is compatible with Windows 10.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>4</strong></p></td>
<td align="left"><p>Remote health attestation</p></td>
<td align="left"><p>The Health Attestation Service is a trusted cloud service operated by Microsoft that performs a series of health checks and reports to MDM what Windows 10 security features are enabled on the device.</p>
<p>Security verification includes boot state (WinPE, Safe Mode, Debug/test modes) and components that manage security and integrity of runtime operations (BitLocker, Device Guard).</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>5</strong></p></td>
<td align="left"><p>Enterprise managed asset</p></td>
<td align="left"><p>Enterprise managed asset is the resource to protect.</p>
<p>For example, the asset can be Office 365, other cloud apps, on-premises web resources published by Azure AD, or even VPN access.</p></td>
</tr>
</tbody>
</table>
| Number | Part of the solution | Description |
| - | - | - |
| **1** | Windows 10-based device | The first time a Windows 10-based device is powered on, the out-of-box experience (OOBE) screen is displayed. During setup, the device can be automatically registered into Azure Active Directory (AD) and enrolled in MDM.<br/>A Windows 10-based device with TPM 2.0 can report health status at any time by using the Health Attestation Service available with all editions of Windows 10.|
| **2** | Identity provider | Azure AD contains users, registered devices, and registered application of organization’s tenant. A device always belongs to a user and a user can have multiple devices. A device is represented as an object with different attributes like the compliance status of the device. A trusted MDM can update the compliance status.<br/>Azure AD is more than a repository. Azure AD is able to authenticate users and devices and can also authorize access to managed resources. Azure AD has a conditional access control engine that leverages the identity of the user, the location of the device and also the compliance status of the device when making a trusted access decision.|
| **3**|Mobile device management| Windows 10 has MDM support that enables the device to be managed out-of-box without deploying any agent.<br/>MDM can be Microsoft Intune or any third-party MDM solution that is compatible with Windows 10.|
| **4** | Remote health attestation | The Health Attestation Service is a trusted cloud service operated by Microsoft that performs a series of health checks and reports to MDM what Windows 10 security features are enabled on the device.<br/>Security verification includes boot state (WinPE, Safe Mode, Debug/test modes) and components that manage security and integrity of runtime operations (BitLocker, Device Guard).|
| **5** | Enterprise managed asset | Enterprise managed asset is the resource to protect.<br/>For example, the asset can be Office 365, other cloud apps, on-premises web resources published by Azure AD, or even VPN access.|
 
The combination of Windows 10-based devices, identity provider, MDM, and remote health attestation creates a robust end-to-end-solution that provides validation of health and compliance of devices that access high-value assets.
## Protect devices and enterprise credentials against threats
This section describes what Windows 10 offers in terms of security defenses and what control can be measured and reported to.
### Windows 10 hardware-based security defenses
The most aggressive forms of malware try to insert themselves into the boot process as early as possible so that they can take control of the operating system early and prevent protection mechanisms and antimalware software from working. This type of malicious code is often called a rootkit or bootkit. The best way to avoid having to deal with low-level malware is to secure the boot process so that the device is protected from the very start.
Windows 10 supports multiple layers of boot protection. Some of these features are available only if specific types of hardware are installed. For more information, see the [Hardware requirements](#hardware-req) section.
![figure 4](images/hva-fig4-hardware.png)
Windows 10 supports features to help prevent sophisticated low-level malware like rootkits and bootkits from loading during the startup process:
- **Trusted Platform Module.** A Trusted Platform Module (TPM) is a hardware component that provides unique security features.
Windows 10 leverages security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
Windows 10 uses the TPM for cryptographic calculations as part of health attestation and to protect the keys for BitLocker, Microsoft Passport, virtual smart cards, and other public key certificates. For more information, see [TPM requirements in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=733948).
Windows 10 recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows 10 supports only TPM 2.0. TPM 2.0 is required for device health attestation.
TPM 2.0 provides a major revision to the capabilities over TPM 1.2:
- Update crypto strength to meet modern security needs
- Support for SHA-256 for PCRs
- Support for HMAC command
- Cryptographic algorithms flexibility to support government needs
- TPM 1.2 is severely restricted in terms of what algorithms it can support
- TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents
- Consistency across implementations
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
- **Secure Boot.** Devices with UEFI firmware can be configured to load only trusted operating system bootloaders. Secure Boot does not require a TPM.
The most basic protection is the Secure Boot feature, which is a standard part of the UEFI 2.2+ architecture. On a PC with conventional BIOS, anyone who can take control of the boot process can boot by using an alternative OS loader, and potentially gain access to system resources. When Secure Boot is enabled, you can boot using only an OS loader that’s signed using a certificate stored in the UEFI Secure Boot DB. Naturally, the Microsoft certificate used to digitally sign the Windows 10 OS loaders are in that store, which allows UEFI to validate the certificate as part of its security policy. Secure Boot must be enabled by default on all computers that are certified for Windows 10 under the Windows Hardware Compatibility Program.
Secure Boot is a UEFI firmware-based feature, which allows for the signing and verification of critical boot files and drivers at boot time. Secure Boot checks signature values of the Windows Boot Manager, BCD store, Windows OS loader file, and other boot critical DLLs at boot time before the system is allowed to fully boot into a usable operating system by using policies that are defined by the OEM at build time. Secure Boot prevents many types of boot-based rootkit, malware, and other security-related attacks against the Windows platform. Secure Boot protects the operating system boot process whether booting from local hard disk, USB, PXE, or DVD, or into full Windows or Windows Recovery Environment (RE).
Secure Boot protects the boot environment of a Windows 10 installation by verifying the signatures of the critical boot components to confirm malicious activity did not compromise them. Secure Boot protection ends after the Windows kernel file (ntoskrnl.exe) has been loaded.
**Note**  
Secure Boot protects the platform until the Windows kernel is loaded. Then protections like ELAM take over.
>**Note:**  Secure Boot protects the platform until the Windows kernel is loaded. Then protections like ELAM take over.
 
- **Secure Boot configuration policy.** Extends Secure Boot functionality to critical Windows 10 configuration.
Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) cannot be enabled. This ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
Secure Boot configuration policy does this with UEFI policy. These signatures for these policies are signed in the same way that operating system binaries are signed for use with Secure Boot.
The Secure Boot configuration policy must be signed by a private key that corresponds to one of the public keys stored in the Key Exchange Key (KEK) list. The Microsoft Certificate Authority (CA) will be present in the KEK list of all Windows certified Secure Boot systems. By default, a policy signed by the Microsoft KEK shall be work on all Secure Boot systems. BootMgr must verify the signature against the KEK list before applying a signed policy. With Windows 10, the default Secure Boot configuration policy is embedded in bootmgr.
The bootloader verifies the digital signature of the Windows 10 kernel before loading it. The Windows 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and the ELAM component. This step is important and protects the rest of the boot process by verifying that all Windows boot components have integrity and can be trusted.
- **Early Launch Antimalware (ELAM).** ELAM tests all drivers before they load and prevents unapproved drivers from loading.
Traditional antimalware apps don’t start until after the boot drivers have been loaded, which gives a rootkit that is disguised as a driver the opportunity to work. ELAM is a Windows mechanism introduced in a previous version of Windows that allows antimalware software to run very early in the boot sequence. Thus, the antimalware component is the first third-party component to run and control the initialization of other boot drivers until the Windows operating system is operational. When the system is started with a complete runtime environment (network access, storage, and so on), then a full-featured antimalware is loaded.
ELAM can load a Microsoft or non-Microsoft antimalware driver before all non-Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible, ELAM has a simple task: Examine every boot driver and determine whether it is on the list of trusted drivers. If it’s not trusted, Windows won’t load it.
**Note**  
Windows Defender, Microsoft's antimalware included by default in Windows 10, supports ELAM; it can be replaced with a third-party antimalware compatible solution. The name of the Windows Defender ELAM driver is WdBoot.sys. Windows Defender in Windows 10 uses its ELAM driver to roll back any malicious changes made to the Windows Defender driver at the next reboot. This prevents kernel mode malware making lasting changes to Windows Defender’s mini-filter driver before shutdown or reboot.
>**Note:**  Windows Defender, Microsoft's antimalware included by default in Windows 10, supports ELAM; it can be replaced with a third-party antimalware compatible solution. The name of the Windows Defender ELAM driver is WdBoot.sys. Windows Defender in Windows 10 uses its ELAM driver to roll back any malicious changes made to the Windows Defender driver at the next reboot. This prevents kernel mode malware making lasting changes to Windows Defender’s mini-filter driver before shutdown or reboot.
 
The ELAM signed driver is loaded before any other third-party drivers or applications, which allows the antimalware software to detect and block any attempts to tamper with the boot process by trying to load unsigned or untrusted code.
The ELAM driver is a small driver with a small policy database that has a very narrow scope, focused on drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be signed by Microsoft and the associated certificate must contain the complementary EKU (1.3.6.1.4.1.311.61.4.1).
- **Virtualization-based security (Hyper-V + Secure Kernel).** Virtualization-based security is a completely new enforced security boundary that allows you to protect critical parts of Windows 10.
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate domain credentials from the rest of the Windows operating system. For more information, refer to the [Virtualization-based security](#virtual) section.
- **Hyper-V Code Integrity (HVCI).** Hyper-V Code Integrity is a feature of Device Guard that ensures only drivers, executables, and DLLs that comply with the Device Guard Code Integrity policy are allowed to run.
When enabled and configured, Windows 10 can start the Hyper-V virtualization-based security services, including Hyper-V Code Integrity (HVCI). HVCI helps protect the system core (kernel), privileged drivers, and system defenses, like antimalware solutions, by preventing malware from running early in the boot process, or after startup.
HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This means that kernel memory pages can never be Writable and Executable (W+X) and executable code cannot be directly modified.
**Note**  
Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must have compatible drivers. For additional information, please read the [Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=691612) blog post.
>**Note:**  Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must have compatible drivers. For additional information, please read the [Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=691612) blog post.
 
The Device Guard Code Integrity feature lets organizations control what code is trusted to run into the Windows kernel and what applications are approved to run in user mode. It’s configurable by using a policy.
Device Guard Code Integrity policy is a binary file that Microsoft recommends you sign. The signing of the Code Integrity policy aids in the protection against a malicious user with Administrator privileges trying to modify or remove the current Code Integrity policy.
- **Credential Guard.** Credential Guard protects corporate credentials with hardware-based credential isolation.
In Windows 10, Credential Guard aims to protect domain corporate credentials from theft and reuse by malware. With Credential Guard, Windows 10 implemented an architectural change that fundamentally prevents the current forms of the pass-the-hash (PtH) attack.
This is accomplished by leveraging Hyper-V and the new virtualization-based security feature to create a protected container where trusted code and secrets are isolated from the Windows kernel. That means that even if the Windows kernel is compromised an attacker has no way to read and extract the data required to initiate a PtH attack. Credential Guard prevents this because the memory where secrets are stored is no longer accessible from the regular OS, even in kernel mode - the hypervisor controls who can access the memory.
- **Health attestation.** The device’s firmware logs the boot process, and Windows 10 can send it to a trusted server that can check and assess the device’s health.
Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware components are made as they load during the boot process. Additionally, they are taken and measured sequentially, not all at once. When these measurements are complete, their values are digitally signed and stored securely in the TPM and cannot be changed unless the system is reset.
For more information, see [Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware](http://go.microsoft.com/fwlink/p/?LinkId=733950).
During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For additional security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called *remote device health attestation*, allows the server to verify health status of the Windows device.
Health attestation requires the presence of TPM 2.0. On Windows 10, TPM 2.0 also requires UEFI firmware.
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM vendor. Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a measurement does not work. But with conditional access control, health attestation will help to prevent access to high-value assets.
### <a href="" id="virtual"></a>Virtualization-based security
Virtualization-based security provides a new trust boundary for Windows 10. leverages Hyper-V hypervisor technology to enhance platform security. Virtualization-based security provides a secure execution environment to run specific Windows trusted code (trustlet) and to protect sensitive data.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Note that virtualization-based security is not trying to protect against a physical attacker.
The following Windows 10 services are protected with virtualization-based security:
- **Credential Guard** (LSA Credential Isolation): prevents pass-the-hash attacks and enterprise credential theft that happens by reading and dumping the content of lsass memory
- **Device Guard** (Hyper-V Code Integrity): Device Guard uses the new virtualization-based security in Windows 10 to isolate the Code Integrity service from the Windows kernel itself, which lets the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
- **Other isolated services**: for example, on Windows Server Technical Preview 2016, there is the vTPM feature that allows you to have encrypted virtual machines (VMs) on servers.
**Note**  
Virtualization-based security is only available with Windows 10 Enterprise. Virtualization-based security requires devices with UEFI (2.3.1 or higher) with Secure Boot enabled, x64 processor with Virtualization Extensions and SLAT enabled. IOMMU, TPM 2.0. and support for Secure Memory overwritten are optional, but recommended.
>**Note:**  Virtualization-based security is only available with Windows 10 Enterprise. Virtualization-based security requires devices with UEFI (2.3.1 or higher) with Secure Boot enabled, x64 processor with Virtualization Extensions and SLAT enabled. IOMMU, TPM 2.0. and support for Secure Memory overwritten are optional, but recommended.
 
The schema below is a high-level view of Windows 10 with virtualization-based security.
![figure 5](images/hva-fig5-virtualbasedsecurity.png)
### Credential Guard
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This helps ensure that protected data is not stolen and reused on remote machines, which mitigates many PtH-style attacks.
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This helps ensure that protected data is not stolen and reused on
remote machines, which mitigates many PtH-style attacks.
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
- **The per-boot key** is used for any in-memory credentials that do not require persistence. An example of such a credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution Center (KDC) every time authentication occurs and is protected with a per-boot key.
- **The persistent key**, or some derivative, is used to help protect items that are stored and reloaded after a reboot. Such protection is intended for long-term storage, and must be protected with a consistent key.
Credential Guard is activated by a registry key and then enabled by using an UEFI variable. This is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that credential isolation is enabled, it then spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode support routines are ready before any authentication begins.
Credential Guard is activated by a registry key and then enabled by using an UEFI variable. This is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that
credential isolation is enabled, it then spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode support routines are ready before any authentication begins.
### Device Guard
Device Guard is a new feature of Windows 10 Enterprise that allows organizations to lock down a device to help protect it from running untrusted software. In this configuration, the only applications allowed to run are those that are trusted by the organization.
The trust decision to execute code is performed by using Hyper-V Code Integrity, which runs in virtualization-based security, a Hyper-V protected container that runs alongside regular Windows.
Hyper-V Code Integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with Administrator privileges. On x64-based versions of Windows 10 kernel-mode drivers must be digitally signed.
**Note**  
Independently of activation of Device Guard Policy, [Windows 10 by default raises the bar for what runs in the kernel](http://go.microsoft.com/fwlink/p/?LinkId=691613). Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
>**Note:**  Independently of activation of Device Guard Policy, [Windows 10 by default raises the bar for what runs in the kernel](http://go.microsoft.com/fwlink/p/?LinkId=691613). Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
 
With Device Guard in Windows 10, organizations are now able to define their own Code Integrity policy for use on x64 systems running Windows 10 Enterprise. Organizations have the ability to configure the policy that determines what is trusted to run. These include drivers and system files, as well as traditional desktop applications and scripts. The system is then locked down to only run applications that the organization trusts.
Device Guard is a built-in feature of Windows 10 Enterprise that prevents the execution of unwanted code and applications. Device Guard can be configured using two rule actions - allow and deny:
- **Allow** limits execution of applications to an allowed list of code or trusted publisher and blocks everything else.
- **Deny** completes the allow trusted publisher approach by blocking the execution of a specific application.
At the time of this writing, and according to Microsoft’s latest research, more than 90 percent of malware is unsigned completely. So implementing a basic Device Guard policy can simply and effectively help block the vast majority of malware. In fact, Device Guard has the potential to go further, and can also help block signed malware.
Device Guard needs to be planned and configured to be truly effective. It is not just a protection that is enabled or disabled. Device Guard is a combination of hardware security features and software security features that, when configured together, can lock down a computer to help ensure the most secure and resistant system possible.
There are three different parts that make up the Device Guard solution in Windows 10:
- The first part is a base **set of hardware security features** introduced with the previous version of Windows. TPM for hardware cryptographic operations and UEFI with modern firmware, along with Secure Boot, allows you to control what the device is running when the systems start.
- After the hardware security feature, there is the code integrity engine. In Windows 10, **Code Integrity is now fully configurable** and now resides in Isolated user mode, a part of the memory that is protected by virtualization-based security.
- The last part of Device Guard is **manageability**. Code Integrity configuration is exposed through specific Group Policy Objects, PowerShell cmdlets, and MDM configuration service providers (CSPs).
For more information on how to deploy Device Guard in an enterprise, see the [Device Guard deployment guide](device-guard-deployment-guide.md).
### Device Guard scenarios
As previously described, Device Guard is a powerful way to lock down systems. Device Guard is not intended to be used broadly and it may not always be applicable, but there are some high-interest scenarios.
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have very well-defined software that are expected to run and don’t change too frequently. It could also help protect Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of applications is not going to change on a daily basis.
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have very well-defined software that are expected to run and don’t change too frequently.
It could also help protect Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of applications is not going to change on a daily basis.
SAWs are computers that are built to help significantly reduce the risk of compromise from malware, phishing attacks, bogus websites, and PtH attacks, among other security risks. Although SAWs can’t be considered a “silver bullet” security solution to these attacks, these types of clients are helpful as part of a layered, defense-in-depth approach to security.
To protect high-value assets, SAWs are used to make secure connections to those assets.
Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool like System Center Configuration Manager, Intune, or any third-party device management, then Device Guard is very applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s quite difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
Before you can benefit from the protection included in Device Guard, Code Integrity policy must be created by using tools provided by Microsoft, but the policy can be deployed with common management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10, along with restrictions on Windows 10 script hosts. Device Guard Code Integrity policy restricts what code can run on a device.
**Note**  
Device Guard policy can be signed in Windows 10, which adds additional protection against administrative users changing or removing this policy.
>**Note:**  Device Guard policy can be signed in Windows 10, which adds additional protection against administrative users changing or removing this policy.
 
Signed Device Guard policy offers stronger protection against a malicious local administrator trying to defeat Device Guard.
When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable which offers tampering protection. The only way to update the Device Guard policy subsequently is to provide a new version of the policy signed by the same signer or from a signer specified as part of the Device Guard policy into the UpdateSigner section.
When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable which offers tampering protection. The only way to update the Device Guard policy subsequently is to provide a new version of the policy signed by the same signer or from a signer specified as part of the
Device Guard policy into the UpdateSigner section.
### The importance of signing applications
On computers with Device Guard, Microsoft proposes to move from a world where unsigned apps can be run without restriction to a world where only signed and trusted code is allowed to run on Windows 10.
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Windows Store infrastructure. More specifically, LOB apps will be available in a private store within the public Windows Store. Windows Store signs and distributes Universal Windows apps and Classic Windows apps. All apps downloaded from the Windows Store are signed.
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Windows Store infrastructure. More specifically, LOB apps will be available in a private store within the public Windows Store. Windows Store signs and distributes Universal
Windows apps and Classic Windows apps. All apps downloaded from the Windows Store are signed.
In organizations today, the vast majority of LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them through a process to create additional signatures that can be distributed along with existing applications.
### Why are antimalware and device management solutions still necessary?
Although allow-list mechanisms are extremely efficient at ensuring that only trusted applications can be run, they cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
Vulnerabilities are weaknesses in software that could allow an attacker to compromise the integrity, availability, or confidentiality of the device. Some of the worst vulnerabilities allow attackers to exploit the compromised device by causing it to run malicious code without the user’s knowledge.
It’s common to see attackers distributing specially crafted content in an attempt to exploit known vulnerabilities in user mode software like web browsers (and their plug-ins), Java virtual machines, PDF readers, or document editors. As of today, 90 percent of discovered vulnerabilities affect user mode applications compared to the operating system and kernel mode drivers that host them.
To combat these threats, patching is the single most effective control, with antimalware software forming complementary layers of defense.
Most application software has no facility for updating itself, so even if the software vendor publishes an update that fixes the vulnerability, the user may not know that the update is available or how to obtain it, and therefore remains vulnerable to attack. Organizations still need to manage devices and to patch vulnerabilities.
MDM solutions are becoming prevalent as a light-weight device management technology. Windows 10 extends the management capabilities that have become available for MDMs. One key feature Microsoft has added to Windows 10 is the ability for MDMs to acquire a strong statement of device health from managed and registered devices.
### Device health attestation
Device health attestation leverages the TPM 2.0 to provide cryptographically strong and verifiable measurements of the chain of software used to boot the device.
For Windows 10-based devices, Microsoft introduces a new public API that will allow MDM software to access a remote attestation service called Windows Health Attestation Service. A health attestation result, in addition with other elements, can be used to allow or deny access to networks, apps, or services, based on whether devices prove to be healthy.
For more information on device health attestation, see the [Detect an unhealthy Windows 10-based device](#detect-unhealthy) section.
### <a href="" id="hardware-req"></a>Hardware requirements
The following table details the hardware requirements for both virtualization-based security services and the health attestation feature. For more information, see [Minimum hardware requirements](http://go.microsoft.com/fwlink/p/?LinkId=733951).
<table>
<colgroup>
<col width="50%" />
@ -274,33 +373,57 @@ The following table details the hardware requirements for both virtualization-ba
</table>
 
This section presented information about several closely related controls in Windows 10. The multi-layer defenses and in-depth approach helps to eradicate low-level malware during boot sequence. Virtualization-based security is a fundamental operating system architecture change that adds a new security boundary. Device Guard and Credential Guard respectively help to block untrusted code and protect corporate domain credentials from theft and reuse. This section also briefly discussed the importance of managing devices and patching vulnerabilities. All these technologies can be used to harden and lock down devices while limiting the risk of attackers compromising them.
## <a href="" id="detect-unhealthy"></a>Detect an unhealthy Windows 10-based device
As of today, many organizations only consider devices to be compliant with company policy after they’ve passed a variety of checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting is not entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
The biggest challenge with rootkits is that they can be undetectable to the client. Because they start before antimalware, and they have system-level privileges, they can completely disguise themselves while continuing to access system resources. As a result, traditional computers infected with rootkits appear to be healthy, even with antimalware running.
As previously discussed, the health attestation feature of Windows 10 uses the TPM 2.0 hardware component to securely record a measurement of every boot-related component, including firmware, Windows 10 kernel, and even early boot drivers. Because, health attestation leverages the hardware-based security capabilities of TPM, the log of all boot measured components remains out of the reach of any malware.
By attesting a trusted boot state, devices can prove that they are not running low-level malware that could spoof later compliance checks. TPM-based health attestation provides a reliable anchor of trust for assets that contain high-value data.
### What is the concept of device health?
To understand the concept of device health, it’s important to know traditional measures that IT pros have taken to prevent the breach of malware. Malware control technologies are highly focused on the prevention of installation and distribution.
However, the use of traditional malware prevention technologies like antimalware or patching solutions brings a new set of issues for IT pros: the ability to monitor and control the compliance of devices accessing organization’s resources.
The definition of device compliance will vary based on an organization’s installed antimalware, device configuration settings, patch management baseline, and other security requirements. But health of the device is part of the overall device compliance policy.
The health of the device is not binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by leveraging trustworthy hardware TPM.
But health attestation only provides information, which is why an MDM solution is needed to take and enforce a decision.
### Remote device health attestation
In Windows 10, health attestation refers to a feature where Measured Boot data generated during the boot process is sent to a remote device health attestation service operated by Microsoft.
This is the most secure approach available for Windows 10-based devices to detect when security defenses are down. During the boot process, the TCG log and PCRs values are sent to a remote Microsoft cloud service. Logs are then checked by the Health Attestation Service to determine what changes have occurred on the device.
A relying party like an MDM can inspect the report generated by the remote health attestation service.
**Note**  
To use the health attestation feature of Windows 10, the device must be equipped with a discrete or firmware TPM 2.0. There is no restriction on any particular edition of Windows 10.
>**Note:**  To use the health attestation feature of Windows 10, the device must be equipped with a discrete or firmware TPM 2.0. There is no restriction on any particular edition of Windows 10.
 
Windows 10 supports health attestation scenarios by allowing applications access to the underlying health attestation configuration service provider (CSP) so that applications can request a health attestation token. The measurement of the boot sequence can be checked at any time locally by an antimalware or an MDM agent.
Remote device health attestation combined with an MDM provides a hardware-rooted method for reporting the current security status and detecting any changes, without having to trust the software running on the system.
In the case where malicious code is running on the device, the use of a remote server is required. If a rootkit is present on the device, the antimalware is no longer reliable, and its behavior can be hijacked by a malicious code running early in the startup sequence. That's why it's important to use Secure Boot and Device Guard, to control which code is loaded during the boot sequence.
The antimalware software can search to determine whether the boot sequence contains any signs of malware, such as a rootkit. It can also send the TCG log and the PCRs to a remote health attestation server to provide a separation between the measurement component and the verification component.
Health attestation logs the measurements in various TPM Platform Configuration Registers (PCRs) and TCG logs during the boot process.
![figure 6](images/hva-fig6-logs.png)
When starting a device equipped with a TPM, a measurement of different components is performed. This includes firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. The raw measurements are stored in the TPM PCR registers while the details of all events (executable path, authority certification, and so on) are available in the TCG log.
![figure 7](images/hva-fig7-measurement.png)
The health attestation process works as follows:
1. Hardware boot components are measured.
2. Operating system boot components are measured.
3. If Device Guard is enabled, current Device Guard policy is measured.
@ -309,90 +432,138 @@ The health attestation process works as follows:
6. Boot start drivers are measured.
7. MDM server through the MDM agent issues a health check command by leveraging the Health Attestation CSP.
8. Boot measurements are validated by the Health Attestation Service
**Note**  
By default, the last 100 system boot logs and all associated resume logs are archived in the %SystemRoot%\\logs\\measuredboot folder.
>**Note:**  By default, the last 100 system boot logs and all associated resume logs are archived in the %SystemRoot%\\logs\\measuredboot folder.
The number of retained logs may be set with the registry **REG\_DWORD** value **PlatformLogRetention** under the **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM** key. A value of **0** will turn off log archival and a value of **0xffffffff** will keep all logs.
 
The following process describes how health boot measurements are sent to the health attestation service:
1. The client (a Windows 10-based device with a TPM 2.0) initiates the request with the remote device health attestation service. Because the health attestation server is expected to be a Microsoft cloud service, the URI is already pre-provisioned in the client.
2. The client then sends the TCG log, the AIK signed data (PCR values, boot counter) and the AIK certificate information.
3. The remote device heath attestation service then:
1. Verifies that the AIK certificate is issued by a known and trusted CA and the certificate is valid and not revoked.
2. Verifies that the signature on the PCR quotes is correct and consistent with the TCG log value.
3. Parses the properties in the TCG log.
4. Issues the device health token that contains the health information, the AIK information, and the boot counter information. The health token also contains valid issuance time. The device health token is encrypted and signed, that means that the information is protected and only accessible to issuing health attestation service.
4. The client stores the health encrypted blob in its local store. The device health token contains device health status, a device ID (the Windows AIK), and the boot counter.
![figure 8](images/hva-fig8a-healthattest8a.png)
### Device health attestation components
The device health attestation solution involves different components that are TPM, Health Attestation CSP, and the Windows Health Attestation Service. Those components are described in this section.
### <a href="" id="trusted-platform-module-"></a>Trusted Platform Module
*It’s all about TPM 2.0 and endorsement certificates.* This section describes how PCRs (that contain system configuration data), endorsement key (EK) (that act as an identity card for TPM), SRK (that protect keys) and AIKs (that can report platform state) are used for health attestation reporting.
In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device.
A TPM incorporates in a single component:
- A RSA 2048-bit key generator
- A random number generator
- Nonvolatile memory for storing EK, SRK, and AIK keys
- A cryptographic engine to encrypt, decrypt, and sign
- Volatile memory for storing the PCRs and RSA keys
### Endorsement key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM. For more information, see [Understand the TPM endorsement key](http://go.microsoft.com/fwlink/p/?LinkId=733952).
The endorsement key is often accompanied by one or two digital certificates:
- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it’s a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service.
- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device.
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10.
**Note**  
Secure Boot protects the platform until the Windows kernel is loaded. Then protections like Trusted Boot, Hyper-V Code Integrity and ELAM take over. A device that uses Intel TPM or Qualcomm TPM gets a signed certificate online from the manufacturer that has created the chip and then stores the signed certificate in TPM storage. For the operation to succeed, if you are filtering Internet access from your client devices, you must authorize the following URLs:
>**Note:**  Secure Boot protects the platform until the Windows kernel is loaded. Then protections like Trusted Boot, Hyper-V Code Integrity and ELAM take over. A device that uses Intel TPM or Qualcomm TPM gets a signed certificate online from the manufacturer that has created the chip and then stores the signed certificate in TPM storage. For the operation to succeed, if you are filtering Internet access from your client devices, you must authorize the following URLs:
- For Intel firmware TPM: **https://ekop.intel.com/ekcertservice**
- For Qualcomm firmware TPM: **https://ekcert.spserv.microsoft.com/**
 
### Attestation Identity Keys
Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
**Note**  
Before the device can report its health using the TPM 2.0 attestation functions, an AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
>**Note:**  Before the device can report its health using the TPM 2.0 attestation functions, an AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
 
The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10-based device.
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft
Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10-based device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Microsoft Passport without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an endorsement certificate.
### Storage root key
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### Platform Configuration Registers
The TPM contains a set of registers that are designed to provide a cryptographic representation of the software and state of the system that booted. These registers are called Platform Configuration Registers (PCRs).
The measurement of the boot sequence is based on the PCR and TCG log. To establish a static root of trust, when the device is starting, the device must be able to measure the firmware code before execution. In this case, the Core Root of Trust for Measurement (CRTM) is executed from the boot, calculates the hash of the firmware, then stores it by expanding the register PCR\[0\] and transfers execution to the firmware.
PCRs are set to zero when the platform is booted, and it is the job of the firmware that boots the platform to measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components take the hash of the next component that is to be run and record the measurements in the PCRs. The initial component that starts the measurement chain is implicitly trusted. This is the CRTM. Platform manufacturers are required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative hash of the components that have been measured.
The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log has not been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
### TPM provisioning
For the TPM of a Windows 10-based device to be usable, it must first be provisioned. The process of provisioning differs somewhat based on TPM versions, but, when successful, it results in the TPM being usable and the owner authorization data (ownerAuth) for the TPM being stored locally on the registry.
When the TPM is provisioned, Windows 10 will first attempt to determine the EK and locally stored **ownerAuth** values by looking in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Endorsement**
During the provisioning process, the device may need to be restarted.
Note that the **Get-TpmEndorsementKeyInfo PowerShell** cmdlet can be used with administrative privilege to get information about the endorsement key and certificates of the TPM.
If the TPM ownership is not known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Admin\\SRKPub**
If the TPM ownership is not known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location:
**HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Admin\\SRKPub**
As part of the provisioning process, Windows 10 will create an AIK with the TPM. When this operation is performed, the resulting AIK public portion is stored in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\WindowsAIKPub**
**Note**  
For provisioning AIK certificates and filtering Internet access, you must authorize the following wildcard URL: **https://\*.microsoftaik.azure.net**
>**Note:**  For provisioning AIK certificates and filtering Internet access, you must authorize the following wildcard URL: **https://\*.microsoftaik.azure.net**
 
### Windows 10 Health Attestation CSP
Windows 10 contains a configuration service provider (CSP) specialized for interacting with the health attestation feature. A CSP is a component that plugs into the Windows MDM client and provides a published protocol for how MDM servers can configure settings and manage Windows-based devices. The management protocol is represented as a tree structure that can be specified as URIs with functions to perform on the URIs such as “get”, “set”, “delete”, and so on.
The following is a list of functions performed by the Windows 10 Health Attestation CSP:
- Collects data that is used to verify a device’s health status
- Forwards the data to the Health Attestation Service
- Provisions the Health Attestation Certificate that it receives from the Health Attestation Service
- Upon request, forwards the Health Attestation Certificate (received from the Health Attestation Service) and related runtime information to the MDM server for verification
During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs values that are measured during the boot, by using a secure communication channel to the Health Attestation Service.
When an MDM server validates that a device has attested to the Health Attestation Service, it will be given a set of statements and claims about how that device booted, with the assurance that the device did not reboot between the time that it attested its health and the time that the MDM server validated it.
### Windows Health Attestation Service
The role of Windows Health Attestation Service is essentially to evaluate a set of health data (TCG log and PCR values), make a series of detections (based on available health data) and generate encrypted health blob or produce report to MDM servers.
**Note**  
Both device and MDM servers must have access to **has.spserv.microsoft.com** using the TCP protocol on port 443 (HTTPS).
>**Note:**  Both device and MDM servers must have access to **has.spserv.microsoft.com** using the TCP protocol on port 443 (HTTPS).
 
Checking that a TPM attestation and the associated log are valid takes several steps:
1. First, the server must check that the reports are signed by **trustworthy AIKs**. This might be done by checking that the public part of the AIK is listed in a database of assets, or perhaps that a certificate has been checked.
2. After the key has been checked, the signed attestation (a quote structure) should be checked to see whether it is a **valid signature over PCR values**.
3. Next the logs should be checked to ensure that they match the PCR values reported.
4. Finally, the logs themselves should be examined by an MDM solution to see whether they represent **known or valid security configurations**. For example, a simple check might be to see whether the measured early OS components are known to be good, that the ELAM driver is as expected, and that the ELAM driver policy file is up to date. If all of these checks succeed, an attestation statement can be issued that later can be used to determine whether or not the client should be granted access to a resource.
The Health Attestation Service provides the following information to an MDM solution about the health of the device:
- Secure Boot enablement
- Boot and kernel debug enablement
- BitLocker enablement
@ -401,8 +572,11 @@ The Health Attestation Service provides the following information to an MDM solu
- ELAM loaded
- Safe Mode boot, DEP enablement, test signing enablement
- Device TPM has been provisioned with a trusted endorsement certificate
For completeness of the measurements, see [Health Attestation CSP](http://go.microsoft.com/fwlink/p/?LinkId=733949).
The following table presents some key items that can be reported back to MDM depending on the type of Windows 10-based device.
<table>
<colgroup>
<col width="50%" />
@ -446,90 +620,139 @@ The following table presents some key items that can be reported back to MDM dep
</table>
 
### Leverage MDM and the Health Attestation Service
To make device health relevant, the MDM solution evaluates the device health report and is configured to the organization’s device health requirements.
A solution that leverages MDM and the Health Attestation Service consists of three main parts:
1. A device with health attestation enabled. This will usually be done as a part of enrollment with an MDM provider (health attestation will be disabled by default).
2. After this is enabled, and every boot thereafter, the device will send health measurements to the Health Attestation Service hosted by Microsoft, and it will receive a health attestation blob in return.
3. At any point after this, an MDM server can request the health attestation blob from the device and ask Health Attestation Service to decrypt the content and validate that it’s been attested.
![figure 9](images/hva-fig8-evaldevicehealth8.png)
Interaction between a Windows 10-based device, the Health Attestation Service, and MDM can be performed as follows:
1. The client initiates a session with the MDM server. The URI for the MDM server would be part of the client app that initiates the request. The MDM server at this time could request the health attestation data by using the appropriate CSP URI.
2. The MDM server specifies a nonce along with the request.
3. The client then sends the AIK quoted nonce + the boot counter and the health blob information. This health blob is encrypted with a Health Attestation Service public key that only the Health Attestation Service can decrypt.
4. The MDM server:
1. Verifies that the nonce is as expected.
2. Passes the quoted data, the nonce and the encrypted health blob to the Health Attestation Service server.
5. The Health Attestation Service:
1. Decrypts the health blob.
2. Verifies that the boot counter in the quote is correct using the AIK in the health blob and matches the value in the health blob.
3. Verifies that the nonce matches in the quote and the one that is passed from MDM.
4. Because the boot counter and the nonce are quoted with the AIK from the health blob, it also proves that the device is the same one as the one for which the health blob has been generated.
5. Sends data back to the MDM server including health parameters, freshness, and so on.
**Note**  
The MDM server (relying party) never performs the quote or boot counter validation itself. It gets the quoted data and the health blob (which is encrypted) and sends the data to the Health Attestation Service for validation. This way, the AIK is never visible to the MDM, which thereby addresses privacy concerns.
>**Note:**  The MDM server (relying party) never performs the quote or boot counter validation itself. It gets the quoted data and the health blob (which is encrypted) and sends the data to the Health Attestation Service for validation. This way, the AIK is never visible to the MDM, which thereby addresses privacy concerns.
 
Setting the requirements for device compliance is the first step to ensure that registered devices that do not meet health and compliance requirements are detected, tracked, and have actions enforced by the MDM solution.
Devices that attempt to connect to resources must have their health evaluated so that unhealthy and noncompliant devices can be detected and reported. To be fully efficient, an end-to-end security solution must impose a consequence for unhealthy devices like refusing access to high-value assets. That is the purpose of conditional access control, which is detailed in the next section.
Devices that attempt to connect to resources must have their health evaluated so that unhealthy and noncompliant devices can be detected and reported. To be fully efficient, an end-to-end security solution must impose a consequence for unhealthy devices like refusing access to high-value assets.
That is the purpose of conditional access control, which is detailed in the next section.
## Control the security of a Windows 10-based device before access is granted
Today’s access control technology, in most cases, focuses on ensuring that the right people get access to the right resources. If users can authenticate, they get access to resources using a device that the organization’s IT staff and systems know very little about. Perhaps there is some check such as ensuring that a device is encrypted before giving access to email, but what if the device is infected with malware?
The remote device health attestation process uses measured boot data to verify the health status of the device. The health of the device is then available for an MDM solution like Intune.
**Note**  
For the latest information on Intune and Windows 10 features support, see the [Microsoft Intune blog](http://go.microsoft.com/fwlink/p/?LinkId=691614) and [What's new in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=733956).
>**Note:**  For the latest information on Intune and Windows 10 features support, see the [Microsoft Intune blog](http://go.microsoft.com/fwlink/p/?LinkId=691614) and [What's new in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=733956).
 
The figure below shows how the Health Attestation Service is expected to work with Microsoft’s cloud-based Intune MDM service.
![figure 10](images/hva-fig9-intune.png)
An MDM solution can then leverage health state statements and take them to the next level by coupling with client policies that will enable conditional access to be granted based on the device’s ability to prove that it’s malware free, its antimalware system is functional and up to date, the firewall is running, and the devices patch state is compliant.
An MDM solution can then leverage health state statements and take them to the next level by coupling with client policies that will enable conditional access to be granted based on the device’s ability to prove that it’s malware free, its antimalware system is functional and up to date, the
firewall is running, and the devices patch state is compliant.
Finally, resources can be protected by denying access to endpoints that are unable to prove they’re healthy. This feature is much needed for BYOD devices that need to access organizational resources.
### Built-in support of MDM in Windows 10
Windows 10 has an MDM client that ships as part of the operating system. This enables MDM servers to manage Windows 10-based devices without requiring a separate agent.
### Third-party MDM server support
Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For additional information, see [Azure Active Directory integration with MDM](http://go.microsoft.com/fwlink/p/?LinkId=733954).
**Note**  
MDM servers do not need to create or download a client to manage Windows 10. For more information, see [Mobile device management](http://go.microsoft.com/fwlink/p/?LinkId=733955).
>**Note:**  MDM servers do not need to create or download a client to manage Windows 10. For more information, see [Mobile device management](http://go.microsoft.com/fwlink/p/?LinkId=733955).
 
The third-party MDM server will have the same consistent first-party user experience for enrollment, which also provides simplicity for Windows 10 users.
### <a href="" id="management-of-windows-defender-by-third-party-mdm-"></a>Management of Windows Defender by third-party MDM
This management infrastructure makes it possible for IT pros to use MDM-capable products like Intune, to manage health attestation, Device Guard, or Windows Defender on Windows 10-based devices, including BYODs that aren’t domain joined. IT pros will be able to manage and configure all of the actions and settings they are familiar with customizing by using Intune with Intune Endpoint Protection on down-level operating systems. Admins that currently only manage domain joined devices through Group Policy will find it easy to transition to managing Windows 10-based devices by using MDM because many of the settings and actions are shared across both mechanisms.
For more information on how to manage Windows 10 security and system settings with an MDM solution, see [Custom URI settings for Windows 10 devices](http://go.microsoft.com/fwlink/p/?LinkId=733953).
### Conditional access control
On most platforms, the Azure Active Directory (Azure AD) device registration happens automatically during enrollment. The device states are written by the MDM solution into Azure AD, and then read by Office 365 (or by any authorized Windows app that interacts with Azure AD) the next time the client tries to access an Office 365 compatible workload.
If the device is not registered, the user will get a message with instructions on how to register (also known as enrolling). If the device is not compliant, the user will get a different message that redirects them to the MDM web portal where they can get more information on the compliance problem and how to resolve it.
**Azure AD** authenticates the user and the device, **MDM** manages the compliance and conditional access policies, and the **Health Attestation Service** reports about the health of the device in an attested way.
![figure 11](images/hva-fig10-conditionalaccesscontrol.png)
### <a href="" id="office-365-conditional-access-control-"></a>Office 365 conditional access control
Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company’s device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include additional target groups.
Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company’s device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include additional
target groups.
When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that do not have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
When a user enrolls, the device is registered with Azure AD, and enrolled with a compatible MDM solution like Intune.
**Note**  
Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy based access checks. Steps to turn on auto-MDM enrollment with Azure AD and Intune are explained in the [Windows 10, Azure AD And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!](http://go.microsoft.com/fwlink/p/?LinkId=691615) blog post.
>**Note**  Microsoft is working with third-party MDM ISVs to support automated MDM enrollment and policy based access checks. Steps to turn on auto-MDM enrollment with Azure AD and Intune are explained in the [Windows 10, Azure AD And Microsoft Intune: Automatic MDM Enrollment Powered By The Cloud!](http://go.microsoft.com/fwlink/p/?LinkId=691615) blog post.
 
When a user enrolls a device successfully, the device becomes trusted. Azure AD provides single-sign-on to access company applications and enforces conditional access policy to grant access to a service not only the first time the user requests access, but every time the user requests to renew access.
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the compliance policy is not met at the time of request for renewal.
Depending on the type of email application that employees use to access Exchange online, the path to establish secured access to email can be slightly different. However, the key components: Azure AD, Office 365/Exchange Online, and Intune, are the same. The IT experience and end-user experience also are similar.
![figure 12](images/hva-fig11-office365.png)
Clients that attempt to access Office 365 will be evaluated for the following properties:
- Is the device managed by an MDM?
- Is the device registered with Azure AD?
- Is the device compliant?
To get to a compliant state, the Windows 10-based device needs to:
- Enroll with an MDM solution.
- Register with Azure AD.
- Be compliant with the device policies set by the MDM solution.
**Note**  
At the present time, conditional access policies are selectively enforced on users on iOS and Android devices. For more information, see the [Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility!](http://go.microsoft.com/fwlink/p/?LinkId=691616) blog post.
>**Note:**  At the present time, conditional access policies are selectively enforced on users on iOS and Android devices. For more information, see the [Azure AD, Microsoft Intune and Windows 10 – Using the cloud to modernize enterprise mobility!](http://go.microsoft.com/fwlink/p/?LinkId=691616) blog post.
 
### <a href="" id="cloud-and-on-premises-apps-conditional-access-control-"></a>Cloud and on-premises apps conditional access control
Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's logon to make real-time decisions about which applications they should be allowed to access.
IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even on-premises applications. Access rules in Azure AD leverage the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
For more information about conditional access, see [Azure Conditional Access Preview for SaaS Apps.](http://go.microsoft.com/fwlink/p/?LinkId=524807)
**Note**  
Conditional access control is an Azure AD Premium feature that's also available with EMS. If you don't have an Azure AD Premium subscription, you can get a trial from the [Microsoft Azure](http://go.microsoft.com/fwlink/p/?LinkId=691617) site.
>**Note:**  Conditional access control is an Azure AD Premium feature that's also available with EMS. If you don't have an Azure AD Premium subscription, you can get a trial from the [Microsoft Azure](http://go.microsoft.com/fwlink/p/?LinkId=691617) site.
 
For on-premises applications there are two options to enable conditional access control based on a device's compliance state:
- For on-premises applications that are published through the Azure AD Application Proxy, you can configure conditional access control policies as you would for cloud applications. For more details, see the [Azure AD Conditional Access preview updated: Now supports On-Premises and Custom LOB apps](http://go.microsoft.com/fwlink/p/?LinkId=691618) blog post.
- Additionally, Azure AD Connect will sync device compliance information from Azure AD to on-premises AD. ADFS on Windows Server Technical Preview 2016 will support conditional access control based on a device's compliance state. IT pros will configure conditional access control policies in ADFS that use the device's compliance state reported by a compatible MDM solution to secure on-premises applications.
![figure 13](images/hva-fig12-conditionalaccess12.png)
The following process describes how Azure AD conditional access works:
1. User has already enrolled with MDM through Workplace Access/Azure AD join which registers device with Azure AD.
2. When the device boots or resumes from hibernate, a task “Tpm-HASCertRetr” is triggered to request in background a health attestation blob. Device sends TPM boot measurements to the Health Attestation Service.
3. Health Attestation Service validates device state and issues an encrypted blob to the device based on the health state with details on failed checks (if any).
@ -544,34 +767,59 @@ The following process describes how Azure AD conditional access works:
12. Access gated by compliance claim in Azure AD.
13. If the device is compliant and the user is authorized, an access token is generated.
14. User can access the corporate managed asset.
For more information about Azure AD join, see the [Azure AD & Windows 10: Better Together for Work or School](http://go.microsoft.com/fwlink/p/?LinkId=691619) white paper.
Conditional access control is a topic that many organizations and IT pros may not know as well as they should. The different attributes that describe a user, a device, compliance, and context of access are very powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
## Takeaways and summary
The following list contains high-level key take-aways to improve the security posture of any organization. However, the few take-aways presented in this section should not be interpreted as an exhaustive list of security best practices.
- **Understand that no solution is 100 percent secure**
If determined adversaries with malicious intent gain physical access to the device, they could eventually break through its security layers and control it.
- **Use health attestation with an MDM solution**
Devices that attempt to connect to high-value assets must have their health evaluated so that unhealthy and noncompliant devices can be detected, reported, and eventually blocked.
- **Use Credential Guard**
Credential Guard is a feature that greatly helps protect corporate domain credentials from pass-the-hash attacks.
- **Use Device Guard**
Device Guard is a real advance in security and an effective way to help protect against malware. The new Device Guard feature in Windows 10 blocks untrusted apps (apps not authorized by your organization).
- **Sign Device Guard policy**
Signed Device Guard policy helps protect against a user with administrator privileges trying to defeat the current policy. When a policy is signed, the only way to modify Device Guard subsequently is to provide a new version of the policy signed by the same signer or from a signer specify as part of the Device Guard policy.
- **Use virtualization-based security**
When you have Kernel Mode Code Integrity protected by virtualization-based security, the code integrity rules are still enforced even if a vulnerability allows unauthorized kernel mode memory access. Keep in mind that Device Guard devices that run Kernel Code Integrity with virtualization-based security must have compatible drivers.
- **Start to deploy Device Guard with Audit mode**
Deploy Device Guard policy to targeted computers and devices in Audit mode. Monitor the Code Integrity event log that indicates a program or a driver would have been blocked if Device Guard was configured in Enforcement mode. Adjust Device Guard rules until a high level of confidence has been reached. After the testing phase has been completed, Device Guard policy can be switched to Enforcement mode.
- **Build an isolated reference machine when deploying Device Guard**
Because the corporate network can contain malware, you should start to configure a reference environment that is isolated from your main corporate network. After that, you can create a code integrity policy that includes the trusted applications you want to run on your protected devices.
- **Use AppLocker when it makes sense**
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user or a group of users.
- **Lock down firmware and configuration**
After Windows 10 is installed, lock down firmware boot options access. This prevents a user with physical access from modifying UEFI settings, disabling Secure Boot, or booting other operating systems. Also, in order to protect against an administrator trying to disable Device Guard, add a rule in the current Device Guard policy that will deny and block execution of the **C:\\Windows\\System32\\SecConfig.efi** tool.
Health attestation is a key feature of Windows 10 that includes client and cloud components to control access to high-value assets based on a user and their device’s identity and compliance with corporate governance policy. Organizations can choose to detect and report unhealthy devices, or to configure health enforcement rules based on their needs. Health attestation provides an end-to-end security model and integration points, which vendors and software developers can use to build and integrate a customized solution.
## Related topics
[Protect derived domain credentials with Credential Guard](credential-guard.md)
[Device Guard deployment guide](device-guard-deployment-guide.md)
[Trusted Platform Module technology overview](http://go.microsoft.com/fwlink/p/?LinkId=733957)
 
 
- [Protect derived domain credentials with Credential Guard](credential-guard.md)
- [Device Guard deployment guide](device-guard-deployment-guide.md)
- [Trusted Platform Module technology overview](http://go.microsoft.com/fwlink/p/?LinkId=733957)

84
windows/keep-secure/protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md
View File

@ -2,112 +2,163 @@
title: Protecting cluster shared volumes and storage area networks with BitLocker (Windows 10)
description: This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
ms.assetid: ecd25a10-42c7-4d31-8a7e-ea52c8ebc092
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Protecting cluster shared volumes and storage area networks with BitLocker
**Applies to**
- Windows 10
This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
BitLocker can protect both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on clustered volumes allows for an additional layer of protection for administrators wishing to protect sensitive, highly available data. By adding additional protectors to the clustered volume, administrators can also add an additional barrier of security to resources within an organization by allowing only certain user accounts access to unlock the BitLocker volume.
## <a href="" id="configuring-bitlocker-on-cluster-shared-volumes-"></a>Configuring BitLocker on Cluster Shared Volumes
### Using BitLocker with Clustered Volumes
BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be protected. The volume can be a physical disk resource such as a logical unit number (LUN) on a storage area network (SAN) or network attached storage (NAS).
**Important**  
SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see [Windows Hardware Lab Kit](https://msdn.microsoft.com/library/windows/hardware/dn930814.aspx).
>**Important**  SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see [Windows Hardware Lab Kit](https://msdn.microsoft.com/library/windows/hardware/dn930814.aspx).
 
Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server 2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using BitLocker with volumes designated for a cluster, the volume will need to turn on BitLocker before its addition to the storage pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server 2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using BitLocker with volumes designated for a cluster, the volume will need to turn on
BitLocker before its addition to the storage pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
Windows PowerShell or the manage-bde command line interface is the preferred method to manage BitLocker on CSV2.0 volumes. This is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points do not require the use of a drive letter. Volumes that lack drive letters do not appear in the BitLocker Control Panel item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0 resources is not available in the Control Panel item.
**Note**  
Mount points can be used to support remote mount points on SMB based network shares. This type of share is not supported for BitLocker encryption.
>**Note:**  Mount points can be used to support remote mount points on SMB based network shares. This type of share is not supported for BitLocker encryption.
 
For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD), BitLocker runs in Used Disk Space Only encryption mode. You cannot use the **manage-bde –WipeFreeSpace** command to transition the volume to full-volume encryption on these types of volumes. This occurs because Full Encryption requires an end marker for the volume and dynamically expanding VHDs do not have a static end of volume marker.
For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD), BitLocker runs in Used Disk Space Only encryption mode. You cannot use the **manage-bde –WipeFreeSpace** command to transition the volume to full-volume encryption on these types of volumes. This occurs because Full
Encryption requires an end marker for the volume and dynamically expanding VHDs do not have a static end of volume marker.
### Active Directory-based protector
You can also use an Active Directory Domain Services (AD DS) protector for protecting clustered volumes held within your AD DS infrastructure. The **ADAccountOrGroup** protector is a domain security identifier (SID)-based protector that can be bound to a user account, machine account or group. When an unlock request is made for a protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to unlock or deny the request. BitLocker will unlock protected volumes without user intervention by attempting protectors in the following order:
1. Clear key
2. Driver-based auto-unlock key
3. ADAccountOrGroup protector
1. Service context protector
2. User protector
4. Registry-based auto-unlock key
**Note**  
A Windows Server 2012 or later domain controller is required for this feature to work properly.
>**Note:**  A Windows Server 2012 or later domain controller is required for this feature to work properly.
 
### Turning on BitLocker before adding disks to a cluster using Windows PowerShell
BitLocker encryption is available for disks before or after addition to a cluster storage pool. The advantage of encrypting volumes prior to adding them to a cluster is that the disk resource does not require suspending the resource to complete the operation. To turn on BitLocker for a disk before adding it to a cluster, do the following:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Ensure the disk is formatted NTFS and has a drive letter assigned to it.
3. Enable BitLocker on the volume using your choice of protector. A password protector is used in the Windows PowerShell script example below.
``` syntax
Enable-BitLocker E: -PasswordProtector -Password $pw
```
4. Identify the name of the cluster with Windows PowerShell.
``` syntax
Get-Cluster
```
5. Add an **ADAccountOrGroup**protector to the volume using the cluster name using a command such as:
``` syntax
Add-BitLockerProtector E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
**Warning**  
You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
>**Warning:**  You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
 
6. Repeat steps 1-6 for each disk in the cluster.
7. Add the volume(s) to the cluster.
### Turning on BitLocker for a clustered disk using Windows PowerShell
When the cluster service owns a disk resource already, it needs to be set into maintenance mode before BitLocker can be enabled. Use the following steps for turning BitLocker on for a clustered disk:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Check the status of the cluster disk using Windows PowerShell.
``` syntax
Get-ClusterResource "Cluster Disk 1"
```
3. Put the physical disk resource into maintenance mode using Windows PowerShell.
``` syntax
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource
```
4. Enable BitLocker on the volume using your choice of protector. A password protector is used in the example below.
``` syntax
Enable-BitLocker E: -PasswordProtector -Password $pw
```
5. Identify the name of the cluster with Windows PowerShell
``` syntax
Get-Cluster
```
6. Add an **ADAccountOrGroup** protector with the Cluster Name Object (CNO) to the volume using a command such as:
``` syntax
Add-BitLockerProtector E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
**Warning**  
You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
>**Warning:**  You must add an **ADAccountOrGroup** protector using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to failover properly in a traditional failover cluster.
 
7. Repeat steps 1-6 for each disk in the cluster.
8. Add the volume(s) to the cluster
### Adding BitLocker encrypted volumes to a cluster using manage-bde
You can also use manage-bde to enable BitLocker on clustered volumes. The steps needed to add a physical disk resource or CSV2.0 volume to an existing cluster includes the following:
1. Verify the BitLocker Drive Encryption feature is installed on the computer.
2. Ensure new storage is formatted as NTFS.
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using the manage-bde command line interface (see example):
- `Manage-bde -on -used <drive letter> -RP -sid domain\CNO$ -sync`
1. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will encounter a hard block. Otherwise, the encryption will continue.
2. Using the -sync parameter is optional. Using it ensures the command waits until the encryption for the volume is completed before releasing the volume for use in the cluster storage pool.
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered
- Once the disk is clustered it can also be enabled for CSV.
5. During the resource online operation, cluster will check to see if the disk is BitLocker encrypted.
1. If the volume is not BitLocker enabled, traditional cluster online operations occur.
2. If the volume is BitLocker enabled, the following check occurs:
- If volume is **locked**, BitLocker will impersonate the CNO and unlock the volume using the CNO protector. If this operation fails an event will be logged that the volume could not be unlocked and the online operation will fail.
6. Once the disk is online in the storage pool, it can be added to a CSV by right clicking on the disk resource and choosing "**Add to cluster shared volumes**".
CSVs can include both encrypted and unencrypted volumes. To check the status of a particular volume for BitLocker encryption, administrators can utilize the manage-bde -status command with a path to the volume inside the CSV namespace as seen in the example command line below.
``` syntax
manage-bde -status "C:\ClusterStorage\volume1"
```
### Physical Disk Resources
Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This means that operations such as encrypting, decrypting, locking or unlocking volumes require context to perform. For example, you cannot unlock or decrypt a physical disk resource if you are not administering the cluster node that owns the disk resource because the disk resource is not available.
### Restrictions on BitLocker actions with cluster volumes
The following table contains information about both Physical Disk Resources (i.e. traditional failover cluster volumes) and Cluster Shared Volumes (CSV) and the actions that are allowed by BitLocker in each situation.
<table>
<colgroup>
<col width="20%" />
@ -211,11 +262,12 @@ The following table contains information about both Physical Disk Resources (i.e
</tbody>
</table>
 
**Note**  
Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically resume a paused encryption or decryption from the MDS node
>**Note:**  Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically resume a paused encryption or decryption from the MDS node
 
In the case where a physical disk resource experiences a failover event during conversion, the new owning node will detect the conversion is not complete and will complete the conversion process.
### Other considerations when using BitLocker on CSV2.0
Some other considerations to take into account for BitLocker on clustered storage include the following:
- BitLocker volumes have to be initialized and beginning encryption before they are available to add to a CSV2.0 volume.
- If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put into disk maintenance mode. You can add the CSV back to the cluster while waiting for decryption to complete.
@ -224,5 +276,3 @@ Some other considerations to take into account for BitLocker on clustered storag
- If conversion is paused with encryption in progress and a physical disk resource volume is offline from the cluster, the BitLocker driver will automatically resume conversion when the volume is online to the cluster.
- If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster thread (health check) will automatically resume conversion when moving the volume back from maintenance.
- If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode, the BitLocker driver will automatically resume conversion when the volume is moved back from maintenance mode.
 
 

89
windows/keep-secure/recovery-console-allow-automatic-administrative-logon.md
View File

@ -2,88 +2,93 @@
title: Recovery console Allow automatic administrative logon (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Recovery console Allow automatic administrative logon security policy setting.
ms.assetid: be2498fc-48f4-43f3-ad09-74664e45e596
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Recovery console: Allow automatic administrative logon
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting.
## Reference
This policy setting determines whether the built-in Administrator account password must be provided before access to the device is granted. If you enable this setting, the built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required.
The Recovery Console can be very useful when troubleshooting and repairing systems that cannot be restarted. However, enabling this policy setting so a user can automatically log on to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select **Recovery Console** from the **Restart** menu, and then assume full control of the server.
### Possible values
- Enabled
The built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required
- Disabled
Automatic administrative logon is not allowed.
- Not defined
Automatic administrative logon is not allowed.
### Best practices
- Set **Recovery Console: Allow automatic administrative logon** to **Disabled**. This requires a user to enter a user name and password to access the Recovery Console account.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Disabled|
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
## Policy management
This section describes features and tools that are available 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.
### Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device
### Policy conflicts
None.
## 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 Recovery Console can be very useful when you must troubleshoot and repair device that do not start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server.
### Countermeasure
Disable the **Recovery console: Allow automatic administrative logon** setting.
### Potential impact
Users must enter a user name and password to access the Recovery Console.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

88
windows/keep-secure/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
View File

@ -2,95 +2,99 @@
title: Recovery console Allow floppy copy and access to all drives and folders (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Recovery console Allow floppy copy and access to all drives and folders security policy setting.
ms.assetid: a5b4ac0c-f33d-42b5-a866-72afa7cbd0bd
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Recovery console: Allow floppy copy and access to all drives and folders
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting.
## Reference
This policy setting enables or disables the Recovery Console SET command, which allows you to set the following Recovery Console environment variables.
- **AllowWildCards**. Enables wildcard support for some commands, such as the DEL command.
- **AllowAllPaths**. Allows access to all files and folders on the device.
- **AllowRemovableMedia**. Allows files to be copied to removable media, such as a floppy disk.
- **NoCopyPrompt**. Suppresses the prompt that typically displays before an existing file is overwritten.
You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the removable media before the hard disk drive, the server will start from the removable disk. This causes the server's network services to be unavailable.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
- Set **Recovery Console: Allow floppy copy and access to drives and folders** to **Disabled**. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account will not be able to copy files and folders to a floppy disk.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Disabled|
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
## Policy management
This section describes features and tools that are available 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.
### Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device.
### Policy conflicts
None.
### Command-line tools
Enabling this security option makes the Recovery Console SET command available, which allows you to set the following Recovery Console environment variables:
- AllowWildCards: Enable wildcard support for some commands (such as the DEL command).
- AllowAllPaths: Allow access to all files and folders on the device.
- AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.
- NoCopyPrompt: Do not prompt when overwriting an existing file.
## 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 who can cause the system to restart into the Recovery Console could steal sensitive data and leave no audit or access trail.
### Countermeasure
Disable the **Recovery console: Allow floppy copy and access to drives and folders** setting.
### Potential impact
Users who have started a server through the Recovery Console and logged in with the built-in Administrator account cannot copy files and folders to a floppy disk.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

28
windows/keep-secure/refresh-an-applocker-policy.md
View File

@ -2,39 +2,55 @@
title: Refresh an AppLocker policy (Windows 10)
description: This topic for IT professionals describes the steps to force an update for an AppLocker policy.
ms.assetid: 3f24fcbc-3926-46b9-a1a2-dd036edab8a9
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Refresh an AppLocker policy
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to force an update for an AppLocker policy.
If you update the rule collection on a local computer by using the Local Security Policy snap-in, the policy will take effect immediately. If Group Policy is used to distribute the AppLocker policy and you want to immediately implement the policy, you must manually refresh the policy. The Group Policy refresh might take several minutes, depending upon the number of policies within the Group Policy Object (GPO) and the number of target computers.
To use Group Policy to distribute the AppLocker policy change, you need to retrieve the deployed AppLocker policy first. To prepare for the update and subsequent refresh, see [Edit an AppLocker policy](edit-an-applocker-policy.md)
[Edit an AppLocker policy](edit-an-applocker-policy.md) and [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
To complete this procedure, you must have 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 manually refresh the AppLocker policy by using Group Policy**
1. From a command prompt, type **gpupdate /force**, and then press ENTER.
2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using Group Policy, you first need to update the rule within the rule collection. For information about updating existing rules, see [Edit AppLocker rules](edit-applocker-rules.md). For information about creating a new rule for an existing policy, see:
To change a policy on an individual computer, or to implement that policy on other computers, without using Group Policy, you first need to update the rule within the rule collection. For information about updating existing rules, see [Edit AppLocker rules](edit-applocker-rules.md). For information
about creating a new rule for an existing policy, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md)
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To refresh the AppLocker policy on the local computer**
- Update the rule collection by using the Local Security Policy console with one of the following procedures:
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
- [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md)
When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do this, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
**Caution**  
When importing rules from another computer, all the rules will be applied, not just the one that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
>**Caution:**  When importing rules from another computer, all the rules will be applied, not just the one that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
 
- Merge AppLocker policies. For procedures to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
 
 

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

@ -2,19 +2,24 @@
title: Registry (Global Object Access Auditing) (Windows 10)
description: This topic for the IT professional describes the Advanced Security Audit policy setting, Registry (Global Object Access Auditing), which enables you to configure a global system access control list (SACL) on the registry of a computer.
ms.assetid: 953bb1c1-3f76-43be-ba17-4aed2304f578
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Registry (Global Object Access Auditing)
**Applies to**
- Windows 10
This topic for the IT professional describes the Advanced Security Audit policy setting, **Registry (Global Object Access Auditing)**, which enables you to configure a global system access control list (SACL) on the registry of a computer.
If you select the **Configure security** check box on this 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 registry. The specified SACL is then automatically applied to every registry object type.
This policy setting must be used in combination with the **Registry** security policy setting under Object Access. For more info, see [Audit Registry](audit-registry.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)

87
windows/keep-secure/remove-computer-from-docking-station.md
View File

@ -2,93 +2,96 @@
title: Remove computer from docking station (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Remove computer from docking station security policy setting.
ms.assetid: 229a385a-a862-4973-899a-413b1b5b6c30
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Remove computer from docking station
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Remove computer from docking station** security policy setting.
## Reference
This security setting determines whether a user can undock a portable device from its docking station without logging on. This policy setting only affects scenarios that involve a portable computer and its docking station.
If this user right is assigned to the user’s account (or if the user is a member of the assigned group), the user must log on before removing the portable device from its docking station. Otherwise, as a security measure, the user will not be able to log on after the device is removed from the docking station. If this policy is not assigned, the user may remove the portable device from its docking station without logging on, and then have the ability to start and log on to the device afterwards in its undocked state.
Constant: SeUndockPrivilege
### Possible values
- User-defined list of accounts
- Not Defined
### Best practices
- Assign this user right to only those accounts that are permitted to use the portable device.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
Although this portable device scenario does not normally apply to servers, 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 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
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
Anyone who has the **Remove computer from docking station** user right can log on and then remove a portable device from its docking station. If this setting is not defined, it has the same effect as if everyone was granted this right. However, the value of implementing this countermeasure is reduced by the following factors:
- If attackers can restart the device, they could remove it from the docking station after the BIOS starts but before the operating system starts.
- This setting does not affect servers because they typically are not installed in docking stations.
- An attacker could steal the device and the docking station together.
- Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
### Countermeasure
Ensure that only the local Administrators group and the user account to which the device is allocated are assigned the **Remove computer from docking station** user right.
### Potential impact
By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted this user right as necessary. If your organization's users are not members of the local Administrators groups on their portable devices, they cannot remove their portable devices from their docking stations if they do not first shut down the device. Therefore, you may want to assign the **Remove computer from docking station** privilege to the local Users group for portable devices.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

92
windows/keep-secure/replace-a-process-level-token.md
View File

@ -2,96 +2,94 @@
title: Replace a process level token (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Replace a process level token security policy setting.
ms.assetid: 5add02db-6339-489e-ba21-ccc3ccbe8745
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Replace a process level token
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Replace a process level token** security policy setting.
## Reference
This policy setting determines which parent processes can replace the access token that is associated with a child process.
Specifically, the **Replace a process level token** setting determines which user accounts can call the CreateProcessAsUser() application programming interface (API) so that one service can start another. An example of a process that uses this user right is Task Scheduler, where the user right is extended to any processes that can be managed by Task Scheduler.
An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account that is associated with the process or thread. With this user right, every child process that runs on behalf of this user account would have its access token replaced with the process level token.
Constant: SeAssignPrimaryTokenPrivilege
### Possible values
- User-defined list of accounts
- Defaults
- Not defined
### Best practices
- For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Network Service and Local Service on domain controllers and 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>Network Service</p>
<p>Local Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Network Service</p>
<p>Local Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Network Service</p>
<p>Local Service</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Network Service</p>
<p>Local Service</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Network Service</p>
<p>Local Service</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Network Service<br/>Local Service |
| Stand-Alone Server Default Settings | Network Service<br/>Local Service|
| Domain Controller Effective Default Settings | Network Service<br/>Local Service|
| Member Server Effective Default Settings | Network Service<br/>Local Service|
| Client Computer Effective Default Settings | Network Service<br/>Local Service|
 
## 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.
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
Users with the **Replace a process level token** user right can start processes as another user if they know the user’s credentials.
### Countermeasure
For member servers, ensure that only the Local Service and Network Service accounts have the **Replace a process level token** user right.
### Potential impact
On most computers, restricting the **Replace a process level token** user right to the Local Service and the Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the **Replace a process level token** user right to additional accounts. For example, IIS requires that the Service, Network Service, and IWAM\_*&lt;ComputerName&gt;* accounts be explicitly granted this user right.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

22
windows/keep-secure/requirements-for-deploying-applocker-policies.md
View File

@ -2,23 +2,30 @@
title: Requirements for deploying AppLocker policies (Windows 10)
description: This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies.
ms.assetid: 3e55bda2-3cd7-42c7-bad3-c7dfbe193d48
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Requirements for deploying AppLocker policies
**Applies to**
- Windows 10
This deployment topic for the IT professional lists the requirements that you need to consider before you deploy AppLocker policies.
The following requirements must be met or addressed before you deploy your AppLocker policies:
- [Deployment plan](#bkmk-reqdepplan)
- [Supported operating systems](#bkmk-reqsupportedos)
- [Policy distribution mechanism](#bkmk-reqpolicydistmech)
- [Event collection and analysis system](#bkmk-reqeventcollectionsystem)
### <a href="" id="bkmk-reqdepplan"></a>Deployment plan
An AppLocker policy deployment plan is the result of investigating which applications are required and necessary in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see [AppLocker Design Guide](applocker-policies-design-guide.md). The following table is an example of the data you need to collect and the decisions you need to make to successfully deploy AppLocker policies on the supported operating systems (as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
<table style="width:100%;">
<colgroup>
<col width="11%" />
@ -116,6 +123,7 @@ An AppLocker policy deployment plan is the result of investigating which applica
</table>
 
**Event processing policy**
<table>
<colgroup>
<col width="20%" />
@ -153,6 +161,7 @@ An AppLocker policy deployment plan is the result of investigating which applica
</table>
 
**Policy maintenance policy**
<table>
<colgroup>
<col width="20%" />
@ -194,15 +203,20 @@ An AppLocker policy deployment plan is the result of investigating which applica
</table>
 
### <a href="" id="bkmk-reqsupportedos"></a>Supported operating systems
AppLocker is supported only on certain operating systems. Some features are not available on all operating systems. For more information, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
### <a href="" id="bkmk-reqpolicydistmech"></a>Policy distribution mechanism
You need a way to distribute the AppLocker policies throughout the targeted business groups. AppLocker uses Group Policy management architecture to effectively distribute application control policies. AppLocker policies can also be configured on individual computers by using the Local Security Policy snap-in.
### <a href="" id="bkmk-reqeventcollectionsystem"></a>Event collection and analysis system
Event processing is important to understand application usage. You must have a process in place to collect and analyze AppLocker events so that application usage is appropriately restricted and understood. For procedures to monitor AppLocker events, see:
- [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md)
- [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md)
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
## See also
[AppLocker deployment guide](applocker-policies-deployment-guide.md)
 
 
- [AppLocker deployment guide](applocker-policies-deployment-guide.md)

225
windows/keep-secure/requirements-to-use-applocker.md
View File

@ -2,211 +2,60 @@
title: Requirements to use AppLocker (Windows 10)
description: This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems.
ms.assetid: dc380535-071e-4794-8f9d-e5d1858156f0
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Requirements to use AppLocker
**Applies to**
- Windows 10
This topic for the IT professional lists software requirements to use AppLocker on the supported Windows operating systems.
## General requirements
To use AppLocker, you need:
- A device running a supported operating system to create the rules. The computer can be a domain controller.
- For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC) or Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
- Devices running a supported operating system to enforce the AppLocker rules that you create.
**Note**  
You can use Software Restriction Policies with AppLocker, but with some limitations. For more info, see [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
>**Note:**  You can use Software Restriction Policies with AppLocker, but with some limitations. For more info, see [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md).
 
## Operating system requirements
The following table show the on which operating systems AppLocker features are supported.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Version</th>
<th align="left">Can be configured</th>
<th align="left">Can be enforced</th>
<th align="left">Available rules</th>
<th align="left">Notes</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Windows 10</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>You can use the [AppLocker CSP](http://msdn.microsoft.com/library/windows/hardware/dn920019.aspx) to configure AppLocker policies on any edition of Windows 10. You can only manage AppLocker with Group Policy on devices running Windows 10 Enterprise and Windows Server 2016 Technical Preview.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2012 R2</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows 8.1</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Only the Enterprise edition supports AppLocker</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows RT 8.1</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Server 2012 Standard</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2012 Datacenter</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows 8 Pro</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 8 Enterprise</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Packaged apps</p>
<p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows RT</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2008 R2 Standard</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Server 2008 R2 Enterprise</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2008 R2 Datacenter</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Server 2008 R2 for Itanium-Based Systems</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 7 Ultimate</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows 7 Enterprise</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>Packaged app rules will not be enforced.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 7 Professional</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>Executable</p>
<p>Windows Installer</p>
<p>Script</p>
<p>DLL</p></td>
<td align="left"><p>No AppLocker rules are enforced.</p></td>
</tr>
</tbody>
</table>
| Version | Can be configured | Can be enforced | Available rules | Notes |
| - | - | - | - | - |
| Windows 10| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| You can use the [AppLocker CSP](http://msdn.microsoft.com/library/windows/hardware/dn920019.aspx) to configure AppLocker policies on any edition of Windows 10. You can only manage AppLocker with Group Policy on devices running Windows 10 Enterprise and Windows Server 2016 Technical Preview. |
| Windows Server 2012 R2| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| |
| Windows 8.1| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL| Only the Enterprise edition supports AppLocker|
| Windows RT 8.1| No| No| N/A||
| Windows Server 2012 Standard| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL||
| Windows Server 2012 Datacenter| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL||
| Windows 8 Pro| No| No| N/A||
| Windows 8 Enterprise| Yes| Yes| Packaged apps<br/>Executable<br/>Windows Installer<br/>Script<br/>DLL||
| Windows RT| No| No| N/A| |
| Windows Server 2008 R2 Standard| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows Server 2008 R2 Enterprise|Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows Server 2008 R2 Datacenter| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows Server 2008 R2 for Itanium-Based Systems| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows 7 Ultimate| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows 7 Enterprise| Yes| Yes| Executable<br/>Windows Installer<br/>Script<br/>DLL| Packaged app rules will not be enforced.|
| Windows 7 Professional| Yes| No| Executable<br/>Windows Installer<br/>Script<br/>DLL| No AppLocker rules are enforced.|
 
AppLocker is not supported on versions of the Windows operating system not listed above. Software Restriction Policies can be used with those versions. However, the SRP Basic User feature is not supported on the above operating systems.
## See also
[Administer AppLocker](administer-applocker.md)
[Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
[Optimize AppLocker performance](optimize-applocker-performance.md)
[Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md)
[Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md)
[AppLocker Design Guide](applocker-policies-design-guide.md)
 
 
- [Administer AppLocker](administer-applocker.md)
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
- [Optimize AppLocker performance](optimize-applocker-performance.md)
- [Use AppLocker and Software Restriction Policies in the same domain](use-applocker-and-software-restriction-policies-in-the-same-domain.md)
- [Manage packaged apps with AppLocker](manage-packaged-apps-with-applocker.md)
- [AppLocker Design Guide](applocker-policies-design-guide.md)

76
windows/keep-secure/reset-account-lockout-counter-after.md
View File

@ -2,76 +2,68 @@
title: Reset account lockout counter after (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Reset account lockout counter after security policy setting.
ms.assetid: d5ccf6dd-5ba7-44a9-8e0b-c478d8b1442c
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Reset account lockout counter after
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Reset account lockout counter after** security policy setting.
## Reference
The **Reset account lockout counter after** policy setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0. If [Account lockout threshold](account-lockout-threshold.md) is set to a number greater than zero, this reset time must be less than or equal to the value of [Account lockout duration](account-lockout-duration.md).
A disadvantage to setting this too high is that users lock themselves out for an inconveniently long period if they exceed the account lockout threshold through logon errors. Users may make excessive Help Desk calls.
### Possible values
- A user-defined number of minutes from 1 through 99,999
- Not defined
### Best practices
- You need to determine the threat level for your organization and balance that against the cost of your Help Desk support for password resets. Each organization will have specific requirements.
### Location
**Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Account Lockout 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 Group Policy Object (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 applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Not defined</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 Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| Not defined|
| Default domain controller policy | Not defined|
| Stand-alone server default settings | Not applicable|
| Domain controller effective default settings | Not defined|
| Member server effective default settings | Not defined|
| Client computer effective default settings | Not applicable|
 
## 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
Users can accidentally lock themselves out of their accounts if they mistype their password multiple times.
### Countermeasure
Configure the **Reset account lockout counter after** policy setting to 30.
### Potential impact
If you do not configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to log on to each user's account numerous times and lock out their accounts, a denial-of-service (DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to log on after a failed logon within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk.
## Related topics
[Account Lockout Policy](account-lockout-policy.md)
 
 
- [Account Lockout Policy](account-lockout-policy.md)

97
windows/keep-secure/restore-files-and-directories.md
View File

@ -2,102 +2,97 @@
title: Restore files and directories (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Restore files and directories security policy setting.
ms.assetid: c673c0fa-6f49-4edd-8c1f-c5e8513f701d
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Restore files and directories
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Restore files and directories** security policy setting.
## Reference
This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories, and it determines which users can set valid security principals as the owner of an object.
Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system:
- **Traverse folder / execute file**
- **Write**
Constant: SeRestorePrivilege
### Possible values
- User-defined list of accounts
- Defaults
- Not Defined
### Best practices
- Users with this user right can overwrite registry settings, hide data, and gain ownership of system objects, so only assign this user right to trusted users.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, this right is granted to the Administrators, Backup Operators, and Server Operators groups on domain controllers, and to the Administrators and Backup Operators groups 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></p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</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>
<p>Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</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>
<p>Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
|Default Domain Policy | |
| Default Domain Controller Policy| Administrators<br/>Backup Operators<br/>Server Operators|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators|
| Domain Controller Effective Default Settings | Administrators<br/>Backup Operators<br/>Server Operators|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators|
| Client Computer Effective Default Settings | Administrators<br/>Backup Operators|
 
## 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 **Restore files and directories** user right could restore sensitive data to a computer and overwrite data that is more recent, which could lead to loss of important data, data corruption, or a denial-of-service condition. Attackers could overwrite executable files that are used by legitimate administrators or system services with versions that include malicious software to grant themselves elevated privileges, compromise data, or install programs that provide continued access to the device
**Note**  
Even if the following countermeasure is configured, an attacker could restore data to a computer in a domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media that are used to back up data.
>**Note:**  Even if the following countermeasure is configured, an attacker could restore data to a computer in a domain that is controlled by the attacker. Therefore, it is critical that organizations carefully protect the media that are used to back up data.
 
### Countermeasure
Ensure that only the local Administrators group is assigned the **Restore files and directories** user right unless your organization has clearly defined roles for backup and for restore personnel.
### Potential impact
If you remove the **Restore files and directories** user right from the Backup Operators group and other accounts, users who are not members of the local Administrators group cannot load data backups. If restoring backups is delegated to a subset of IT staff in your organization, you should verify that this change does not negatively affect the ability of your organization's personnel to do their jobs.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

21
windows/keep-secure/run-the-automatically-generate-rules-wizard.md
View File

@ -2,19 +2,26 @@
title: Run the Automatically Generate Rules wizard (Windows 10)
description: This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
ms.assetid: 8cad1e14-d5b2-437c-8f88-70cffd7b3d8e
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Run the Automatically Generate Rules wizard
**Applies to**
- Windows 10
This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
AppLocker allows you to automatically generate rules for all files within a folder. It will scan the specified folder and create the condition types that you choose for each file in that folder.
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 device 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 automatically generate rules**
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically generate rules for executable, Windows Installer, script and packaged app rules.
3. Click **Automatically Generate Rules**.
@ -22,15 +29,13 @@ You can perform this task by using the Group Policy Management Console for an Ap
5. Click **Select** to choose the security group in which the default rules should be applied. By default, this is the **Everyone** group.
6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you have selected. Accept the provided name or type a different name, and then click **Next**.
7. On the **Rule Preferences** page, choose the conditions that you want the wizard to use while creating rules, and then click **Next**. For more info about rule conditions, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
**Note**  
The **Reduce the number of rules created by grouping similar files** check box is selected by default. This helps you organize AppLocker rules and reduce the number of rules that you create by performing the following operations for the rule condition that you select:
>**Note:**  The **Reduce the number of rules created by grouping similar files** check box is selected by default. This helps you organize AppLocker rules and reduce the number of rules that you create by performing the following operations for the rule condition that you select:
- One publisher condition is created for all files that have the same publisher and product name.
- One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder are not signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
- One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the wizard creates a file hash rule for each file.
 
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click **Previous** to return to the page where you can change your selections. After reviewing the rules, click **Create**.
**Note**  
If you are running the wizard to create your first rules for a GPO, you will be prompted to create the default rules, which allow critical system files to run, after completing the wizard. You may edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after replacing them with your custom rules.
 
 
 
>**Note:**  If you are running the wizard to create your first rules for a GPO, you will be prompted to create the default rules, which allow critical system files to run, after completing the wizard. You may edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after replacing them with your custom rules.

54
windows/keep-secure/script-rules-in-applocker.md
View File

@ -2,61 +2,35 @@
title: Script rules in AppLocker (Windows 10)
description: This topic describes the file formats and available default rules for the script rule collection.
ms.assetid: fee24ca4-935a-4c5e-8a92-8cf1d134d35f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Script rules in AppLocker
**Applies to**
- Windows 10
This topic describes the file formats and available default rules for the script rule collection.
AppLocker defines script rules to include only the following file formats:
- .ps1
- .bat
- .cmd
- .vbs
- .js
The following table lists the default rules that are available for the script rule collection.
<table>
<colgroup>
<col width="25%" />
<col width="25%" />
<col width="25%" />
<col width="25%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Purpose</th>
<th align="left">Name</th>
<th align="left">User</th>
<th align="left">Rule condition type</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Allows members of the local Administrators group to run all scripts</p></td>
<td align="left"><p>(Default Rule) All scripts</p></td>
<td align="left"><p>BUILTIN\Administrators</p></td>
<td align="left"><p>Path: *</p></td>
</tr>
<tr class="even">
<td align="left"><p>Allow all users to run scripts in the Windows folder</p></td>
<td align="left"><p>(Default Rule) All scripts located in the Windows folder</p></td>
<td align="left"><p>Everyone</p></td>
<td align="left"><p>Path: %windir%\*</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Allow all users to run scripts in the Program Files folder</p></td>
<td align="left"><p>(Default Rule) All scripts located in the Program Files folder</p></td>
<td align="left"><p>Everyone</p></td>
<td align="left"><p>Path: %programfiles%\*</p></td>
</tr>
</tbody>
</table>
| Purpose | Name | User | Rule condition type |
| - | - | - | - |
| Allows members of the local Administrators group to run all scripts| (Default Rule) All scripts| BUILTIN\Administrators | Path: *|
| Allow all users to run scripts in the Windows folder| (Default Rule) All scripts located in the Windows folder| Everyone | Path: %windir%\*|
| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder|Everyone | Path: %programfiles%\*|
 
## Related topics
[Understanding AppLocker default rules](understanding-applocker-default-rules.md)
 
 
- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)

12
windows/keep-secure/secpol-advanced-security-audit-policy-settings.md
View File

@ -2,22 +2,28 @@
title: Advanced security audit policy settings (Windows 10)
description: Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.
ms.assetid: 6BF9A642-DBC3-4101-94A3-B2316C553CE3
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Advanced security audit policy settings
**Applies to**
- Windows 10
Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.
The security audit policy settings under **Security Settings\\Advanced Audit Policy Configuration** can help your organization audit compliance with important business-related and security-related rules by tracking precisely defined activities, such as:
- A group administrator has modified settings or data on servers that contain finance information.
- An employee within a defined group has accessed an important file.
- The correct system access control list (SACL) is applied to every file and folder or registry key on a computer or file share as a verifiable safeguard against undetected access.
You can access these audit policy settings through the Local Security Policy snap-in (secpol.msc) on the local device or by using Group Policy.
These Advanced Audit policy settings allow you to select only the behaviors that you want to monitor. You can exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because security audit policies can be applied by using domain Group Policy Objects, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.
For more info, see [Advanced security audit policies](advanced-security-auditing.md).
 
 

35
windows/keep-secure/security-auditing-overview.md
View File

@ -2,42 +2,31 @@
title: Security auditing (Windows 10)
description: Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network.
ms.assetid: 2d9b8142-49bd-4a33-b246-3f0c2a5f32d4
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security auditing
**Applies to**
- Windows 10
Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network.
## <a href="" id="bkmk-over"></a>
Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you have determined to be valuable in your risk assessment.
For info on the changes that were added in Windows 10, see [Security auditing](../whats-new/security-auditing.md).
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Basic security audit policies](basic-security-audit-policies.md)</p></td>
<td align="left"><p>Before you implement auditing, you must decide on an auditing policy. A basic audit policy specifies categories of security-related events that you want to audit. When this version of Windows is first installed, all auditing categories are disabled. By enabling various auditing event categories, you can implement an auditing policy that suits the security needs of your organization.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Advanced security audit policies](advanced-security-auditing.md)</p></td>
<td align="left"><p>Advanced security audit policy settings are found in <strong>Security Settings\Advanced Audit Policy Configuration\System Audit Policies</strong> and appear to overlap with basic security audit policies, but they are recorded and applied differently.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
|[Basic security audit policies](basic-security-audit-policies.md) |Before you implement auditing, you must decide on an auditing policy. A basic audit policy specifies categories of security-related events that you want to audit. When this version of Windows is first installed, all auditing categories are disabled. By enabling various auditing event categories, you can implement an auditing policy that suits the security needs of your organization. |
|[Advanced security audit policies](advanced-security-auditing.md) |Advanced security audit policy settings are found in **Security Settings\Advanced Audit Policy Configuration\System Audit Policies** and appear to overlap with basic security audit policies, but they are recorded and applied differently. |
 
 
 

30
windows/keep-secure/security-considerations-for-applocker.md
View File

@ -2,33 +2,45 @@
title: Security considerations for AppLocker (Windows 10)
description: This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
ms.assetid: 354a5abb-7b31-4bea-a442-aa9666117625
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security considerations for AppLocker
**Applies to**
- Windows 10
This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to a specific group of users or within a defined business group. The following are security considerations for AppLocker:
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/ee460962.aspx).
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If the local computer is not joined to a domain and is not administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of interpreted code, such as Microsoft Office macros.
**Important**  
You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
>**Important:**  You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
 
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
**Note**  
Two flags that illustrate this condition are `SANDBOX_INERT`, which can be passed to `CreateRestrictedToken`, and `LOAD_IGNORE_CODE_AUTHZ_LEVEL`, which can be passed to `LoadLibraryEx`. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
>**Note:**  Two flags that illustrate this condition are `SANDBOX_INERT`, which can be passed to `CreateRestrictedToken`, and `LOAD_IGNORE_CODE_AUTHZ_LEVEL`, which can be passed to `LoadLibraryEx`. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
 
## Related topics
[AppLocker technical reference](applocker-technical-reference.md)
 
 
- [AppLocker technical reference](applocker-technical-reference.md)

508
windows/keep-secure/security-options.md
View File

@ -2,417 +2,127 @@
title: Security Options (Windows 10)
description: Provides an introduction to the settings under Security Options of the local security policies and links to information about each setting.
ms.assetid: 405ea253-8116-4e57-b08e-14a8dcdca92b
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security Options
**Applies to**
- Windows 10
Provides an introduction to the settings under **Security Options** of the local security policies and links to information about each setting.
The **Security Options** contain the following groupings of security policy settings that allow you to configure the behavior of the local computer. Some of these policies can be included in a Group Policy Object and distributed over your organization.
If you edit policy settings locally on a device, you will affect the settings on only that one device. If you configure the settings in a Group Policy Object (GPO), the settings apply to all devices that are subject to that GPO.
For info about setting security policies, see [Configure security policy settings](how-to-configure-security-policy-settings.md).
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Accounts: Administrator account status](accounts-administrator-account-status.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Accounts: Administrator account status</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management, and security considerations for the <strong>Accounts: Block Microsoft accounts</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Accounts: Guest account status](accounts-guest-account-status.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Accounts: Guest account status</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Accounts: Limit local account use of blank passwords to console logon only](accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Accounts: Limit local account use of blank passwords to console logon only</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Accounts: Rename administrator account](accounts-rename-administrator-account.md)</p></td>
<td align="left"><p>This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Accounts: Rename guest account](accounts-rename-guest-account.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Accounts: Rename guest account</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Audit: Audit the access of global system objects](audit-audit-the-access-of-global-system-objects.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Audit: Audit the access of global system objects</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Audit: Audit the use of Backup and Restore privilege](audit-audit-the-use-of-backup-and-restore-privilege.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Audit: Audit the use of Backup and Restore privilege</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings](audit-force-audit-policy-subcategory-settings-to-override.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management practices, and security considerations for the <strong>Audit: Shut down system immediately if unable to log security audits</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax</strong> policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Devices: Allow undock without having to log on](devices-allow-undock-without-having-to-log-on.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Devices: Allow undock without having to log on</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Devices: Allowed to format and eject removable media](devices-allowed-to-format-and-eject-removable-media.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Devices: Allowed to format and eject removable media</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Devices: Prevent users from installing printer drivers](devices-prevent-users-from-installing-printer-drivers.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Devices: Prevent users from installing printer drivers</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Devices: Restrict CD-ROM access to locally logged-on user only](devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Devices: Restrict CD-ROM access to locally logged-on user only</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Devices: Restrict floppy access to locally logged-on user only](devices-restrict-floppy-access-to-locally-logged-on-user-only.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Devices: Restrict floppy access to locally logged-on user only</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Domain controller: Allow server operators to schedule tasks](domain-controller-allow-server-operators-to-schedule-tasks.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain controller: Allow server operators to schedule tasks</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Domain controller: LDAP server signing requirements](domain-controller-ldap-server-signing-requirements.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain controller: LDAP server signing requirements</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Domain controller: Refuse machine account password changes](domain-controller-refuse-machine-account-password-changes.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain controller: Refuse machine account password changes</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Digitally encrypt or sign secure channel data (always)</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Digitally encrypt secure channel data (when possible)</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Digitally sign secure channel data (when possible)</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Disable machine account password changes</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Maximum machine account password age</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Domain member: Require strong (Windows 2000 or later) session key](domain-member-require-strong-windows-2000-or-later-session-key.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Domain member: Require strong (Windows 2000 or later) session key</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Display user information when the session is locked](interactive-logon-display-user-information-when-the-session-is-locked.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Interactive logon: Display user information when the session is locked</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Interactive logon: Do not display last user name</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Do not require CTRL+ALT+DEL](interactive-logon-do-not-require-ctrl-alt-del.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Interactive logon: Do not require CTRL+ALT+DEL</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Machine account lockout threshold](interactive-logon-machine-account-lockout-threshold.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management, and security considerations for the <strong>Interactive logon: Machine account lockout threshold</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Machine inactivity limit](interactive-logon-machine-inactivity-limit.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management, and security considerations for the <strong>Interactive logon: Machine inactivity limit</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management, and security considerations for the <strong>Interactive logon: Message text for users attempting to log on</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Interactive logon: Message title for users attempting to log on</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Interactive logon: Number of previous logons to cache (in case domain controller is not available)</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Prompt user to change password before expiration](interactive-logon-prompt-user-to-change-password-before-expiration.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Interactive logon: Prompt user to change password before expiration</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Interactive logon: Require Domain Controller authentication to unlock workstation</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Interactive logon: Require smart card](interactive-logon-require-smart-card.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Interactive logon: Require smart card</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Interactive logon: Smart card removal behavior](interactive-logon-smart-card-removal-behavior.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Interactive logon: Smart card removal behavior</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Microsoft network client: Digitally sign communications (always)</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Microsoft network client: Digitally sign communications (if server agrees)</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Microsoft network client: Send unencrypted password to third-party SMB servers](microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Microsoft network client: Send unencrypted password to third-party SMB servers</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Microsoft network server: Amount of idle time required before suspending session](microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Microsoft network server: Amount of idle time required before suspending session</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Microsoft network server: Attempt S4U2Self to obtain claim information](microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management, and security considerations for the <strong>Microsoft network server: Attempt S4U2Self to obtain claim information</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Microsoft network server: Digitally sign communications (always)</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Microsoft network server: Digitally sign communications (if client agrees)</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Microsoft network server: Disconnect clients when logon hours expire](microsoft-network-server-disconnect-clients-when-logon-hours-expire.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Microsoft network server: Disconnect clients when logon hours expire</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Microsoft network server: Server SPN target name validation level](microsoft-network-server-server-spn-target-name-validation-level.md)</p></td>
<td align="left"><p>Describes the best practices, location, and values, policy management and security considerations for the <strong>Microsoft network server: Server SPN target name validation level</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Allow anonymous SID/Name translation](network-access-allow-anonymous-sidname-translation.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Allow anonymous SID/Name translation</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network access: Do not allow anonymous enumeration of SAM accounts](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Network access: Do not allow anonymous enumeration of SAM accounts</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Do not allow anonymous enumeration of SAM accounts and shares](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Network access: Do not allow anonymous enumeration of SAM accounts and shares</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network access: Do not allow storage of passwords and credentials for network authentication](network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Do not allow storage of passwords and credentials for network authentication</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Let Everyone permissions apply to anonymous users](network-access-let-everyone-permissions-apply-to-anonymous-users.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Let Everyone permissions apply to anonymous users</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network access: Named Pipes that can be accessed anonymously](network-access-named-pipes-that-can-be-accessed-anonymously.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Named Pipes that can be accessed anonymously</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Remotely accessible registry paths](network-access-remotely-accessible-registry-paths.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Remotely accessible registry paths</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network access: Remotely accessible registry paths and subpaths](network-access-remotely-accessible-registry-paths-and-subpaths.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Network access: Remotely accessible registry paths and subpaths</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Restrict anonymous access to Named Pipes and Shares</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Shares that can be accessed anonymously</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network access: Sharing and security model for local accounts</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md)</p></td>
<td align="left"><p>Describes the location, values, policy management, and security considerations for the <strong>Network security: Allow Local System to use computer identity for NTLM</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>Network security: Allow LocalSystem NULL session fallback</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Allow PKU2U authentication requests to this computer to use online identities](network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md)</p></td>
<td align="left"><p>Describes the best practices, location, and values for the <strong>Network Security: Allow PKU2U authentication requests to this computer to use online identities</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Configure encryption types allowed for Kerberos Win7 only](network-security-configure-encryption-types-allowed-for-kerberos.md)</p></td>
<td align="left"><p>Describes the best practices, location, values and security considerations for the <strong>Network security: Configure encryption types allowed for Kerberos Win7 only</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Do not store LAN Manager hash value on next password change](network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network security: Do not store LAN Manager hash value on next password change</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network security: Force logoff when logon hours expire</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network security: LAN Manager authentication level</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: LDAP client signing requirements](network-security-ldap-client-signing-requirements.md)</p></td>
<td align="left"><p>This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Minimum session security for NTLM SSP based (including secure RPC) clients](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network security: Minimum session security for NTLM SSP based (including secure RPC) clients</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Minimum session security for NTLM SSP based (including secure RPC) servers](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Network security: Minimum session security for NTLM SSP based (including secure RPC) servers</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network security: Restrict NTLM: Add server exceptions in this domain</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network Security: Restrict NTLM: Audit incoming NTLM traffic</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network Security: Restrict NTLM: Audit NTLM authentication in this domain</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network Security: Restrict NTLM: Incoming NTLM traffic</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Network security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network Security: Restrict NTLM: NTLM authentication in this domain</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, management aspects, and security considerations for the <strong>Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Recovery console: Allow automatic administrative logon](recovery-console-allow-automatic-administrative-logon.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Recovery console: Allow automatic administrative logon</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Recovery console: Allow floppy copy and access to all drives and folders](recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Recovery console: Allow floppy copy and access to all drives and folders</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Shutdown: Allow system to be shut down without having to log on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Shutdown: Allow system to be shut down without having to log on</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>Shutdown: Clear virtual memory pagefile</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[System cryptography: Force strong key protection for user keys stored on the computer](system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>System cryptography: Force strong key protection for user keys stored on the computer</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md)</p></td>
<td align="left"><p>This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[System objects: Require case insensitivity for non-Windows subsystems](system-objects-require-case-insensitivity-for-non-windows-subsystems.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>System objects: Require case insensitivity for non-Windows subsystems</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)](system-objects-strengthen-default-permissions-of-internal-system-objects.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[System settings: Optional subsystems](system-settings-optional-subsystems.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>System settings: Optional subsystems</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[System settings: Use certificate rules on Windows executables for Software Restriction Policies](system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>System settings: Use certificate rules on Windows executables for Software Restriction Policies</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[User Account Control: Admin Approval Mode for the Built-in Administrator account](user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Admin Approval Mode for the Built-in Administrator account</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, and security considerations for the <strong>User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Behavior of the elevation prompt for standard users</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[User Account Control: Detect application installations and prompt for elevation](user-account-control-detect-application-installations-and-prompt-for-elevation.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Detect application installations and prompt for elevation</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control: Only elevate executables that are signed and validated](user-account-control-only-elevate-executables-that-are-signed-and-validated.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Only elevate executables that are signed and validated</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Only elevate UIAccess applications that are installed in secure locations</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Run all administrators in Admin Approval Mode</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Switch to the secure desktop when prompting for elevation</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control: Virtualize file and registry write failures to per-user locations](user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management and security considerations for the <strong>User Account Control: Virtualize file and registry write failures to per-user locations</strong> security policy setting.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Accounts: Administrator account status](accounts-administrator-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Administrator account status** security policy setting.|
| [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md) | Describes the best practices, location, values, management, and security considerations for the **Accounts: Block Microsoft accounts** security policy setting.|
| [Accounts: Guest account status](accounts-guest-account-status.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Guest account status** security policy setting.|
| [Accounts: Limit local account use of blank passwords to console logon only](accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Limit local account use of blank passwords to console logon only** security policy setting. |
| [Accounts: Rename administrator account](accounts-rename-administrator-account.md)| This security policy reference topic for the IT professional describes the best practices, location, values, and security considerations for this policy setting.|
| [Accounts: Rename guest account](accounts-rename-guest-account.md) | Describes the best practices, location, values, and security considerations for the **Accounts: Rename guest account** security policy setting.|
| [Audit: Audit the access of global system objects](audit-audit-the-access-of-global-system-objects.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the access of global system objects** security policy setting.|
| [Audit: Audit the use of Backup and Restore privilege](audit-audit-the-use-of-backup-and-restore-privilege.md) | Describes the best practices, location, values, and security considerations for the **Audit: Audit the use of Backup and Restore privilege** security policy setting.|
| [Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings](audit-force-audit-policy-subcategory-settings-to-override.md) | Describes the best practices, location, values, and security considerations for the **Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings** security policy setting. |
| [Audit: Shut down system immediately if unable to log security audits](audit-shut-down-system-immediately-if-unable-to-log-security-audits.md)| Describes the best practices, location, values, management practices, and security considerations for the **Audit: Shut down system immediately if unable to log security audits** security policy setting. |
| [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. |
| [DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md)| Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting. |
| [Devices: Allow undock without having to log on](devices-allow-undock-without-having-to-log-on.md)| Describes the best practices, location, values, and security considerations for the **Devices: Allow undock without having to log on** security policy setting.|
| [Devices: Allowed to format and eject removable media](devices-allowed-to-format-and-eject-removable-media.md) | Describes the best practices, location, values, and security considerations for the **Devices: Allowed to format and eject removable media** security policy setting.|
| [Devices: Prevent users from installing printer drivers](devices-prevent-users-from-installing-printer-drivers.md) | Describes the best practices, location, values, and security considerations for the **Devices: Prevent users from installing printer drivers** security policy setting.|
| [Devices: Restrict CD-ROM access to locally logged-on user only](devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md) | Describes the best practices, location, values, and security considerations for the **Devices: Restrict CD-ROM access to locally logged-on user only** security policy setting. |
| [Devices: Restrict floppy access to locally logged-on user only](devices-restrict-floppy-access-to-locally-logged-on-user-only.md)| Describes the best practices, location, values, and security considerations for the **Devices: Restrict floppy access to locally logged-on user only** security policy setting. |
| [Domain controller: Allow server operators to schedule tasks](domain-controller-allow-server-operators-to-schedule-tasks.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: Allow server operators to schedule tasks** security policy setting. |
| [Domain controller: LDAP server signing requirements](domain-controller-ldap-server-signing-requirements.md)| Describes the best practices, location, values, and security considerations for the **Domain controller: LDAP server signing requirements** security policy setting. |
| [Domain controller: Refuse machine account password changes](domain-controller-refuse-machine-account-password-changes.md) | Describes the best practices, location, values, and security considerations for the **Domain controller: Refuse machine account password changes** security policy setting.|
| [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) | Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt or sign secure channel data (always)** security policy setting. |
| [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally encrypt secure channel data (when possible)** security policy setting. |
| [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Digitally sign secure channel data (when possible)** security policy setting.|
| [Domain member: Disable machine account password changes](domain-member-disable-machine-account-password-changes.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Disable machine account password changes** security policy setting.
| [Domain member: Maximum machine account password age](domain-member-maximum-machine-account-password-age.md) |Describes the best practices, location, values, and security considerations for the **Domain member: Maximum machine account password age** security policy setting.|
|[Domain member: Require strong (Windows 2000 or later) session key](domain-member-require-strong-windows-2000-or-later-session-key.md)| Describes the best practices, location, values, and security considerations for the **Domain member: Require strong (Windows 2000 or later) session key** security policy setting. |
| [Interactive logon: Display user information when the session is locked](interactive-logon-display-user-information-when-the-session-is-locked.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Display user information when the session is locked** security policy setting. |
| [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not display last user name** security policy setting.|
| [Interactive logon: Do not require CTRL+ALT+DEL](interactive-logon-do-not-require-ctrl-alt-del.md)| Describes the best practices, location, values, and security considerations for the **Interactive logon: Do not require CTRL+ALT+DEL** security policy setting.|
| [Interactive logon: Machine account lockout threshold](interactive-logon-machine-account-lockout-threshold.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine account lockout threshold** security policy setting.|
| [Interactive logon: Machine inactivity limit](interactive-logon-machine-inactivity-limit.md)| Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Machine inactivity limit** security policy setting.|
| [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md) | Describes the best practices, location, values, management, and security considerations for the **Interactive logon: Message text for users attempting to log on** security policy setting. |
| [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)| Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Message title for users attempting to log on** security policy setting. |
| [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md)| Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting. |
| [Interactive logon: Prompt user to change password before expiration](interactive-logon-prompt-user-to-change-password-before-expiration.md)| Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Prompt user to change password before expiration** security policy setting. |
| [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md)| Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Require Domain Controller authentication to unlock workstation** security policy setting. |
| [Interactive logon: Require smart card](interactive-logon-require-smart-card.md) | Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Require smart card** security policy setting.|
| [Interactive logon: Smart card removal behavior](interactive-logon-smart-card-removal-behavior.md) | Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.|
| [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md) | Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting. |
| [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network client: Digitally sign communications (if server agrees)** security policy setting. |
| [Microsoft network client: Send unencrypted password to third-party SMB servers](microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md)| Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Send unencrypted password to third-party SMB servers** security policy setting. |
| [Microsoft network server: Amount of idle time required before suspending session](microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Amount of idle time required before suspending session** security policy setting. |
| [Microsoft network server: Attempt S4U2Self to obtain claim information](microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md)| Describes the best practices, location, values, management, and security considerations for the **Microsoft network server: Attempt S4U2Self to obtain claim information** security policy setting. |
| [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)| Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting.|
| [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)| Describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (if client agrees)** security policy setting. |
| [Microsoft network server: Disconnect clients when logon hours expire](microsoft-network-server-disconnect-clients-when-logon-hours-expire.md)| Describes the best practices, location, values, and security considerations for the **Microsoft network server: Disconnect clients when logon hours expire** security policy setting. |
| [Microsoft network server: Server SPN target name validation level](microsoft-network-server-server-spn-target-name-validation-level.md)| Describes the best practices, location, and values, policy management and security considerations for the **Microsoft network server: Server SPN target name validation level** security policy setting. |
| [Network access: Allow anonymous SID/Name translation](network-access-allow-anonymous-sidname-translation.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Allow anonymous SID/Name translation** security policy setting.|
| [Network access: Do not allow anonymous enumeration of SAM accounts](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts** security policy setting. |
| [Network access: Do not allow anonymous enumeration of SAM accounts and shares](network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md)| Describes the best practices, location, values, and security considerations for the **Network access: Do not allow anonymous enumeration of SAM accounts and shares** security policy setting. |
| [Network access: Do not allow storage of passwords and credentials for network authentication](network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Do not allow storage of passwords and credentials for network authentication** security policy setting. |
| [Network access: Let Everyone permissions apply to anonymous users](network-access-let-everyone-permissions-apply-to-anonmous-users.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Let Everyone permissions apply to anonymous users** security policy setting. |
| [Network access: Named Pipes that can be accessed anonymously](network-access-named-pipes-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Named Pipes that can be accessed anonymously** security policy setting. |
| [Network access: Remotely accessible registry paths](network-access-remotely-accessible-registry-paths.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Remotely accessible registry paths** security policy setting.|
| [Network access: Remotely accessible registry paths and subpaths](network-access-remotely-accessible-registry-paths-and-subpaths.md)| Describes the best practices, location, values, and security considerations for the **Network access: Remotely accessible registry paths and subpaths** security policy setting. |
| [Network access: Restrict anonymous access to Named Pipes and Shares](network-access-restrict-anonymous-access-to-named-pipes-and-shares.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Restrict anonymous access to Named Pipes and Shares** security policy setting. |
| [Network access: Shares that can be accessed anonymously](network-access-shares-that-can-be-accessed-anonymously.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Shares that can be accessed anonymously** security policy setting. |
| [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md)| Describes the best practices, location, values, policy management and security considerations for the **Network access: Sharing and security model for local accounts** security policy setting. |
| [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md)| Describes the location, values, policy management, and security considerations for the **Network security: Allow Local System to use computer identity for NTLM** security policy setting. |
| [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md)| Describes the best practices, location, values, and security considerations for the **Network security: Allow LocalSystem NULL session fallback** security policy setting.|
| [Network security: Allow PKU2U authentication requests to this computer to use online identities](network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md)| Describes the best practices, location, and values for the **Network Security: Allow PKU2U authentication requests to this computer to use online identities** security policy setting. |
| [Network security: Configure encryption types allowed for Kerberos Win7 only](network-security-configure-encryption-types-allowed-for-kerberos.md)| Describes the best practices, location, values and security considerations for the **Network security: Configure encryption types allowed for Kerberos Win7 only** security policy setting. |
| [Network security: Do not store LAN Manager hash value on next password change](network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md)| Describes the best practices, location, values, policy management and security considerations for the **Network security: Do not store LAN Manager hash value on next password change** security policy setting. |
| [Network security: Force logoff when logon hours expire](network-security-force-logoff-when-logon-hours-expire.md)| Describes the best practices, location, values, policy management and security considerations for the **Network security: Force logoff when logon hours expire** security policy setting. |
| [Network security: LAN Manager authentication level](network-security-lan-manager-authentication-level.md)| Describes the best practices, location, values, policy management and security considerations for the **Network security: LAN Manager authentication level** security policy setting.|
| [Network security: LDAP client signing requirements](network-security-ldap-client-signing-requirements.md) | This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. This information applies to computers running at least the Windows Server 2008 operating system. |
| [Network security: Minimum session security for NTLM SSP based (including secure RPC) clients](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-clients.md)| Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) clients** security policy setting. |
| [Network security: Minimum session security for NTLM SSP based (including secure RPC) servers](network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md)| Describes the best practices, location, values, policy management and security considerations for the **Network security: Minimum session security for NTLM SSP based (including secure RPC) servers** security policy setting. |
| [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication** security policy setting. |
| [Network security: Restrict NTLM: Add server exceptions in this domain](network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network security: Restrict NTLM: Add server exceptions in this domain** security policy setting. |
| [Network security: Restrict NTLM: Audit incoming NTLM traffic](network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit incoming NTLM traffic** security policy setting. |
| [Network security: Restrict NTLM: Audit NTLM authentication in this domain](network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Audit NTLM authentication in this domain** security policy setting. |
| [Network security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Incoming NTLM traffic** security policy setting. |
| [Network security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: NTLM authentication in this domain** security policy setting. |
| [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md)| Describes the best practices, location, values, management aspects, and security considerations for the **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers** security policy setting. |
| [Recovery console: Allow automatic administrative logon](recovery-console-allow-automatic-administrative-logon.md)| Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow automatic administrative logon** security policy setting. |
| [Recovery console: Allow floppy copy and access to all drives and folders](recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md)| Describes the best practices, location, values, policy management and security considerations for the **Recovery console: Allow floppy copy and access to all drives and folders** security policy setting. |
| [Shutdown: Allow system to be shut down without having to lg on](shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md)| Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting. |
| [Shutdown: Clear virtual memory pagefile](shutdown-clear-virtual-memory-pagefile.md)| Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.|
| [System cryptography: Force strong key protection for user keys stored on the computer](system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md)| Describes the best practices, location, values, policy management and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting. |
| [System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing](system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md)| This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting. |
| [System objects: Require case insensitivity for non-Windows subsystems](system-objects-require-case-insensitivity-for-non-windows-subsystems.md)| Describes the best practices, location, values, policy management and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting. |
| [System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)](system-objects-strengthen-default-permissions-of-internal-system-objects.md)| Describes the best practices, location, values, policy management and security considerations for the **System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)** security policy setting. |
| [System settings: Optional subsystems](system-settings-optional-subsystems.md) | Describes the best practices, location, values, policy management and security considerations for the **System settings: Optional subsystems** security policy setting.|
| [System settings: Use certificate rules on Windows executables for Software Restriction Policies](system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md)| Describes the best practices, location, values, policy management and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting. |
| [User Account Control: Admin Approval Mode for the Built-in Administrator account](user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Admin Approval Mode for the Built-in Administrator account** security policy setting. |
| [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md)| Describes the best practices, location, values, and security considerations for the **User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop** security policy setting. |
| [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode** security policy setting. |
| [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Behavior of the elevation prompt for standard users** security policy setting. |
| [User Account Control: Detect application installations and prompt for elevation](user-account-control-detect-application-installations-and-prompt-for-elevation.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Detect application installations and prompt for elevation** security policy setting. |
| [User Account Control: Only elevate executables that are signed and validated](user-account-control-only-elevate-executables-that-are-signed-and-validated.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting. |
| [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting. |
| [User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Run all administrators in Admin Approval Mode** security policy setting. |
| [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Switch to the secure desktop when prompting for elevation** security policy setting. |
| [User Account Control: Virtualize file and registry write failures to per-user locations](user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md)| Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Virtualize file and registry write failures to per-user locations** security policy setting. |
 
## Related topics
[Security policy settings reference](security-policy-settings-reference.md)
[Security policy settings](security-policy-settings.md)
 
 
- [Security policy settings reference](security-policy-settings-reference.md)
- [Security policy settings](security-policy-settings.md)

51
windows/keep-secure/security-policy-settings-reference.md
View File

@ -2,53 +2,32 @@
title: Security policy settings reference (Windows 10)
description: This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.
ms.assetid: ef5a4579-15a8-4507-9a43-b7ccddcb0ed1
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security policy settings reference
**Applies to**
- Windows 10
This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.
This reference focuses on those settings that are considered security settings. This reference examines only the settings and features in the Windows operating systems that can help organizations secure their enterprises against malicious software threats. Management features and those security features that you cannot configure are not described in this reference.
Each policy setting described contains referential content such as a detailed explanation of the settings, best practices, default settings, differences between operating system versions, policy management considerations, and security considerations that include a discussion of vulnerability, countermeasures, and potential impact of those countermeasures.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Account Policies](account-policies.md)</p></td>
<td align="left"><p>An overview of account policies in Windows and provides links to policy descriptions.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Audit Policy](audit-policy.md)</p></td>
<td align="left"><p>Provides information about basic audit policies that are available in Windows and links to information about each setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Security Options](security-options.md)</p></td>
<td align="left"><p>Provides an introduction to the settings under <strong>Security Options</strong> of the local security policies and links to information about each setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Advanced security audit policy settings](secpol-advanced-security-audit-policy-settings.md)</p></td>
<td align="left"><p>Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Rights Assignment](user-rights-assignment.md)</p></td>
<td align="left"><p>Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows.</p></td>
</tr>
</tbody>
</table>
 
| Topic | Description |
| - | - |
| [Account Policies](account-policies.md) | An overview of account policies in Windows and provides links to policy descriptions.|
| [Audit Policy](audit-policy.md) | Provides information about basic audit policies that are available in Windows and links to information about each setting.|
| [Security Options](security-options.md) | Provides an introduction to the settings under **Security Options** of the local security policies and links to information about each setting.|
| [Advanced security audit policy settings](secpol-advanced-security-audit-policy-settings.md) | Provides information about the advanced security audit policy settings that are available in Windows and the audit events that they generate.|
| [User Rights Assignment](user-rights-assignment.md) | Provides an overview and links to information about the User Rights Assignment security policy settings user rights that are available in Windows.  |
 
 

218
windows/keep-secure/security-policy-settings.md
View File

@ -2,111 +2,191 @@
title: Security policy settings (Windows 10)
description: This reference topic describes the common scenarios, architecture, and processes for security settings.
ms.assetid: e7ac5204-7f6c-4708-a9f6-6af712ca43b9
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security policy settings
**Applies to**
- Windows 10
This reference topic describes the common scenarios, architecture, and processes for security settings.
Security policy settings are rules that administrators configure on a computer or multiple devices for the purpose of protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security settings for multiple devices from any device joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients, and other resources in your organization.
Security settings can control:
- User authentication to a network or device.
- The resources that users are permitted to access.
- Whether to record a user’s or group’s actions in the event log.
- Membership in a group.
To manage security configurations for multiple devices, you can use one of the following options:
- Edit specific security settings in a GPO.
- Use the Security Templates snap-in to create a security template that contains the security policies you want to apply, and then import the security template into a Group Policy Object. A security template is a file that represents a security configuration, and it can be imported to a GPO, applied to a local device, or used to analyze security.
For more info about managing security configurations, see [Administer security policy settings](administer-security-policy-settings.md).
The Security Settings extension of the Local Group Policy Editor includes the following types of security policies:
- **Account Policies.** These polices are defined on devices; they affect how user accounts can interact with the computer or domain. Account policies include the following types of policies:
- **Password Policy.** These policies determine settings for passwords, such as enforcement and lifetimes. Password policies are used for domain accounts.
- **Account Lockout Policy.** These policies determine the conditions and length of time that an account will be locked out of the system. Account lockout policies are used for domain or local user accounts.
- **Kerberos Policy.** These policies are used for domain user accounts; they determine Kerberos-related settings, such as ticket lifetimes and enforcement.
- **Local Policies.** These policies apply to a computer and include the following types of policy settings:
- **Audit Policy.** Specify security settings that control the logging of security events into the Security log on the computer, and specifies what types of security events to log (success, failure, or both).
**Note**  
For devices running Windows 7 and later, we recommend to use the settings under Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies.
>**Note:**  For devices running Windows 7 and later, we recommend to use the settings under Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies.
 
- **User Rights Assignment.** Specify the users or groups that have logon rights or privileges on a device
- **Security Options.** Specify security settings for the computer, such as Administrator and Guest Account names; access to floppy disk drives and CD-ROM drives; installation of drivers; logon prompts; and so on.
- **Windows Firewall with Advanced Security.** Specify settings to protect the device on your network by using a stateful firewall that allows you to determine which network traffic is permitted to pass between your device and the network.
- **Network List Manager Policies.** Specify settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices.
- **Public Key Policies.** Specify settings to control Encrypting File System, Data Protection, and BitLocker Drive Encryption in addition to certain certificate paths and services settings.
- **Software Restriction Policies.** Specify settings to identify software and to control its ability to run on your local device, organizational unit, domain, or site.
- **Application Control Policies.** Specify settings to control which users or groups can run particular applications in your organization based on unique identities of files.
- **IP Security Policies on Local Computer.** Specify settings to ensure private, secure communications over IP networks through the use of cryptographic security services. IPsec establishes trust and security from a source IP address to a destination IP address.
- **Advanced Audit Policy Configuration.** Specify settings that control the logging of security events into the security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over which activities to monitor as opposed to the Audit Policy settings under Local Policies.
- **Advanced Audit Policy Configuration.** Specify settings that control the logging of security events into the security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over which activities to monitor as opposed to the Audit Policy settings under
Local Policies.
## Policy-based security settings management
The Security Settings extension to Group Policy provides an integrated policy-based management infrastructure to help you manage and enforce your security policies.
You can define and apply security settings policies to users, groups, and network servers and clients through Group Policy and Active Directory Domain Services (AD DS). A group of servers with the same functionality can be created (for example, a Microsoft Web (IIS) server), and then Group Policy Objects can be used to apply common security settings to the group. If more servers are added to this group later, many of the common security settings are automatically applied, reducing deployment and administrative labor.
### Common scenarios for using security settings policies
Security settings policies are used to manage the following aspects of security: accounts policy, local policy, user rights assignment, registry values, file and registry Access Control Lists (ACLs), service startup modes, and more.
As part of your security strategy, you can create GPOs with security settings policies configured specifically for the various roles in your organization, such as domain controllers, file servers, member servers, clients, and so on.
You can create an organizational unit (OU) structure that groups devices according to their roles. Using OUs is the best method for separating specific security requirements for the different roles in your network. This approach also allows you to apply customized security templates to each class of server or computer. After creating the security templates, you create a new GPO for each of the OUs, and then import the security template (.inf file) into the new GPO.
Importing a security template to a GPO ensures that any accounts to which the GPO is applied automatically receive the template’s security settings when the Group Policy settings are refreshed. On a workstation or server, the security settings are refreshed at regular intervals (with a random offset of at most 30 minutes), and, on a domain controller, this process occurs every few minutes if changes have occurred in any of the GPO settings that apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred.
**Note**  
These refresh settings vary between versions of the operating system and can be configured.
Importing a security template to a GPO ensures that any accounts to which the GPO is applied automatically receive the template’s security settings when the Group Policy settings are refreshed. On a workstation or server, the security settings are refreshed at regular intervals (with a random
offset of at most 30 minutes), and, on a domain controller, this process occurs every few minutes if changes have occurred in any of the GPO settings that apply. The settings are also refreshed every 16 hours, whether or not any changes have occurred.
>**Note:**  These refresh settings vary between versions of the operating system and can be configured.
 
By using Group Policy−based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update a number of servers with any additional changes required in the future.
### Dependencies on other operating system technologies
For devices that are members of a Windows Server 2008 or later domain, security settings policies depend on the following technologies:
- **Active Directory Domain Services (AD DS)**
The Windows-based directory service, AD DS, stores information about objects on a network and makes this information available to administrators and users. By using AD DS, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single logon.
- **Group Policy**
The infrastructure within AD DS that enables directory-based configuration management of user and computer settings on devices running Windows Server. By using Group Policy, you can define configurations for groups of users and computers, including policy settings, registry-based policies, software installation, scripts, folder redirection, Remote Installation Services, Internet Explorer maintenance, and security.
- **Domain Name System (DNS)**
A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This allows users, computers, and applications to query DNS to specify remote systems by fully qualified domain names rather than by IP addresses.
- **Winlogon**
A part of the Windows operating system that provides interactive logon support. Winlogon is designed around an interactive logon model that consists of three components: the Winlogon executable, a credential provider, and any number of network providers.
- **Setup**
Security configuration interacts with the operating system setup process during a clean installation or upgrade from earlier versions of Windows Server.
- **Security Accounts Manager (SAM)**
A Windows service used during the logon process. SAM maintains user account information, including groups to which a user belongs.
- **Local Security Authority (LSA)**
A protected subsystem that authenticates and logs users onto the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system.
- **Windows Management Instrumentation (WMI)**
A feature of the Microsoft Windows operating system, WMI is the Microsoft implementation of Web-Based Enterprise Management (WBEM), which is an industry initiative to develop a standard technology for accessing management information in an enterprise environment. WMI provides access to information about objects in a managed environment. Through WMI and the WMI application programming interface (API), applications can query for and make changes to static information in the Common Information Model (CIM) repository and dynamic information maintained by the various types of providers.
- **Resultant Set of Policy (RSoP)**
An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. This allows administrators to easily determine the combination of policy settings that apply to, or will apply to, a user or device.
- **Service Control Manager (SCM)**
Used for configuration of service startup modes and security.
- **Registry**
Used for configuration of registry values and security.
- **File system**
Used for configuration of security.
- **File system conversions**
Security is set when an administrator converts a file system from FAT to NTFS.
- **Microsoft Management Console (MMC)**
The user interface for the Security Settings tool is an extension of the Local Group Policy Editor MMC snap-in.
### Security settings policies and Group Policy
The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tool set. The following components are associated with Security Settings: a configuration engine; an analysis engine; a template and database interface layer; setup integration logic; and the secedit.exe command-line tool. The security configuration engine is responsible for handling security configuration editor-related security requests for the system on which it runs. The analysis engine analyzes system security for a given configuration and saves the result. The template and database interface layer handles reading and writing requests from and to the template or database (for internal storage). The Security Settings extension of the Local Group Policy Editor handles Group Policy from a domain-based or local device. The security configuration logic integrates with setup and manages system security for a clean installation or upgrade to a more recent Windows operating system. Security information is stored in templates (.inf files) or in the Secedit.sdb database.
The following diagram shows Security Settings and related features.
**Security Settings Policies and Related Features**
![components related to security policies](images/secpol-components.gif)
- **Scesrv.dll**
Provides the core security engine functionality.
- **Scecli.dll**
Provides the client-side interfaces to the security configuration engine and provides data to Resultant Set of Policy (RSoP).
- **Wsecedit.dll**
The Security Settings extension of Local Group Policy Editor. scecli.dll is loaded into wsecedit.dll to support the Security Settings user interface.
- **Gpedit.dll**
The Local Group Policy Editor MMC snap-in.
## <a href="" id="w2k3tr-gpssp-how-ebls"></a>Security Settings extension architecture
The Security Settings extension of the Local Group Policy Editor is part of the Security Configuration Manager tools, as shown in the following diagram.
**Security Settings Architecture**
![architecture of security policy settings](images/secpol-architecture.gif)
The security settings configuration and analysis tools include a security configuration engine, which provides local computer (non-domain member) and Group Policy−based configuration and analysis of security settings policies. The security configuration engine also supports the creation of security policy files. The primary features of the security configuration engine are scecli.dll and scesrv.dll.
The following list describes these primary features of the security configuration engine and other Security Settings−related features.
- **scesrv.dll**
This .dll is hosted in services.exe and runs under local system context. scesrv.dll provides core Security Configuration Manager functionality, such as import, configure, analyze, and policy propagation.
Scesrv.dll performs configuration and analysis of various security-related system parameters by calling corresponding system APIs, including LSA, SAM, and the registry.
Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over LRPC (Windows XP) and fails the call if it is not.
Communication between parts of the Security Settings extension occurs by using the following methods:
- Component Object Model (COM) calls
- Local Remote Procedure Call (LRPC)
- Lightweight Directory Access Protocol (LDAP)
@ -114,146 +194,204 @@ The following list describes these primary features of the security configuratio
- Server Message Block (SMB)
- Win32 APIs
- Windows Management Instrumentation (WMI) calls
On domain controllers, scesrv.dll receives notifications of changes made to SAM and the LSA that need to be synchronized across domain controllers. Scesrv.dll incorporates those changes into the Default Domain Controller Policy GPO by using in-process scecli.dll template modification APIs.
Scesrv.dll also performs configuration and analysis operations.
- **Scecli.dll**
This is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC snap-ins. It is used by Setup to configure default system security and security of files, registry keys, and services installed by the Setup API .inf files.
The command-line version of the security configuration and analysis user interfaces, secedit.exe, uses scecli.dll.
Scecli.dll implements the client-side extension for Group Policy.
Scesrv.dll uses scecli.dll to download applicable Group Policy files from SYSVOL in order to apply Group Policy security settings to the local device.
Scecli.dll logs application of security policy into WMI (RSoP).
Scesrv.dll policy filter uses scecli.dll to update Default Domain Controller Policy GPO when changes are made to SAM and LSA.
- **Wsecedit.dll**
The Security Settings extension of the Group Policy Object Editor snap-in. You use this tool to configure security settings in a Group Policy Object for a site, domain, or organizational unit. You can also use Security Settings to import security templates to a GPO.
- **Secedit.sdb**
This is a permanent system database used for policy propagation including a table of persistent settings for rollback purposes.
- **User databases**
A user database is any database other than the system database created by administrators for the purposes of configuration or analysis of security.
- **.Inf Templates**
These are text files that contain declarative security settings. They are loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they are downloaded (by using file copy) and merged into the system database during policy propagation.
These are text files that contain declarative security settings. They are loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they are downloaded (by using file copy) and merged into
the system database during policy propagation.
## <a href="" id="w2k3tr-gpssp-how-hjxe"></a>Security settings policy processes and interactions
For a domain-joined device, where Group Policy is administered, security settings are processed in conjunction with Group Policy. Not all settings are configurable.
### <a href="" id="bkmk-gpprocessing"></a>Group Policy processing
When a computer starts and a user logs on, computer policy and user policy are applied according to the following sequence:
1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start.
2. An ordered list of Group Policy Objects is obtained for the device. The list might depend on these factors:
- Whether the device is part of a domain and, therefore, subject to Group Policy through Active Directory.
- The location of the device in Active Directory.
- Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
3. Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is a synchronous process by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.
4. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
5. The user presses CTRL+ALT+DEL to log on.
6. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.
7. An ordered list of Group Policy Objects is obtained for the user. The list might depend on these factors:
- Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory.
- Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting.
- The location of the user in Active Directory.
- Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
8. User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.
9. Logon scripts run. Group Policy−based logon scripts are hidden and asynchronous by default. The user object script runs last.
10. The operating system user interface that is prescribed by Group Policy appears.
### Group Policy Objects storage
A Group Policy Object (GPO) is a virtual object that is identified by a Globally Unique Identifier (GUID) and stored at the domain level. The policy setting information of a GPO is stored in the following two locations:
- **Group Policy containers in Active Directory.**
The Group Policy container is an Active Directory container that contains GPO properties, such as version information, GPO status, plus a list of other component settings.
- **Group Policy templates in a domain’s system volume folder (SYSVOL).**
The Group Policy template is a file system folder that includes policy data specified by .admx files, security settings, script files, and information about applications that are available for installation. The Group Policy template is located in the SYSVOL folder in the domain\\Policies subfolder.
The **GROUP\_POLICY\_OBJECT** structure provides information about a GPO in a GPO list, including the version number of the GPO, a pointer to a string that indicates the Active Directory portion of the GPO, and a pointer to a string that specifies the path to the file system portion of the GPO.
### Group Policy processing order
Group Policy settings are processed in the following order:
1. **Local Group Policy Object.**
Each device running a Windows operating system beginning with Windows XP has exactly one Group Policy Object that is stored locally.
2. **Site.**
Any Group Policy Objects that have been linked to the site are processed next. Processing is synchronous and in an order that you specify.
3. **Domain.**
Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you speciy.
4. **Organizational units.**
Group Policy Objects that are linked to the organizational unit that is highest in the Active Directory hierarchy are processed first, then Group Policy Objects that are linked to its child organizational unit, and so on. Finally, the Group Policy Objects that are linked to the organizational unit that contains the user or device are processed.
At the level of each organizational unit in the Active Directory hierarchy, one, many, or no Group Policy Objects can be linked. If several Group Policy Objects are linked to an organizational unit, their processing is synchronous and in an order that you specify.
This order means that the local Group Policy Object is processed first, and Group Policy Objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy Objects.
This is the default processing order and administrators can specify exceptions to this order. A Group Policy Object that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to **Enforced** with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as **Block Inheritance**. Group Policy Object links that are set to **Enforced** are always applied, however, and they cannot be blocked.
### <a href="" id="bkmk-secpolprocessing"></a>Security settings policy processing
In the context of Group Policy processing, security settings policy is processed in the following order.
1. During Group Policy processing, the Group Policy engine determines which security settings policies to apply.
2. If security settings policies exist in a GPO, Group Policy invokes the Security Settings client-side extension.
3. The Security Settings extension downloads the policy from the appropriate location such as a specific domain controller.
4. The Security Settings extension merges all security settings policies according to precedence rules. The processing is according to the Group Policy processing order of local, site, domain, and organizational unit (OU), as described earlier in the “Group Policy processing order” section. If multiple GPOs are in effect for a given device and there are no conflicting policies, then the policies are cumulative and are merged.
This example uses the Active Directory structure shown in the following figure. A given computer is a member of OU2, to which the **GroupMembershipPolGPO** GPO is linked. This computer is also subject to the **UserRightsPolGPO** GPO, which is linked to OU1, higher in the hierarchy. In this case, no conflicting policies exist so the device receives all of the policies contained in both the **UserRightsPolGPO** and the **GroupMembershipPolGPO** GPOs.
**Multiple GPOs and Merging of Security Policy**
![multiple gpos and merging of security policy](images/secpol-multigpomerge.gif)
5. The resultant security policies are stored in secedit.sdb, the security settings database. The security engine gets the security template files and imports them to secedit.sdb.
6. The security settings policies are applied to devices.
The following figure illustrates the security settings policy processing.
**Security Settings Policy Processing**
![process and interactions of security policy settin](images/secpol-processes.gif)
### Merging of security policies on domain controllers
Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:
- Network Security: Force logoff when logon hours expire
- Accounts: Administrator account status
- Accounts: Guest account status
- Accounts: Rename administrator account
- Accounts: Rename guest account
Another mechanism exists that allows security policy changes made by administrators by using net accounts to be merged into the Default Domain Policy GPO. User rights changes that are made by using Local Security Authority (LSA) APIs are filtered into the Default Domain Controllers Policy GPO.
### Special considerations for domain controllers
If an application is installed on a primary domain controller (PDC) with operations master role (also known as flexible single master operations or FSMO) and the application makes changes to user rights or password policy, these changes must be communicated to ensure that synchronization across domain controllers occurs. Scesrv.dll receives a notification of any changes made to the security account manager (SAM) and LSA that need to be synchronized across domain controllers and then incorporates the changes into the Default Domain Controller Policy GPO by using scecli.dll template modification APIs.
### When security settings are applied
After you have edited the security settings policies, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object in the following instances:
- When a device is restarted.
- Every 90 minutes on a workstation or server and every 5 minutes on a domain controller. This refresh interval is configurable.
- By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO has not changed.
### Persistence of security settings policy
Security settings can persist even if a setting is no longer defined in the policy that originally applied it.
Security settings might persist in the following cases:
- The setting has not been previously defined for the device.
- The setting is for a registry security object.
- The settings are for a file system security object.
All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is. This behavior is sometimes referred to as “tattooing.”
All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is.
This behavior is sometimes referred to as “tattooing.”
Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values.
### Permissions required for policy to apply
Both Apply Group Policy and Read permissions are required to have the settings from a Group Policy Object apply to users or groups, and computers.
### Filtering security policy
By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or will not have a Group Policy Object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.
**Note**  
Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.
**Note:**  Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.
 
### Migration of GPOs containing security settings
In some situations, you might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings.
Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as taking a folder and copying it from one device to another.
The following security policies can contain security principals and might require some additional work to successfully move them from one domain to another.
- User rights assignment
- Restricted groups
- Services
- File system
- Registry
- The GPO DACL, if you choose to preserve it during a copy operation
To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When migrating a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[Administer security policy settings](administer-security-policy-settings.md)</p></td>
<td align="left"><p>This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Configure security policy settings](how-to-configure-security-policy-settings.md)</p></td>
<td align="left"><p>Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Security policy settings reference](security-policy-settings-reference.md)</p></td>
<td align="left"><p>This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.</p></td>
</tr>
</tbody>
</table>
 
 
 
| Topic | Description |
| - | - |
| [Administer security policy settings](administer-security-policy-settings.md) | This article discusses different methods to administer security policy settings on a local device or throughout a small- or medium-sized organization.|
| [Configure security policy settings](how-to-configure-security-policy-settings.md) | Describes steps to configure a security policy setting on the local device, on a domain-joined device, and on a domain controller.|
| [Security policy settings reference](security-policy-settings-reference.md) | This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.|

55
windows/keep-secure/security-technologies.md
View File

@ -2,64 +2,14 @@
title: Security technologies (Windows 10)
description: Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
ms.assetid: BFE2DE22-B0CE-465B-8CF6-28F64464DF08
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Security technologies
<<<<<<< HEAD
Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
## In this section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Topic</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>[AppLocker](applocker-overview.md)</p></td>
<td align="left"><p>This topic provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[BitLocker](bitlocker-overview.md)</p></td>
<td align="left"><p>This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Encrypted Hard Drive](encrypted-hard-drive.md)</p></td>
<td align="left"><p>Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Security auditing](security-auditing-overview.md)</p></td>
<td align="left"><p>Topics in this section are for IT professionals and describes the security auditing features in Windows and how your organization can benefit from using these technologies to enhance the security and manageability of your network.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Security policy settings](security-policy-settings.md)</p></td>
<td align="left"><p>This reference topic describes the common scenarios, architecture, and processes for security settings.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Trusted Platform Module](trusted-platform-module-overview.md)</p></td>
<td align="left"><p>This topic for the IT professional describes the Trusted Platform Module (TPM) and how Windows uses it for access control and authentication. The topic provides links to other resources about the TPM.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[User Account Control](user-account-control-overview.md)</p></td>
<td align="left"><p>User Account Control (UAC) helps prevent malware from damaging a PC and helps organizations deploy a better-managed desktop. With UAC, apps and tasks always run in the security context of a non-administrator account, unless an administrator specifically authorizes administrator-level access to the system. UAC can block the automatic installation of unauthorized apps and prevent inadvertent changes to system settings.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Windows Defender in Windows 10](windows-defender-in-windows-10.md)</p></td>
<td align="left"><p>This topic provides an overview of Windows Defender, including a list of system requirements and new features.</p></td>
</tr>
</tbody>
</table>
 
=======
Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile.
@ -75,6 +25,5 @@ Learn more about the different security technologies that are available in Windo
| [Windows Defender Advanced Threat Protection](windows-defender-advanced-threat-protection.md)| Windows Defender Advanced Threat Protection (Windows Defender ATP) is an out-of-the-box Windows enterprise security service that enables enterprise cybersecurity teams to detect and respond to advanced threats on their networks.|
| [Windows Defender in Windows 10](windows-defender-in-windows-10.md)| This topic provides an overview of Windows Defender, including a list of system requirements and new features.|
>>>>>>> master
 
 

62
windows/keep-secure/select-types-of-rules-to-create.md
View File

@ -2,77 +2,71 @@
title: Select the types of rules to create (Windows 10)
description: This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
ms.assetid: 14751169-0ed1-47cc-822c-8c01a7477784
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Select the types of rules to create
**Applies to**
- Windows 10
This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
When determining what types of rules to create for each of your groups, you should also determine what enforcement setting to use for each group. Different rule types are more applicable for some apps, depending on the way that the applications are deployed in a specific business group.
The following topics provide additional information about AppLocker rules that can help you decide what rules to use for your applications:
- [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 AppLocker default rules](understanding-applocker-default-rules.md)
### Select the rule collection
The rules you create will be in one of the following rule collections:
- Executable files: .exe and .com
- Windows Installer files: .msi, .msp, and .mst
- Scripts: .ps1, .bat, .cmd, .vbs, and .js
- Packaged apps and packaged app installers: .appx
- DLLs: .dll and .ocx
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\\Program Files\\Woodgrove\\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a list of allowed applications, all the Windows files under C:\\Windows must be included as well.
### Determine the rule condition
A rule condition is criteria upon which an AppLocker rule is based and can only be one of the rule conditions in the following table.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Rule condition</th>
<th align="left">Usage scenario</th>
<th align="left">Resources</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Publisher</p></td>
<td align="left"><p>To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by using an internal certificate. Rules that are specified to the version level might have to be updated when a new version of the file is released.</p></td>
<td align="left"><p>For more info about this rule condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).</p></td>
</tr>
<tr class="even">
<td align="left"><p>Path</p></td>
<td align="left"><p>Any file can be assigned this rule condition; however, because path rules specify locations within the file system, any subdirectory will also be affected by the rule (unless explicitly exempted).</p></td>
<td align="left"><p>For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md).</p></td>
</tr>
<tr class="odd">
<td align="left"><p>File hash</p></td>
<td align="left"><p>Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file is released because the hash value is based in part upon the version.</p></td>
<td align="left"><p>For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md).</p></td>
</tr>
</tbody>
</table>
| Rule condition | Usage scenario | Resources |
| - | - | - |
| Publisher | To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by using an internal certificate. Rules that are specified to the version level might have to be updated when a new version of the file is released.|For more info about this rule condition, see [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md).
| Path| Any file can be assigned this rule condition; however, because path rules specify locations within the file system, any subdirectory will also be affected by the rule (unless explicitly exempted).| For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md). |
| File hash | Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file is released because the hash value is based in part upon the version.| For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md). |
 
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
### Determine how to allow system files to run
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule collection.
You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This will permit access to these files whenever updates are applied and the files change. If you require additional application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
- Traverse Folder/Execute File
- Create Files/Write Data
- Create Folders/Append Data
These permissions settings are applied to this folder for application compatibility. However, because any user can create files in this location, allowing apps to be run from this location might conflict with your organization's security policy.
## Next steps
After you have selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the rules. For info about how to do this, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
 
 

100
windows/keep-secure/shut-down-the-system.md
View File

@ -2,105 +2,101 @@
title: Shut down the system (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Shut down the system security policy setting.
ms.assetid: c8e8f890-153a-401e-a957-ba6a130304bf
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Shut down the system
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Shut down the system** security policy setting.
## Reference
This security setting determines if a user who is logged on locally to a device can shut down Windows.
Shutting down domain controllers makes them unavailable to perform functions such as processing logon requests, processing Group Policy settings, and answering Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles (also known as flexible single master operations or FSMO roles) can disable key domain functionality; for example, processing logon requests for new passwords, which is performed by the primary domain controller (PDC) emulator master.
The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancela shutdown.
Constant: SeShutdownPrivilege
### Possible values
- A user-defined list of accounts
- Defaults
- Not defined
### Best practices
1. Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers, and that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks will not be negatively affected.
2. The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Administrators, Backup Operators, Server Operators, and Print Operators on domain controllers, and Administrators and Backup Operators 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>Backup Operators</p>
<p>Server Operators</p>
<p>Print Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Server Operators</p>
<p>Print Operators</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p>
<p>Backup Operators</p>
<p>Users</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not defined|
| Default Domain Controller Policy | Administrators<br/>Backup Operators<br/>Server Operators<br/>Print Operators|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators|
| Domain Controller Effective Default Settings | Administrators<br/>Backup Operators<br/>Server Operators<br/>Print Operators|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators|
| Client Computer Effective Default Settings | Administrators<br/>Backup Operators<br/>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
This user right does not have the same effect as **Force shutdown from a remote system**. For more information, see [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md).
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
The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Although the **Shut down the system** user right requires the ability to log on to the server, you should be very careful about which accounts and groups you allow to shut down a domain controller.
When a domain controller is shut down, it is no longer available to process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that possess operations master roles, you can disable key domain functionality, such as processing logon requests for new passwords, which is performed by the PDC master.
For other server roles, especially those where non-administrators have rights to log on to the server (such as RD Session Host servers), it is critical that this user right be removed from users that do not have a legitimate reason to restart the servers.
### Countermeasure
Ensure that only the Administrators and Backup Operators groups are assigned the **Shut down the system** user right on member servers, and ensure that only the Administrators group is assigned the user right on domain controllers.
### Potential impact
The impact of removing these default groups from the **Shut down the system** user right could limit the delegated abilities of assigned 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)

89
windows/keep-secure/shutdown-allow-system-to-be-shut-down-without-having-to-log-on.md
View File

@ -2,87 +2,90 @@
title: Shutdown Allow system to be shut down without having to log on (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Shutdown Allow system to be shut down without having to log on security policy setting.
ms.assetid: f3964767-5377-4416-8eb3-e14d553a7315
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Shutdown: Allow system to be shut down without having to log on
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Allow system to be shut down without having to log on** security policy setting.
## Reference
This policy setting determines whether a device can be shut down without having to log on to Windows. If you enable this policy setting, the **Shut Down** option is available on the logon screen in Windows. If you disable this policy setting, the **Shut Down** option is removed from the logon screen. This configuration requires that users are able to log on to the device successfully and that they have the **Shut down the system** user right before they can perform a shutdown.
Users who can access the console locally can shut down the system. Attackers or misguided users can connect to the server by using Remote Desktop Services, and then shut it down or restart it without having to identify themselves. A malicious user might also cause a temporary denial-of-service condition by walking up to the local console and restarting the server, or shutting down the server and thus rendering unavailable all its applications and services.
Users who can access the console locally can shut down the system. Attackers or misguided users can connect to the server by using Remote Desktop Services, and then shut it down or restart it without having to identify themselves. A malicious user might also cause a temporary denial-of-service
condition by walking up to the local console and restarting the server, or shutting down the server and thus rendering unavailable all its applications and services.
### Possible values
- Enabled
The shut down command is available on the logon screen.
- Disabled
The shut down option is removed from the logon screen and users must have the **Shut down the system** user right before they can perform a shutdown.
- Not defined
### Best practices
1. On servers, set this policy to **Disabled**. You must log on to servers to shut them down or restart them.
2. On client devices, set this policy to **Enabled** and define the list of those with the right to shut them down or restart them with the User Rights Assignment policy **Shut down the system**.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</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 | Disabled|
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Enabled|
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
### Group Policy
For info about the User Rights Assignment policy, **Shut down the system**, see [Shut down the system](shut-down-the-system.md).
## 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
Users who can access the console locally could shut down the device
Attackers who have access to the local console could restart the server, which would cause a temporary DoS condition. Attackers could also shut down the server and leave all of its applications and services unavailable.
### Countermeasure
Disable the **Shutdown: Allow system to be shut down without having to log on** setting.
### Potential impact
You must log on to servers to shut them down or restart them.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

85
windows/keep-secure/shutdown-clear-virtual-memory-pagefile.md
View File

@ -2,85 +2,82 @@
title: Shutdown Clear virtual memory pagefile (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Shutdown Clear virtual memory pagefile security policy setting.
ms.assetid: 31400078-6c56-4891-a6df-6dfb403c4bc9
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Shutdown: Clear virtual memory pagefile
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Shutdown: Clear virtual memory pagefile** security policy setting.
## Reference
This policy setting determines whether the virtual memory paging file is cleared when the device is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a running device, this paging file is opened exclusively by the operating system, and it is well protected. However, devices that are configured to allow other operating systems to start should verify that the system paging file is cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file is not available to an unauthorized user who manages to directly access the paging file after shutdown.
Important information that is kept in real memory might be written periodically to the paging file. This helps devices handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This is a time-consuming process, but it can expose data that is cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by simply unplugging the server from its power source.
### Possible values
- Enabled
The system paging file is cleared when the system shuts down normally. Also, this policy setting forces the computer to clear the hibernation file (hiberfil.sys) when hibernation is disabled on a portable device.
- Disabled
- Not defined
### Best practices
- Set this policy to **Enabled**. This causes Windows to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Disabled|
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
## Policy management
This section describes features and tools that are available to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a computer 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
Important information that is kept in real memory may be written periodically to the paging file to help Windows handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the paging file. The attacker could move the system volume into a different device and then analyze the contents of the paging file. Although this process is time consuming, it could expose data that is cached from random access memory (RAM) to the paging file.
**Caution**  
An attacker who has physical access to the device could bypass this countermeasure by unplugging the computer from its power source.
>**Caution:**  An attacker who has physical access to the device could bypass this countermeasure by unplugging the computer from its power source.
 
### Countermeasure
Enable the **Shutdown: Clear virtual memory page file** setting. This configuration causes the operating system to clear the paging file when the device is shut down. The amount of time that is required to complete this process depends on the size of the page file. Because the process overwrites the storage area that is used by the page file several times, it could be several minutes before the device completely shuts down.
### Potential impact
It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more than 30 minutes. For some organizations this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

81
windows/keep-secure/store-passwords-using-reversible-encryption.md
View File

@ -2,80 +2,71 @@
title: Store passwords using reversible encryption (Windows 10)
description: Describes the best practices, location, values, and security considerations for the Store passwords using reversible encryption security policy setting.
ms.assetid: 57f958c2-f1e9-48bf-871b-0a9b3299e238
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Store passwords using reversible encryption
**Applies to**
- Windows 10
Describes the best practices, location, values, and security considerations for the **Store passwords using reversible encryption** security policy setting.
## Reference
The **Store password using reversible encryption** policy setting provides support for applications that use protocols that require the user's password for authentication. Storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then log on to network resources by using the compromised account. For this reason, never enable **Store password using reversible encryption** for all users in the domain unless application requirements outweigh the need to protect password information.
If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used by remote access and network connections. Digest Authentication in Internet Information Services (IIS) also requires that you enable this policy setting.
If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used by remote access and network connections. Digest Authentication in Internet
Information Services (IIS) also requires that you enable this policy setting.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
Set the value for **Store password using reversible encryption** to Disabled. If you use CHAP through remote access or IAS, or Digest Authentication in IIS, you must set this value to **Enabled**. This presents a security risk when you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate user account object in Active Directory Users and Computers.
**Note**  
Do not enable this policy setting unless business requirements outweigh the need to protect password information.
>**Note:**  Do not enable this policy setting unless business requirements outweigh the need to protect password information.
 
### 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 Group Policy Object (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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default domain controller policy</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-alone server default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| Disabled|
| Default domain controller policy| Disabled|
| Stand-alone server default settings | Disabled|
| Domain controller effective default settings | Disabled|
| Member server effective default settings | Disabled|
| Effective GPO default settings on client computers | Disabled|
 
## 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
Enabling this policy setting allows the operating system to store passwords in a format that can weaken your overall security.
### Countermeasure
Disable the **Store password using reversible encryption** policy setting.
### Potential impact
If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure this policy setting to Enabled. This presents a security risk when you apply the setting through Group Policy on a user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
## Related topics
[Password Policy](password-policy.md)
 
 
- [Password Policy](password-policy.md)

1
windows/keep-secure/switch-pcr-banks-on-tpm-2-0-devices.md
View File

@ -10,6 +10,7 @@ author: brianlic-msft
---
# Switch PCR banks on TPM 2.0 devices
**Applies to**
- Windows 10

85
windows/keep-secure/synchronize-directory-service-data.md
View File

@ -2,88 +2,89 @@
title: Synchronize directory service data (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Synchronize directory service data security policy setting.
ms.assetid: 97b0aaa4-674f-40f4-8974-b4bfb12c232c
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Synchronize directory service data
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Synchronize directory service data** security policy setting.
## Reference
This policy setting determines which users and groups have authority to synchronize all directory service data, regardless of the protection for objects and properties. This privilege is required to use LDAP directory synchronization (dirsync) services. Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers.
Constant: SeSyncAgentPrivilege
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
- Ensure that no accounts are assigned the **Synchronize directory service data** user right. Only domain controllers need this privilege, which they inherently have.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is not defined 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>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>Enabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Enabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
## 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.
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
The **Synchronize directory service data** user right affects domain controllers (only domain controllers should be able to synchronize directory service data). Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. Attackers who have this user right can view all information that is stored within the directory. They could then use some of that information to facilitate additional attacks or expose sensitive data, such as direct telephone numbers or physical addresses.
### Countermeasure
Ensure that no accounts are assigned the **Synchronize directory service data** user right.
### 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)

80
windows/keep-secure/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
View File

@ -2,82 +2,78 @@
title: System cryptography Force strong key protection for user keys stored on the computer (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System cryptography Force strong key protection for user keys stored on the computer security policy setting.
ms.assetid: 8cbff267-881e-4bf6-920d-b583a5ff7de0
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System cryptography: Force strong key protection for user keys stored on the computer
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **System cryptography: Force strong key protection for user keys stored on the computer** security policy setting.
## Reference
This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password.
Configuring this policy setting so that users must provide a password every time they use a key (in addition to their domain password) makes it more difficult for a malicious user to access locally-stored user keys, even if the attacker takes control of the user's device and determines their logon password.
### Possible values
- **User input is not required when new keys are stored and used**
- **User is prompted when the key is first used**
- **User must enter a password each time they use a key**
- Not defined
### Best practices
- Set this policy to **User must enter a password each time they use a key**. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they will be forced to enter the password for that certificate every time they send a signed email message. For some organizations, the overhead that is caused by using this value might be too high, but they should set the value at a minimum to **User is prompted when the key is first used**.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>DC Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not defined</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|
| DC Effective Default Settings | Not defined|
| Member Server Effective Default Settings | Not defined|
| Client Computer Effective Default Settings| Not defined|
 
## Policy management
This section describes features and tools that are available 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
If a user's account is compromised or the user's device is inadvertently left unsecured, the malicious user can use the keys that are stored for the user to access protected resources.
### Countermeasure
Configure the **System cryptography: Force strong key protection for user keys stored on the computer** setting to **User must enter a password each time they use a key** so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the logon password.
### Potential impact
Users must type their password every time they access a key that is stored on their device. For example, if users use an S/MIME certificate to digitally sign their email, they are forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this setting should be set to **User is prompted when the key is first used**.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

137
windows/keep-secure/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
View File

@ -2,125 +2,112 @@
title: System cryptography Use FIPS compliant algorithms for encryption, hashing, and signing (Windows 10)
description: This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.
ms.assetid: 83988865-dc0f-45eb-90d1-ee33495eb045
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing
**Applies to**
- Windows 10
This security policy reference topic for the IT professional describes the best practices, location, values, policy management and security considerations for this policy setting.
## Reference
The Federal Information Processing Standard (FIPS) 140 is a security implementation that is designed for certifying cryptographic software. Windows implements these certified algorithms to meet the requirements and standards for cryptographic modules for use by departments and agencies of the United States federal government.
The Federal Information Processing Standard (FIPS) 140 is a security implementation that is designed for certifying cryptographic software. Windows implements these certified algorithms to meet the requirements and standards for cryptographic modules for use by departments and agencies of the
United States federal government.
**TLS/SSL**
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
This policy setting determines whether the TLS/SSL security provider supports only the FIPS-compliant strong cipher suite known as TLS\_RSA\_WITH\_3DES\_EDE\_CBC\_SHA, which means that the provider only supports the TLS protocol as a client computer and as a server, if applicable. It uses only the
Triple Data Encryption Standard (3DES) encryption algorithm for the TLS traffic encryption, only the Rivest-Shamir-Adleman (RSA) public key algorithm for the TLS key exchange and authentication, and only the Secure Hash Algorithm version 1 (SHA-1) hashing algorithm for the TLS hashing requirements.
**Encrypting File System (EFS)**
For the EFS service, this policy setting supports the 3DES and Advanced Encryption Standard (AES) encryption algorithms for encrypting file data supported by the NTFS file system. To encrypt file data, by default EFS uses the Advanced Encryption Standard (AES) algorithm with a 256-bit key in the Windows Server 2003, Windows Vista, and later, and it uses a DESX algorithm in Windows XP.
**Remote Desktop Services (RDS)**
For encrypting Remote Desktop Services network communication, this policy setting supports only the Triple DES encryption algorithm.
**BitLocker**
For BitLocker, this policy setting needs to be enabled before any encryption key is generated.
Recovery passwords created on Windows Server 2012 R2 and Windows 8.1 and later when this policy is enabled are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and Windows 8.1; BitLocker will prevent the creation or use of recovery passwords on these systems, so recovery keys should be used instead.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
- For use with TLS, set this policy to **Enabled**. Client devices with this policy setting enabled will be unable to communicate through digitally encrypted or signed protocols with servers that do not support these algorithms. Client devices that are connected to the network and do not support these algorithms cannot use servers that require the algorithms for network communications. If you enable this policy setting, you must also configure Internet Explorer to use TLS.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Disabled|
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
### Operating system version differences
When this setting is enabled, the Encrypting File System (EFS) service supports only the Triple DES encryption algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX.
When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to versions listed in the following:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Operating systems</th>
<th align="left">Applicability</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Windows 10, Windows 8.1, and Windows Server 2012 R2</p></td>
<td align="left"><p>When created on these operating systems, the recovery password cannot be used on other systems listed in this table.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2012 and Windows 8</p></td>
<td align="left"><p>When created on these operating systems, the recovery key can be used on other systems listed in this table as well.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Windows Server 2008 R2 and Windows 7</p></td>
<td align="left"><p>When created on these operating systems, the recovery key can be used on other systems listed in this table as well.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Server 2008 and Windows Vista</p></td>
<td align="left"><p>When created on these operating systems, the recovery key can be used on other systems listed in this table as well.</p></td>
</tr>
</tbody>
</table>
| Operating systems | Applicability |
| - | - |
| Windows 10, Windows 8.1, and Windows Server 2012 R2| When created on these operating systems, the recovery password cannot be used on other systems listed in this table.|
| Windows Server 2012 and Windows 8 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
| Windows Server 2008 R2 and Windows 7 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
| Windows Server 2008 and Windows Vista | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
 
## Policy management
This section describes features and tools that are available 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.
### Group Policy
Setting and deploying this policy using Group Policy takes precedence over the setting on the local device. If the Group Policy is set to **Not Configured**, local settings will apply.
## 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
You can enable this policy setting to ensure that the device uses the most powerful algorithms that are available for digital encryption, hashing, and signing. Use of these algorithms minimize the risk of compromise of digitally encrypted or signed data by an unauthorized user.
### Countermeasure
Enable the **System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing** setting.
### Potential impact
Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require them for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices are not configured to use the same encryption algorithms.
Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require them for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool
uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices are not configured to use the same encryption algorithms.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

84
windows/keep-secure/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
View File

@ -2,83 +2,83 @@
title: System objects Require case insensitivity for non-Windows subsystems (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System objects Require case insensitivity for non-Windows subsystems security policy setting.
ms.assetid: 340d6769-8f33-4067-8470-1458978d1522
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System objects: Require case insensitivity for non-Windows subsystems
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting.
## Reference
This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem is not case sensitive; however, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting does not allow the Win32 subsystem to become case sensitive.
Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting is not enforced, it is possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available.
### Possible values
- Enabled
Case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects.
- Disabled
Will not allow the Win32 subsystem to become case sensitive.
- Not defined
### Best practices
- Set this policy to **Enabled**. All subsystems will be forced to observe case insensitivity. However, this might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive operating system.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Enabled</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>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</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 | Enabled|
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Enabled|
| Client Computer Effective Default Settings | Enabled|
 
## Policy management
This section describes features and tools that are available 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
Because Windows is case insensitive but the POSIX subsystem supports case sensitivity, failure to enable this policy setting makes it possible for a user of that subsystem to create a file with the same name as another file but with a different mix of uppercase and lowercase letters. Such a situation could potentially confuse users when they try to access such files from normal Win32 tools because only one of the files is available.
### Countermeasure
Enable the **System objects: Require case insensitivity for non-Windows subsystems** setting.
### Potential impact
All subsystems are forced to observe case insensitivity. This configuration may confuse users who are familiar with any UNIX-based operating systems that are case sensitive.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

79
windows/keep-secure/system-objects-strengthen-default-permissions-of-internal-system-objects.md
View File

@ -2,80 +2,75 @@
title: System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links) security policy setting.
ms.assetid: 3a592097-9cf5-4fd0-a504-7cbfab050bb6
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)** security policy setting.
## Reference
This policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. By using this list, processes can locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who are not administrators to read, but not to modify, shared objects that they did not create.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
- It is advisable to set this policy to **Enabled**.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\ Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Enabled</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>Enabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Enabled</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 | Enabled |
| DC Effective Default Settings | Enabled|
| Member Server Effective Default Settings| Enabled|
| Client Computer Effective Default Settings | Enabled|
 
## Policy management
This section describes features and tools that are available 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
This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this setting is disabled, it is possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten. Enabling **System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)** prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they did not create.
### Countermeasure
Enable the **System objects: Strengthen default permissions of global system objects (for example, Symbolic Links)** setting.
### Potential impact
None. This is the default configuration.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

81
windows/keep-secure/system-settings-optional-subsystems.md
View File

@ -2,81 +2,78 @@
title: System settings Optional subsystems (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System settings Optional subsystems security policy setting.
ms.assetid: 5cb6519a-4f84-4b45-8072-e2aa8a72fb78
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System settings: Optional subsystems
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **System settings: Optional subsystems** security policy setting.
## Reference
This policy setting determines which subsystems support your applications. You can use this security setting to specify as many subsystems as your environment demands.
The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a user starts a process and then logs out, the next user who logs on to the system might access the process that the previous user started. This is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything that the second user does using that process is performed with the user rights of the first user. This makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics.
### Possible values
- User-defined list of subsystems
- Not defined
### Best practices
- Set this policy setting to a null value. The default value is **POSIX**, so applications that rely on the POSIX subsystem will no longer run. For example, Microsoft Services for UNIX 3.0 installs an updated version of the POSIX subsystem. Reset this policy setting in Group Policy for any servers that use Services for UNIX 3.0.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>POSIX</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>POSIX</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>POSIX</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>POSIX</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 | POSIX|
| DC Effective Default Settings | POSIX|
| Member Server Effective Default Settings| POSIX|
| Client Computer Effective Default Settings | POSIX|
 
## Policy management
This section describes features and tools that are available 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 POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem.
The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across logons. If a user starts a process and then logs out, there is a potential that the next user who logs on to the computer could access the previous user's process. This would allow the second user to take actions on the process by using the privileges of the first user.
### Countermeasure
Configure the **System settings: Optional subsystems setting** to a null value. The default value is POSIX.
### Potential impact
Applications that rely on the POSIX subsystem no longer operate. For example, Microsoft Services for UNIX (SFU) installs an updated version of the POSIX subsystem that is required, so you must reconfigure this setting in Group Policy for any servers that use SFU.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

82
windows/keep-secure/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
View File

@ -2,80 +2,76 @@
title: System settings Use certificate rules on Windows executables for Software Restriction Policies (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the System settings Use certificate rules on Windows executables for Software Restriction Policies security policy setting.
ms.assetid: 2380d93b-b553-4e56-a0c0-d1ef740d089c
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# System settings: Use certificate rules on Windows executables for Software Restriction Policies
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** security policy setting.
## Reference
This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .exe file name extension. This security setting enables or disables certificate rules (which are a type of software restriction policy). With a software restriction policy, you can create a certificate rule that allows or disallows Microsoft Authenticode®-signed software to run, based on the digital certificate that is associated with the software. For certificate rules to work in software restriction policies, you must enable this security setting.
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
- Set this policy to **Enabled**. Enabling certificate rules results in software restriction policies checking a certificate revocation list (CRL) to make sure that the software's certificate and signature are valid. When you start signed programs, this setting can decrease system performance. You can disable CRLs by editing the software restriction policies in the desired GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes.
- Set this policy to **Enabled**. Enabling certificate rules results in software restriction policies checking a certificate revocation list (CRL) to make sure that the software's certificate and signature are valid. When you start signed programs, this setting can decrease system performance.
You can disable CRLs by editing the software restriction policies in the desired GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Security Options
### Default values
The following table lists the actual and effective default values for this policy. 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>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Disabled</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Disabled</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 | Disabled |
| DC Effective Default Settings | Disabled|
| Member Server Effective Default Settings | Disabled|
| Client Computer Effective Default Settings | Disabled|
 
## Policy management
This section describes features and tools that are available 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
Without the use of software restriction policies, users and device might be exposed to unauthorized software that could include malware.
### Countermeasure
Enable the **System settings: Use certificate rules on Windows executables for Software Restriction Policies** setting.
### Potential impact
If you enable certificate rules, software restriction policies check a certificate revocation list (CRL) to verify that the software's certificate and signature are valid. This checking process may negatively affect performance when signed programs start. To disable this feature, you can edit the software restriction policies in the appropriate GPO. In the **Trusted Publishers Properties** dialog box, clear the **Publisher** and **Timestamp** check boxes.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)

2
windows/manage/index.md
View File

@ -74,4 +74,4 @@ Learn about managing and updating Windows 10.
## Related topics
[Windows 10 and Windows 10 Mobile](../index.md)
 
 
 [Learn how Microsoft does IT at the IT Showcase](https://www.microsoft.com/itshowcase)