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

fixing spacing issues

Browse Source
This commit is contained in:
Brian Lich 2016-05-24 14:20:34 -07:00
parent 171964c58b
commit 4f7cf536c2
17 changed files with 653 additions and 617 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

59
windows/keep-secure/kerberos-policy.md
View File

@ -2,56 +2,37 @@
title: Kerberos Policy (Windows 10)
description: Describes the Kerberos Policy settings and provides links to policy setting descriptions.
ms.assetid: 94017dd9-b1a3-4624-af9f-b29161b4bf38
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Kerberos Policy
**Applies to**
- Windows 10
Describes the Kerberos Policy settings and provides links to policy setting descriptions.
The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used by an attacker. However, this also increases the authorization overhead. In most environments, these settings should not need to be changed.
These policy settings are located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**.
The following topics provide a discussion of 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 settings vulnerabilities of each setting), countermeasures you can take, and the potential impact for each setting.
The following topics provide a discussion of 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 settings vulnerabilities of each setting),
countermeasures 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 user logon restrictions](enforce-user-logon-restrictions.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Enforce user logon restrictions</strong> security policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Maximum lifetime for service ticket](maximum-lifetime-for-service-ticket.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for service ticket</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Maximum lifetime for user ticket](maximum-lifetime-for-user-ticket.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for user ticket</strong> policy setting.</p></td>
</tr>
<tr class="even">
<td align="left"><p>[Maximum lifetime for user ticket renewal](maximum-lifetime-for-user-ticket-renewal.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum lifetime for user ticket renewal</strong> security policy setting.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>[Maximum tolerance for computer clock synchronization](maximum-tolerance-for-computer-clock-synchronization.md)</p></td>
<td align="left"><p>Describes the best practices, location, values, policy management, and security considerations for the <strong>Maximum tolerance for computer clock synchronization</strong> security policy setting.</p></td>
</tr>
</tbody>
</table>
| Topic | Description |
| - | - |
| [Enforce user logon restrictions](enforce-user-logon-restrictions.md) | Describes the best practices, location, values, policy management, and security considerations for the **Enforce user logon restrictions** security policy setting.|
| [Maximum lifetime for service ticket](maximum-lifetime-for-service-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting.|
| [Maximum lifetime for user ticket](maximum-lifetime-for-user-ticket.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting.|
| [Maximum lifetime for user ticket renewal](maximum-lifetime-for-user-ticket-renewal.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting.|
| [Maximum tolerance for computer clock synchronization](maximum-tolerance-for-computer-clock-synchronization.md) | Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** 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)

91
windows/keep-secure/load-and-unload-device-drivers.md
View File

@ -2,96 +2,95 @@
title: Load and unload device drivers (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Load and unload device drivers security policy setting.
ms.assetid: 66262532-c610-470c-9792-35ff4389430f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Load and unload device drivers
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Load and unload device drivers** security policy setting.
## Reference
This policy setting determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code.
Windows supports the Plug and Play specifications that define how a computer can detect and configure newly added hardware, and then automatically install the device driver. Prior to Plug and Play, users needed to manually configure devices before attaching them to the device. This model allows a user to plug in the hardware, then Windows searches for an appropriate device driver package and automatically configures it to work without interfering with other devices.
Because device driver software runs as if it is a part of the operating system with unrestricted access to the entire computer, it is critical that only known and authorized device drivers be permitted.
Constant: SeLoadDriverPrivilege
### Possible values
- User-defined list of accounts
- Default values
- Not Defined
### Best practices
- Because of the potential security risk, do not assign this user right to any user, group, or process that you do not want to take over the system.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Administrators and Print Operators on domain controllers and Administrators 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>
<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></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>Administrators</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></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Print Operators|
| Stand-Alone Server Default Settings | Administrators|
| Domain Controller Effective Default Settings | Administrators<br/>Print Operators |
| Member Server Effective Default Settings | Administrators|
| Client Computer Effective Default Settings | Administrators|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the 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
Device drivers run as highly privileged code. A user who has the **Load and unload device drivers** user right could unintentionally install malware that masquerades as a device driver. Administrators should exercise care and install only drivers with verified digital signatures.
**Note**  
You must have this user right or be a member of the local Administrators group to install a new driver for a local printer or to manage a local printer and configure defaults for options such as duplex printing.
>**Note:**  You must have this user right or be a member of the local Administrators group to install a new driver for a local printer or to manage a local printer and configure defaults for options such as duplex printing.
 
### Countermeasure
Do not assign the **Load and unload device drivers** user right to any user or group other than Administrators on member servers. On domain controllers, do not assign this user right to any user or group other than Domain Admins.
### Potential impact
If you remove the **Load and unload device drivers** user right from the Print Operators 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)

89
windows/keep-secure/lock-pages-in-memory.md
View File

@ -2,92 +2,93 @@
title: Lock pages in memory (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Lock pages in memory security policy setting.
ms.assetid: cc724979-aec0-496d-be4e-7009aef660a3
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Lock pages in memory
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Lock pages in memory** security policy setting.
## Reference
This policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk.
Normally, an application running on Windows can negotiate for more physical memory, and in response to the request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use.
Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could lead to performance degradation.
**Note**  
By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system.
>**Note:**  By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system.
 
Constant: SeLockMemoryPrivilege
### Possible values
- User-defined list of accounts
- Not defined
### Best practices
Best practices are dependent on the platform architecture and the applications running on those platforms.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain Controller Effective Default Settings</p></td>
<td align="left"><p>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|
| Domain Controller 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, 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
Users with the **Lock pages in memory** user right could assign physical memory to several processes, which could leave little or no RAM for other processes and result in a denial-of-service condition.
### Countermeasure
Do not assign the **Lock pages in memory** user right to any accounts.
### 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)

94
windows/keep-secure/log-on-as-a-batch-job.md
View File

@ -2,98 +2,92 @@
title: Log on as a batch job (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a batch job security policy setting.
ms.assetid: 4eaddb51-0a18-470e-9d3d-5e7cd7970b41
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Log on as a batch job
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting.
## Reference
This policy setting determines which accounts can log on by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the **Log on as a batch job** user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user's security context.
Constant: SeBatchLogonRight
### Possible values
- User-defined list of accounts
- Default values
- Not Defined
### Best practices
- Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient in most cases.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, this setting is for Administrators, Backup Operators, and Performance Log Users 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>
<p>Backup Operators</p>
<p>Performance Log Users</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>
<p>Performance Log Users</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>Performance Log Users</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>
<p>Performance Log Users</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Administrators</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| Not defined|
| Default Domain Controller Policy | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Stand-Alone Server Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Domain Controller Effective Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Member Server Effective Default Settings | Administrators<br/>Backup Operators<br/>Performance Log Users|
| Client Computer Effective Default Settings | Administrators|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior use the [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) User Rights Assignment setting.
Group Policy settings are applied in the following order, 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
## 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 **Log on as a batch job** user right presents a low-risk vulnerability. For most organizations, the default settings are sufficient. Members of the local Administrators group have this right by default.
### Countermeasure
You should allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you do not want to use the Task Scheduler in this manner, configure the **Log on as a batch job** user right for only the Local Service account.
For IIS servers, you should configure this policy locally instead of through domain–based Group Policy settings so that you can ensure the local IUSR\_*&lt;ComputerName&gt;* and IWAM\_*&lt;ComputerName&gt;* accounts have this user right.
### Potential impact
If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer cannot assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you may need to assign this user right to additional accounts that are required by those components. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*&lt;ComputerName&gt;*, ASPNET, and IWAM\_*&lt;ComputerName&gt;* accounts. If this user right is not assigned to this group and these accounts, IIS cannot run some COM objects that are necessary for proper functionality.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

91
windows/keep-secure/log-on-as-a-service.md
View File

@ -2,88 +2,91 @@
title: Log on as a service (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Log on as a service security policy setting.
ms.assetid: acc9a9e0-fd88-4cda-ab54-503120ba1f42
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Log on as a service
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting.
## Reference
This policy setting determines which service accounts can register a process as a service. Running a process under a service account circumvents the need for human intervention.
Constant: SeServiceLogonRight
### Possible values
- User-defined list of accounts
- Not Defined
### Best practices
- Minimize the number of accounts that are granted this user right.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default this setting is Network Service on domain controllers and Network Service 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>Network 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></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Network Service</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 | Network Service|
| Member Server Effective Default Settings| Network Service|
| Client Computer Effective Default Settings | Network Service|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
The policy setting **Deny logon as a service** supersedes this policy setting if a user account is subject to both policies.
Group Policy settings are applied in the following order, which will overwrite settings on the local device at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
## 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 **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained that level of access could configure the service to run with the Local System account.
The **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An
attacker who has already attained that level of access could configure the service to run with the Local System account.
### Countermeasure
By definition, the Network Service account has the **Log on as a service** user right. This right is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.
### Potential impact
On most computers, restricting the **Log on as a service** user right to the Local System, Local Service, and 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 **Log on as a service** user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.
On most computers, restricting the **Log on as a service** user right to the Local System, Local Service, and 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 **Log on as a service** user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

48
windows/keep-secure/maintain-applocker-policies.md
View File

@ -2,64 +2,100 @@
title: Maintain AppLocker policies (Windows 10)
description: This topic describes how to maintain rules within AppLocker policies.
ms.assetid: b4fbfdfe-ef3d-49e0-a390-f2dfe74602bc
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maintain AppLocker policies
**Applies to**
- Windows 10
This topic describes how to maintain rules within AppLocker policies.
Common AppLocker maintenance scenarios include:
- A new app is deployed, and you need to update an AppLocker policy.
- A new version of an app is deployed, and you need to either update an AppLocker policy or create a new rule to update the policy.
- An app is no longer supported by your organization, so you need to prevent it from being used.
- An app appears to be blocked but should be allowed.
- An app appears to be allowed but should be blocked.
- A single user or small subset of users needs to use a specific app that is blocked.
There are two methods you can use to maintain AppLocker policies:
- [Maintaining AppLocker policies by using Group Policy](#bkmk-applkr-use-gp)
- [Maintaining AppLocker policies on the local computer](#bkmk-applkr-use-locsnapin)
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs.
**Caution**  
You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
versions of GPOs.
>**Caution:**  You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
 
## <a href="" id="bkmk-applkr-use-gp"></a>Maintaining AppLocker policies by using Group Policy
For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following tasks.
### Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented. For example, if a new version of the application is deployed, you can use **Test-AppLockerPolicy** to verify the effectiveness of your current policy for that app.
### Step 2: Export the AppLocker policy from the GPO
Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your AppLocker reference or test computer. To prepare an AppLocker policy for modification, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md)
### Step 3: Update the AppLocker policy by editing the appropriate AppLocker rule
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has been accessed on the local computer, the specific rules can be modified as required.
To modify AppLocker rules, see the following:
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) or [Merge AppLocker policies manually](merge-applocker-policies-manually.md)
- [Delete an AppLocker rule](delete-an-applocker-rule.md)
- [Enforce AppLocker rules](enforce-applocker-rules.md)
### Step 4: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. (Because AppLocker rules are inherited from linked GPOs, you should deploy all rules for simultaneous testing in all test GPOs.) For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 5: Import the AppLocker policy into the GPO
After testing, import the AppLocker policy back into the GPO for implementation. To update the GPO with a modified AppLocker policy, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 6: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
## <a href="" id="bkmk-applkr-use-locsnapin"></a>Maintaining AppLocker policies by using the Local Security Policy snap-in
For every scenario, the steps to maintain an AppLocker policy by using the Local Group Policy Editor or the Local Security Policy snap-in include the following tasks.
### Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented.
### Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
To modify AppLocker rules, see the appropriate topic listed on [Administer AppLocker](administer-applocker.md).
### Step 3: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. For steps to perform this testing, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
### Step 4: Deploy the policy with the modified rule
You can export and then import AppLocker policies to deploy the policy to other computers running Windows 8 or later. To perform this task, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
### Step 5: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
## Additional resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
 
 

92
windows/keep-secure/manage-auditing-and-security-log.md
View File

@ -2,95 +2,97 @@
title: Manage auditing and security log (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Manage auditing and security log security policy setting.
ms.assetid: 4b946c0d-f904-43db-b2d5-7f0917575347
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Manage auditing and security log
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Manage auditing and security log** security policy setting.
## Reference
This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the Security log in Event Viewer. For more info about the Object Access audit policy, see [Audit object access](basic-audit-object-access.md).
This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the
Security log in Event Viewer. For more info about the Object Access audit policy, see [Audit object access](basic-audit-object-access.md).
Constant: SeSecurityPrivilege
### Possible values
- User-defined list of accounts
- Administrators
- Not Defined
### Best practices
1. Before removing this right from a group, investigate whether applications are dependent on this right.
2. Generally, assigning this user right to groups other than Administrators is not necessary.
### 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 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.
Audits for object access are not performed unless you enable them by using the Local Group Policy Editor, the Group Policy Management Console (GPMC), or the Auditpol command-line tool.
For more information about the Object Access audit policy, see [Audit object access](basic-audit-object-access.md).
### 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 with the **Manage auditing and security log** user right can clear the Security log to erase important evidence of unauthorized activity.
### Countermeasure
Ensure that only the local Administrators group has the **Manage auditing and security log** user right.
### Potential impact
Restricting the **Manage auditing and security log** user right to the local Administrators group is the default configuration.
**Warning**  
If groups other than the local Administrators group have been assigned this user right, removing this user right might cause performance issues with other applications. Before removing this right from a group, investigate whether applications are dependent on this right.
>**Warning:**  If groups other than the local Administrators group have been assigned this user right, removing this user right might cause performance issues with other applications. Before removing this right from a group, investigate whether applications are dependent on this right.
 
## Related topics
[User Rights Assignment](user-rights-assignment.md)
 
 
- [User Rights Assignment](user-rights-assignment.md)

44
windows/keep-secure/manage-packaged-apps-with-applocker.md
View File

@ -2,47 +2,71 @@
title: Manage packaged apps with AppLocker (Windows 10)
description: This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy.
ms.assetid: 6d0c99e7-0284-4547-a30a-0685a9916650
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Manage packaged apps with AppLocker
**Applies to**
- Windows 10
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with AppLocker as part of your overall application control strategy.
## Understanding Packaged apps and Packaged app installers for AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity. With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
**Note**  
AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher because Windows does not support unsigned packaged apps.
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
>**Note:**  AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher because Windows does not support unsigned packaged apps.
 
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, not all these components always share common attributes such as the software’s publisher name, product name, and product version. Therefore, AppLocker controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
### <a href="" id="bkmk-compareclassicmetro"></a>Comparing classic Windows apps and packaged apps
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
- **Installing the apps**   All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
- **Changing the system state**   Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
- **Acquiring the apps**   Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
For info about controlling classic Windows apps, see [Administer AppLocker](administer-applocker.md).
For more info about packaged apps, see [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
## Design and deployment decisions
You can use two methods to create an inventory of packaged apps on a computer: the AppLocker console or the **Get-AppxPackage** Windows PowerShell cmdlet.
**Note**  
Not all packaged apps are listed in AppLocker’s application inventory wizard. Certain app packages are framework packages that are leveraged by other apps. By themselves, these packages cannot do anything, but blocking such packages can inadvertently cause failure for apps that you want to allow. Instead, you can create Allow or Deny rules for the packaged apps that use these framework packages. The AppLocker user interface deliberately filters out all the packages that are registered as framework packages. For info about how to create an inventory list, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
>**Note:**  Not all packaged apps are listed in AppLocker’s application inventory wizard. Certain app packages are framework packages that are leveraged by other apps. By themselves, these packages cannot do anything, but blocking such packages can inadvertently cause failure for apps that you want to allow. Instead, you can create Allow or Deny rules for the packaged apps that use these framework packages. The AppLocker user interface deliberately filters out all the packages that are registered as framework packages. For info about how to create an inventory list, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
 
For info about how to use the **Get-AppxPackage** Windows PowerShell cmdlet, see the [AppLocker PowerShell Command Reference](http://technet.microsoft.com/library/hh847210.aspx).
For info about creating rules for Packaged apps, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
Consider the following info when you are designing and deploying apps:
- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps is not necessary.
- You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps were not always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app. This might be contrary to your design.
- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or
Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app. This might be contrary to your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all packaged apps, you can create a default rule for the packaged apps collection.
## Using AppLocker to manage packaged apps
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
1. Gather information about which Packaged apps are running in your environment. For information about how to do this, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) and [Packaged Apps Default Rules in AppLocker](http://technet.microsoft.com/library/ee460941(WS.10).aspx).
3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
 
 

37
windows/keep-secure/manage-tpm-commands.md
View File

@ -2,54 +2,75 @@
title: Manage TPM commands (Windows 10)
description: This topic for the IT professional describes how to manage which Trusted Platform Module (TPM) commands are available to domain users and to local users.
ms.assetid: a78e751a-2806-43ae-9c20-2e7ca466b765
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Manage TPM commands
**Applies to**
- Windows 10
This topic for the IT professional describes how to manage which Trusted Platform Module (TPM) commands are available to domain users and to local users.
## <a href="" id="bkmk-commands1"></a>
After a computer user takes ownership of the TPM, the TPM owner can limit which TPM commands can be run by creating a list of blocked TPM commands. The list can be created and applied to all computers in a domain by using Group Policy, or a list can be created for individual computers by using the TPM MMC. Because some hardware vendors might provide additional commands or the Trusted Computing Group may decide to add commands in the future, the TPM MMC also supports the ability to block new commands.
Domain administrators can configure a list of blocked TPM commands by using Group Policy. Local administrators cannot allow TPM commands that are blocked through Group Policy. For more information about this Group Policy setting, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-clbtc).
Local administrators can block commands by using the TPM MMC, and commands on the default block list are also blocked unless the Group Policy settings are changed from the default settings.
Two policy settings control the enforcement which allows TPM commands to run. For more information about these policy settings, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-idlb).
The following procedures describe how to manage the TPM command lists. You must be a member of the local Administrators group.
**To block TPM commands by using the Local Group Policy Editor**
1. Open the Local Group Policy Editor (gpedit.msc). If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
**Note**  
Administrators with appropriate rights in a domain can configure a Group Policy Object (GPO) that can be applied through Active Directory Domain Services (AD DS).
>**Note:**  Administrators with appropriate rights in a domain can configure a Group Policy Object (GPO) that can be applied through Active Directory Domain Services (AD DS).
 
2. In the console tree, under **Computer Configuration**, expand **Administrative Templates**, and then expand **System**.
3. Under **System**, click **Trusted Platform Module Services**.
4. In the details pane, double-click **Configure the list of blocked TPM commands**.
5. Click **Enabled**, and then click **Show**.
6. For each command that you want to block, click **Add**, enter the command number, and then click **OK**.
**Note**  
For a list of commands, see the [Trusted Platform Module (TPM) Specifications](http://go.microsoft.com/fwlink/p/?linkid=139770).
>**Note:**  For a list of commands, see the [Trusted Platform Module (TPM) Specifications](http://go.microsoft.com/fwlink/p/?linkid=139770).
 
7. After you have added numbers for each command that you want to block, click **OK** twice.
8. Close the Local Group Policy Editor.
**To block or allow TPM commands by using the TPM MMC**
1. Open the TPM MMC (tpm.msc)
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
3. In the console tree, click **Command Management**. A list of TPM commands is displayed.
4. In the list, select a command that you want to block or allow.
5. Under **Actions**, click **Block Selected Command** or **Allow Selected Command** as needed. If **Allow Selected Command** is unavailable, that command is currently blocked by Group Policy.
**To block new commands**
1. Open the TPM MMC (tpm.msc).
If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
2. In the console tree, click **Command Management**. A list of TPM commands is displayed.
3. In the **Action** pane, click **Block New Command**. The **Block New Command** dialog box is displayed.
4. In the **Command Number** text box, type the number of the new command that you want to block, and then click **OK**. The command number you entered is added to the blocked list.
## <a href="" id="bkmk-tpmcmdlets"></a>Use the TPM cmdlets
If you are using Windows PowerShell to manage your computers, you can also manage the TPM by using Windows PowerShell. To install the TPM cmdlets, type the following command:
**dism /online /enable-feature /FeatureName:tpm-psh-cmdlets**
`dism /online /enable-feature /FeatureName:tpm-psh-cmdlets`
For details about the individual cmdlets, see [TPM Cmdlets in Windows PowerShell](http://technet.microsoft.com/library/jj603116.aspx)
## Additional resources
For more info about TPM, see [Trusted Platform Module technology overview](trusted-platform-module-overview.md#bkmk-additionalresources).
 
 

86
windows/keep-secure/maximum-lifetime-for-service-ticket.md
View File

@ -2,89 +2,91 @@
title: Maximum lifetime for service ticket (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for service ticket security policy setting.
ms.assetid: 484bf05a-3858-47fc-bc02-6599ca860247
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maximum lifetime for service ticket
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for service ticket** security policy setting.
## Reference
The **Maximum lifetime for service ticket** policy setting determines the maximum number of minutes that a granted session ticket can be used to access a particular service. The value must be 10 minutes or greater, and it must be less than or equal to the value of the **Maximum lifetime for service ticket** policy setting.
The possible values for this Group Policy setting are:
- A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets do not expire).
- Not defined.
If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that authenticated the connection expires during the connection.
If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours. In addition, users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire.
### Best practices
- It is advisable to set **Maximum lifetime for service ticket** to **600** minutes.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>600 minutes</p></td>
</tr>
<tr class="even">
<td align="left"><p>Default Domain Controller Policy</p></td>
<td align="left"><p>Not defined</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Stand-Alone Server Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>DC Effective Default Settings</p></td>
<td align="left"><p>600 minutes</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy| 600 minutes|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| DC Effective Default Settings | 600 minutes|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the device is not required for this policy setting to be effective.
This policy setting is configured on the domain controller.
### Group Policy
Client computers will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
If you configure the value for the **Maximum lifetime for service ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled.
### Countermeasure
Configure the **Maximum lifetime for service ticket** setting to 600 minutes.
### Potential impact
None. This is the default configuration.
## Related topics
[Kerberos Policy](kerberos-policy.md)
 
 
- [Kerberos Policy](kerberos-policy.md)

85
windows/keep-secure/maximum-lifetime-for-user-ticket-renewal.md
View File

@ -2,88 +2,89 @@
title: Maximum lifetime for user ticket renewal (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket renewal security policy setting.
ms.assetid: f88cd819-3dd1-4e38-b560-13fe6881b609
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maximum lifetime for user ticket renewal
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket renewal** security policy setting.
## Reference
The **Maximum lifetime for user ticket renewal** policy setting determines the period of time (in days) during which a user’s ticket-granting ticket can be renewed.
The possible values for this Group Policy setting are:
- A user-defined number of days from 0 through 99,999
- Not defined
### Best practices
- If the value for this policy setting is too high, users may be able to renew very old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.
It is advisable to set **Maximum lifetime for user ticket renewal** to **7** days.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>7 days</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>7 days</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| 7 days|
| Default Domain Controller Policy| Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings | 7 days|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
### Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the device is not required for this policy setting to be effective.
This policy setting is configured on the domain controller.
### Group Policy
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
If the value for the **Maximum lifetime for user ticket renewal** setting is too high, users might be able to renew very old user tickets.
### Countermeasure
Configure the **Maximum lifetime for user ticket renewal** setting to 7 days.
### Potential impact
None. This is the default configuration.
## Related topics
[Kerberos Policy](kerberos-policy.md)
 
 
- [Kerberos Policy](kerberos-policy.md)

85
windows/keep-secure/maximum-lifetime-for-user-ticket.md
View File

@ -2,88 +2,89 @@
title: Maximum lifetime for user ticket (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum lifetime for user ticket policy setting.
ms.assetid: bcb4ff59-334d-4c2f-99af-eca2b64011dc
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maximum lifetime for user ticket
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Maximum lifetime for user ticket** policy setting.
## Reference
The **Maximum lifetime for user ticket** policy setting determines the maximum amount of time (in hours) that a user’s ticket-granting ticket can be used. When a user’s ticket-granting ticket expires, a new one must be requested or the existing one must be renewed.
The possible values for this Group Policy setting are:
- A user-defined number of hours from 0 through 99,999
- Not defined
If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire.
### Best practices
- It is advisable to set **Maximum lifetime for user ticket** to 10 hours.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
### Default Values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server Type or GPO</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>10 hours</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>10 hours</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server Type or GPO | Default Value |
| - | - |
| Default Domain Policy| 10 hours|
| Default Domain Controller Policy| Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings | 10 hours|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
This policy setting is configured on the domain controller.
### Group Policy
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local computer, the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
If you configure the value for the **Maximum lifetime for user ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack.
### Countermeasure
Configure the **Maximum lifetime for user ticket** setting with a value between 4 and 10 hours.
### Potential impact
Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to access resources that the user does not have rights to. However, it requires more frequent requests to the KDC for ticket-granting tickets on behalf of users. Most KDCs can support a value of four hours without too much additional burden.
## Related topics
[Kerberos Policy](kerberos-policy.md)
 
 
- [Kerberos Policy](kerberos-policy.md)

82
windows/keep-secure/maximum-password-age.md
View File

@ -2,82 +2,76 @@
title: Maximum password age (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum password age security policy setting.
ms.assetid: 2d6e70e7-c8b0-44fb-8113-870c6120871d
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maximum password age
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Maximum password age** security policy setting.
## Reference
The **Maximum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If **Maximum password age** is between 1 and 999 days, the minimum password age must be less than the maximum password age. If **Maximum password age** is set to 0, [Minimum password age](minimum-password-age.md) can be any value between 0 and 998 days.
**Note**  
Setting **Maximum password age** to -1 is equivalent to 0, which means it never expires. Setting it to any other negative number is equivalent to setting it to **Not Defined**.
>**Note:**  Setting **Maximum password age** to -1 is equivalent to 0, which means it never expires. Setting it to any other negative number is equivalent to setting it to **Not Defined**.
 
### Possible values
- User-specified number of days between 0 and 999
- Not defined
### Best practices
Set **Maximum password age** to a value between 30 and 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to compromise a user's password and have access to your network resources.
### 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>42 days</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>42 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Domain controller effective default settings</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member server effective default settings</p></td>
<td align="left"><p>42 days</p></td>
</tr>
<tr class="even">
<td align="left"><p>Effective GPO default settings on client computers</p></td>
<td align="left"><p>42 days</p></td>
</tr>
</tbody>
</table>
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| 42 days|
| Default domain controller policy| Not defined|
| Stand-alone server default settings | 42 days|
| Domain controller effective default settings | 42 days|
| Member server effective default settings | 42 days|
| Effective GPO default settings on client computers| 42 days|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
### Restart requirement
None. Changes to this policy become effective without a 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
The longer a password exists, the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the **Maximum password age** policy setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.
### Countermeasure
Configure the **Maximum password age** policy setting to a value that is suitable for your organization's business requirements.
### Potential impact
If the **Maximum password age** policy setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization because users might keep their passwords in an unsecured location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
## Related topics
[Password Policy](password-policy.md)
 
 
- [Password Policy](password-policy.md)

88
windows/keep-secure/maximum-tolerance-for-computer-clock-synchronization.md
View File

@ -2,88 +2,90 @@
title: Maximum tolerance for computer clock synchronization (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Maximum tolerance for computer clock synchronization security policy setting.
ms.assetid: ba2cf59e-d69d-469e-95e3-8e6a0ba643af
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Maximum tolerance for computer clock synchronization
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Maximum tolerance for computer clock synchronization** security policy setting.
## Reference
This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller that provides Kerberos authentication.
To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both devices must be set to the same time and date. Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two devices is considered to be authentic.
To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both devices must be set to the same time and date.
Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two devices is considered to be authentic.
The possible values for this Group Policy setting are:
- A user-defined number of minutes from 1 through 99,999
- Not defined
### Best practices
- It is advisable to set **Maximum tolerance for computer clock synchronization** to a value of 5 minutes.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy
### Default values
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Server type or GPO</th>
<th align="left">Default value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Default Domain Policy</p></td>
<td align="left"><p>5 minutes</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>5 minutes</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Member Server Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
<tr class="even">
<td align="left"><p>Client Computer Effective Default Settings</p></td>
<td align="left"><p>Not applicable</p></td>
</tr>
</tbody>
</table>
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy| 5 minutes|
| Default Domain Controller Policy | Not defined|
| Stand-Alone Server Default Settings | Not applicable|
| Domain Controller Effective Default Settings| 5 minutes|
| Member Server Effective Default Settings | Not applicable|
| Client Computer Effective Default Settings | Not applicable|
 
## Policy management
This section describes features, tools, and guidance to help you manage this policy.
A restart of the device is not required for this policy setting to be effective.
This policy setting is configured on the domain controller.
### Group Policy
Client devices will get the new setting during the next scheduled and successful Group Policy refresh. But for domain controllers to assign these new settings immediately, a gpupdate.exe /force is required. On the local device, the Security Configuration Engine will refresh this setting in about five minutes.
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock and a domain controller clock. If the difference between the client computer clock and the domain controller clock is less than the maximum time difference specified in this setting, any time stamp that is used in a session between the two computers is considered to be authentic.
### Countermeasure
Configure the **Maximum tolerance for computer clock synchronization** setting to 5 minutes.
### Potential impact
None. This is the default configuration.
## Related topics
[Kerberos Policy](kerberos-policy.md)
 
 
- [Kerberos Policy](kerberos-policy.md)

17
windows/keep-secure/merge-applocker-policies-by-using-set-applockerpolicy.md
View File

@ -2,27 +2,36 @@
title: Merge AppLocker policies by using Set-ApplockerPolicy (Windows 10)
description: This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
ms.assetid: f1c7d5c0-463e-4fe2-a410-844a404f18d0
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Merge AppLocker policies by using Set-ApplockerPolicy
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter is not specified, then the new policy will overwrite the existing policy.
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](http://technet.microsoft.com/library/hh847212.aspx).
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into Windows PowerShell, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
You can also manually merge AppLocker policies. For the procedure to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
**To merge a local AppLocker policy with another AppLocker policy by using LDAP paths**
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for AppLocker, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
2. At the command prompt, type **C:\\PS&gt;Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP: //***&lt;string&gt;***"** **-Merge** where *&lt;string&gt;* specifies the LDAP path of the unique GPO.
## Example
Gets the local AppLocker policy, and then merges the policy with the existing AppLocker policy in the GPO specified in the LDAP path.
``` syntax
C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP://DC13.Contoso.com/CN={31B2F340-016D-11D2-945F-00C044FB984F9},CN=Policies,CN=System,DC=Contoso,DC=com" -Merge
```
 
 
```

86
windows/keep-secure/merge-applocker-policies-manually.md
View File

@ -2,84 +2,46 @@
title: Merge AppLocker policies manually (Windows 10)
description: This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
ms.assetid: 3605f293-e5f2-481d-8efd-775f9f23c30f
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Merge AppLocker policies manually
**Applies to**
- Windows 10
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. Rule collections are specified within the **RuleCollection Type** element. The XML schema includes five attributes for the different rule collections, as shown in the following table:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Rule collection</th>
<th align="left">RuleCollection Type element</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Executable rules</p></td>
<td align="left"><p>Exe</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows Installer rules</p></td>
<td align="left"><p>Msi</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Script rules</p></td>
<td align="left"><p>Script</p></td>
</tr>
<tr class="even">
<td align="left"><p>DLL rules</p></td>
<td align="left"><p>Dll</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Packaged apps and packaged app installers</p></td>
<td align="left"><p>Appx</p></td>
</tr>
</tbody>
</table>
| Rule collection | RuleCollection Type element |
| - | - |
| Executable rules| Exe|
| Windows Installer rules| Msi|
| Script rules | Script|
| DLL rules | Dll|
| Packaged apps and packaged app installers|Appx|
 
Rule enforcement is specified with the **EnforcementMode** element. The three enforcement modes in the XML correspond to the three enforcement modes in the AppLocker console, as shown in the following table:
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">XML enforcement mode</th>
<th align="left">Enforcement mode in Group Policy</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>NotConfigured</p></td>
<td align="left"><p>Not configured (rules are enforced)</p></td>
</tr>
<tr class="even">
<td align="left"><p>AuditOnly</p></td>
<td align="left"><p>Audit only</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Enabled</p></td>
<td align="left"><p>Enforce rules</p></td>
</tr>
</tbody>
</table>
| XML enforcement mode |Enforcement mode in Group Policy |
| - | - |
| NotConfigured | Not configured (rules are enforced)|
| AuditOnly | Audit only|
| Enabled | Enforce rules|
 
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To merge two or more AppLocker policies**
1. Open an XML policy file in a text editor or XML editor, such as Notepad.
2. Select the rule collection where you want to copy rules from.
3. Select the rules that you want to add to another policy file, and then copy the text.
@ -87,5 +49,3 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
 
 

96
windows/keep-secure/microsoft-network-client-digitally-sign-communications-always.md
View File

@ -2,103 +2,109 @@
title: Microsoft network client Digitally sign communications (always) (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Microsoft network client Digitally sign communications (always) security policy setting.
ms.assetid: 4b7b0298-b130-40f8-960d-60418ba85f76
ms.pagetype: security
ms.prod: W10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Microsoft network client: Digitally sign communications (always)
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting.
## Reference
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets. This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.
This policy setting determines whether SMB packet signing must be negotiated before further communication with the Server service is permitted.
Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.
There are three other policy settings that relate to packet-signing requirements for Server Message Block (SMB) communications:
- [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md)
- [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md)
- [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md)
### Possible values
- Enabled
- Disabled
- Not defined
### Best practices
1. Configure the following security policy settings as follows:
- Disable **Microsoft network client: Digitally sign communications (always)**.
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
2. Alternately, you can set all of these policy settings to Enabled, but enabling them can cause slower performance on client devices and prevent them from communicating with legacy SMB applications and operating systems.
### 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
Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client computer after legitimate authentication, and gain unauthorized access to data.
SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
### Countermeasure
Configure the settings as follows:
- Disable **Microsoft network client: Digitally sign communications (always)**.
- Disable [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
**Note**  
An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
>**Note:**  An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
 
### Potential impact
Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
## Related topics
[Security Options](security-options.md)
 
 
- [Security Options](security-options.md)