From 4842f352e2fb22931965a0763c083f3eba5fbdd5 Mon Sep 17 00:00:00 2001 From: Brian Lich Date: Mon, 23 May 2016 15:46:23 -0700 Subject: [PATCH] fixing spacing issues --- ...criptor-definition-language-sddl-syntax.md | 87 +++++++++-------- ...criptor-definition-language-sddl-syntax.md | 90 +++++++++--------- windows/keep-secure/debug-programs.md | 91 +++++++++--------- .../keep-secure/delete-an-applocker-rule.md | 21 +++-- ...ccess-to-this-computer-from-the-network.md | 89 +++++++++--------- .../keep-secure/deny-log-on-as-a-batch-job.md | 94 ++++++++++--------- .../keep-secure/deny-log-on-as-a-service.md | 90 +++++++++--------- windows/keep-secure/deny-log-on-locally.md | 86 ++++++++--------- ...-log-on-through-remote-desktop-services.md | 86 ++++++++--------- ...oy-the-applocker-policy-into-production.md | 24 ++++- ...p-policy-structure-and-rule-enforcement.md | 46 +++------ ...igitally-signed-on-a-reference-computer.md | 15 ++- ...ine-your-application-control-objectives.md | 11 ++- windows/keep-secure/manage-tpm-lockout.md | 37 ++++++-- 14 files changed, 471 insertions(+), 396 deletions(-) diff --git a/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md index 5d4da312b6..6fe17f05af 100644 --- a/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md +++ b/windows/keep-secure/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md @@ -2,86 +2,91 @@ title: DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax (Windows 10) description: Describes the best practices, location, values, and security considerations for the DCOM Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting. ms.assetid: 0fe3521a-5252-44df-8a47-8d92cf936e7c -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. + ## Reference + This policy setting allows you to define additional computer-wide controls that govern access to all Distributed Component Object Model (DCOM)–based applications on a device. These controls restrict call, activation, or launch requests on the device. A simple way to think about these access controls is as an additional access check that is performed against a device-wide access control list (ACL) on each call, activation, or launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to access any COM-based server. This policy setting controls access permissions to cover call rights. + These device-wide ACLs provide a way to override weak security settings that are specified by an application through the CoInitializeSecurity function or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific server. + These ACLs also provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers on the device. + This policy setting allows you to specify an ACL in two different ways. You can type the security descriptor in SDDL, or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you are running. + ### Possible values + - *User-defined input* of the SDDL representation of the groups and privileges + When you specify the users or groups that are to be given permissions, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges for local access and remote access. + - Blank + This represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it as Not defined. The Blank value is set by using the ACL editor to empty the list, and then pressing OK. + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Blank

Default Domain Controller Policy

Blank

Stand-Alone Server Default Settings

Blank

DC Effective Default Settings

Not defined

Member Server Effective Default Settings

Not defined

Client Computer Effective Default Settings

Not defined

+ +| Server type or GPO | Default value +| - | - | +| Default Domain Policy | Blank | +| Default Domain Controller Policy | Blank | +| Stand-Alone Server Default Settings | Blank | +| DC Effective Default Settings | Not defined | +| Member Server Effective Default Settings | Not defined | +| Client Computer Effective Default Settings | Not defined |   ## Policy management + This section describes features and tools that are available to help you manage this policy. ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + The registry settings that are created as a result of enabling the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting take precedence over the previous registry settings when this policy setting was configured. The Remote Procedure Call (RPC) service checks the new registry keys in the Policies section for the computer restrictions, and these registry entries take precedence over the existing registry keys under OLE. This means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, device access permissions for users are not changed. Use care in configuring the list of users and groups. -If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in the Windows operating system, the administrator can use the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting to manage DCOM access to the computer. The administrator can use this setting to specify which users and groups can access the DCOM application on the computer locally and remotely. This will restore control of the DCOM application to the administrator and users. To do this, open the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click **Edit Security**. Specify the users or groups you want to include and the computer access permissions for those users or groups. This defines the setting and sets the appropriate SDDL value. + +If the administrator is denied permission to access DCOM applications due to the changes made to DCOM in the Windows operating system, the administrator can use the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting to manage DCOM access to the computer. The administrator can use this setting to specify which users and groups can access the DCOM application on the computer locally and remotely. This will restore control of the DCOM application to the administrator and users. To do this, open the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click +**Edit Security**. Specify the users or groups you want to include and the computer access permissions for those users or groups. This defines the setting and sets the appropriate SDDL value. + ## 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 + Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. Administrators cannot override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls. + Also, the COM infrastructure includes the Remote Procedure Call Services (RPCSS), a system service that runs during and after computer startup. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote access, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users who use remote, unauthenticated computers. + ### Countermeasure + To protect individual COM-based applications or services, set the **DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting to an appropriate device-wide ACL. + ### Potential impact + Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific call permissions that ACL assigns are the correct permissions for appropriate users. If it does not, you must change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail. + ## Related topics -[Security Options](security-options.md) + +- [Security Options](security-options.md)     diff --git a/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md index ec95e60bb9..d4c42764a5 100644 --- a/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md +++ b/windows/keep-secure/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md @@ -2,86 +2,90 @@ title: DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax (Windows 10) description: Describes the best practices, location, values, and security considerations for the DCOM Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax security policy setting. ms.assetid: 4b95d45f-dd62-4c34-ba32-43954528dabe -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft + --- + # DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax + **Applies to** - Windows 10 + Describes the best practices, location, values, and security considerations for the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** security policy setting. + ## Reference + This policy setting is similar to the [DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax](dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md) setting in that it allows you to define additional computer-wide controls that govern access to all DCOM–based applications on a device. However, the ACLs that are specified in this policy setting control local and remote COM launch requests (not access requests) on the device. A simple way to think about this access control is as an additional access check that is performed against a device-wide ACL on each launch of any COM-based server. If the access check fails, the call, activation, or launch request is denied. (This check is in addition to any access check that is run against the server-specific ACLs.) In effect, it provides a minimum authorization standard that must be passed to launch any COM-based server. The DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax policy setting differs in that it provides a minimum access check that is applied to attempts to access an already launched COM-based server. + These device-wide ACLs provide a way to override weak security settings that are specified by an application through CoInitializeSecurity or application-specific security settings. They provide a minimum security standard that must be passed, regardless of the settings of the specific COM-based server. These ACLs provide a centralized location for an administrator to set a general authorization policy that applies to all COM-based servers. -The **DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax** setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can grant or deny Local Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you are running. +The **DCOM: Machine Launch Restrictions in the Security Descriptor Definition Language (SDDL) syntax** setting allows you to specify an ACL in two ways. You can type the security descriptor in SDDL, or you can grant or deny Local +Access and Remote Access permissions to users and groups. We recommend that you use the built-in user interface to specify the ACL contents that you want to apply with this setting. The default ACL settings vary, depending on the version of Windows you are running. + ### Possible values + - Blank + This represents how the local security policy deletes the policy enforcement key. This value deletes the policy and then sets it to Not defined. The Blank value is set by using the ACL editor to empty the list, and then pressing OK. + - *User-defined input* of the SDDL representation of the groups and privileges + When you specify the users or groups that are to be given permission, the security descriptor field is populated with the Security Descriptor Definition Language representation of those groups and privileges. Users and groups can be given explicit Allow or Deny privileges on both local access and remote access. + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Blank

Default Domain Controller Policy

Blank

Stand-Alone Server Default Settings

Blank

DC Effective Default Settings

Not defined

Member Server Effective Default Settings

Not defined

Client Computer Effective Default Settings

Not defined

+ +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Blank | +| Default Domain Controller Policy | Blank| +| Stand-Alone Server Default Settings |Blank | +| DC Effective Default Settings | Not defined| +| Member Server Effective Default Settings | Not defined | +| Client Computer Effective Default Settings | Not defined|   ## Policy management + This section describes features and tools that are available to help you manage this policy. + ### Restart requirement + None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy. + ### Group Policy + The registry settings that are created as a result of this policy take precedence over the previous registry settings in this area. The Remote Procedure Call (RPC) service (RpcSs) checks the new registry keys in the Policies section for the computer restrictions; these entries take precedence over the existing registry keys under OLE. + If you are denied access to activate and launch DCOM applications due to the changes made to DCOM in the Windows operating system, this policy setting can be used to control the DCOM activation and launch to the device. + You can specify which users and groups can launch and activate DCOM applications on the device locally and remotely by using the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** policy setting. This restores control of the DCOM application to the administrator and specified users. To do this, open the **DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax** setting, and click **Edit Security**. Specify the groups that you want to include and the device launch permissions for those groups. This defines the setting and sets the appropriate SDDL value. + ## 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 + Many COM applications include some security-specific code (for example, to call CoInitializeSecurity), but they use weak settings that allow unauthenticated access to the process. You cannot override these settings to force stronger security in earlier versions of Windows without modifying the application. An attacker could attempt to exploit weak security in an individual application by attacking it through COM calls. + Also, the COM infrastructure includes the Remote Procedure Call Service (RPCSS), a system service that runs during computer startup and always runs after that. This service manages activation of COM objects and the running object table and provides helper services to DCOM remoting. It exposes RPC interfaces that can be called remotely. Because some COM-based servers allow unauthenticated remote component activation, these interfaces can be called by anyone, including unauthenticated users. As a result, RPCSS can be attacked by malicious users using remote, unauthenticated computers. + ### Countermeasure + To protect individual COM-based applications or services, set this policy setting to an appropriate computer-wide ACL. + ### Potential impact + Windows implements default COM ACLs when they are installed. Modifying these ACLs from the default may cause some applications or components that communicate by using DCOM to fail. If you implement a COM-based server and you override the default security settings, confirm that the application-specific launch permissions ACL assigns include activation permissions to appropriate users. If it does not, you must change your application-specific launch permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM do not fail. + ## Related topics -[Security Options](security-options.md) -  -  + +- [Security Options](security-options.md) diff --git a/windows/keep-secure/debug-programs.md b/windows/keep-secure/debug-programs.md index cfcafef2b9..4b133fd251 100644 --- a/windows/keep-secure/debug-programs.md +++ b/windows/keep-secure/debug-programs.md @@ -2,88 +2,91 @@ title: Debug programs (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Debug programs security policy setting. ms.assetid: 594d9f2c-8ffc-444b-9522-75615ec87786 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Debug programs + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Debug programs** security policy setting. + ## Reference + This policy setting determines which users can attach to or open any process, even those they do not own. Developers who are debugging their own applications do not need to be assigned this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating-system components. + Constant: SeDebugPrivilege + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + - Assign this user right only to trusted users to reduce security vulnerabilities. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment + ### Default values + By default, members of the Administrators group have this right. + 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault 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

+ +| 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 and tools that are available to help you manage this policy. + A restart of the device is not required for this policy setting to be effective. + Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on. + ### Group Policy + Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: + 1. Local policy settings 2. Site policy settings 3. Domain policy settings 4. OU policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability -The **Debug programs** user right can be exploited to capture sensitive device information from system memory or to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed passwords and other private security information or to insert malware. By default, the **Debug programs** user right is assigned only to administrators, which helps mitigate risk from this vulnerability. + +The **Debug programs** user right can be exploited to capture sensitive device information from system memory or to access and modify kernel or application structures. Some attack tools exploit this user right to extract hashed passwords and other private security information or to insert malware. +By default, the **Debug programs** user right is assigned only to administrators, which helps mitigate risk from this vulnerability. + ### Countermeasure + Remove the accounts of all users and groups that do not require the **Debug programs** user right. + ### Potential impact -If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this capability on production devices. If an issue arises that requires an application to be debugged on a production server, you can move the server to a different organizational unit (OU) temporarily and assign the **Debug programs** user right to a separate Group Policy for that OU. + +If you revoke this user right, no one can debug programs. However, typical circumstances rarely require this capability on production devices. If an issue arises that requires an application to be debugged on a production server, you can move the server to a different organizational unit (OU) +temporarily and assign the **Debug programs** user right to a separate Group Policy for that OU. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/delete-an-applocker-rule.md b/windows/keep-secure/delete-an-applocker-rule.md index 7b34477fad..ad342ee6cf 100644 --- a/windows/keep-secure/delete-an-applocker-rule.md +++ b/windows/keep-secure/delete-an-applocker-rule.md @@ -2,26 +2,33 @@ title: Delete an AppLocker rule (Windows 10) description: This topic for IT professionals describes the steps to delete an AppLocker rule. ms.assetid: 382b4be3-0df9-4308-89b2-dcf9df351eb5 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Delete an AppLocker rule + **Applies to** - Windows 10 + This topic for IT professionals describes the steps to delete an AppLocker rule. + As older apps are retired and new apps are deployed in your organization, it will be necessary to modify the application control policies. If an app becomes unsupported by the IT department or is no longer allowed due to the organization's security policy, then deleting the rule or rules associated with that app will prevent the app from running. + For info about testing an AppLocker policy to see what rules affect which files or applications, see [Test an AppLocker policy by Using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md). -You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins). + +You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer +AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins). + **To delete a rule in an AppLocker policy** + 1. Open the AppLocker console. 2. Click the appropriate rule collection for which you want to delete the rule. 3. In the details pane, right-click the rule to delete, click **Delete**, and then click **Yes**. -**Note**   -When using Group Policy, for the rule deletion to take effect on computers within the domain, the GPO must be distributed or refreshed. + +>**Note:**  When using Group Policy, for the rule deletion to take effect on computers within the domain, the GPO must be distributed or refreshed. + When this procedure is performed on the local device, the AppLocker policy takes effect immediately. -  -  -  diff --git a/windows/keep-secure/deny-access-to-this-computer-from-the-network.md b/windows/keep-secure/deny-access-to-this-computer-from-the-network.md index 07247e4be1..df4e48dc46 100644 --- a/windows/keep-secure/deny-access-to-this-computer-from-the-network.md +++ b/windows/keep-secure/deny-access-to-this-computer-from-the-network.md @@ -2,94 +2,99 @@ title: Deny access to this computer from the network (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Deny access to this computer from the network security policy setting. ms.assetid: 935e9f89-951b-4163-b186-fc325682bb0b -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deny access to this computer from the network + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Deny access to this computer from the network** security policy setting. + ## Reference + This security setting determines which users are prevented from accessing a device over the network. + Constant: SeDenyNetworkLogonRight + ### Possible values + - User-defined list of accounts - Guest + ### Best practices + - Because all Active Directory Domain Services programs use a network logon for access, use caution when you assign this user right on domain controllers. + ### Location + Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment + ### Default values + By default, this setting is Guest 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault value

Default Domain Policy

Not defined

Default Domain Controller Policy

Guest

Stand-Alone Server Default Settings

Guest

Domain Controller Effective Default Settings

Guest

Member Server Effective Default Settings

Guest

Client Computer Effective Default Settings

Guest

+ + +| Server type or GPO | Default value | +| - | - | +| Default Domain Policy | Not defined | +| Default Domain Controller Policy | Guest | +| Stand-Alone Server Default Settings | Guest | +| Domain Controller Effective Default Settings | Guest | +| Member Server Effective Default Settings | Guest | +| Client Computer Effective Default Settings | Guest |   ## Policy management + This section describes features and tools available to help you manage this policy. + A restart of the device is not required for this policy setting to be effective. + This policy setting supersedes the **Access this computer from the network** policy setting if a user account is subject to both policies. + 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 who can log on to the device over the network can enumerate lists of account names, group names, and shared resources. Users with permission to access shared folders and files can connect over the network and possibly view or modify data. + ### Countermeasure + Assign the **Deny access to this computer from the network** user right to the following accounts: + - Anonymous logon - Built-in local Administrator account - Local Guest account - All service accounts + An important exception to this list is any service accounts that are used to start services that must connect to the device over the network. For example, let’s say you have configured a shared folder for web servers to access, and you present content within that folder through a website. You may need to allow the account that runs IIS to log on to the server with the shared folder from the network. This user right is particularly effective when you must configure servers and workstations on which sensitive information is handled because of regulatory compliance concerns. + ### Potential impact + If you configure the **Deny access to this computer from the network** user right for other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should verify that delegated tasks are not negatively affected. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/deny-log-on-as-a-batch-job.md b/windows/keep-secure/deny-log-on-as-a-batch-job.md index 11dbb9313f..d3abeeb6d5 100644 --- a/windows/keep-secure/deny-log-on-as-a-batch-job.md +++ b/windows/keep-secure/deny-log-on-as-a-batch-job.md @@ -2,92 +2,98 @@ title: Deny log on as a batch job (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a batch job security policy setting. ms.assetid: 0ac36ebd-5e28-4b6a-9b4e-8924c6ecf44b -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deny log on as a batch job + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Deny log on as a batch job** security policy setting. + ## Reference -This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to schedule and start jobs automatically in the future. The ability to log on by using a batch-queue tool is needed for any account that is used to start scheduled jobs by means of the Task Scheduler. + +This policy setting determines which accounts are prevented from logging on by using a batch-queue tool to schedule and start jobs automatically in the future. The ability to log on by using a batch-queue tool is needed for any account that is used to start scheduled jobs by means of the Task +Scheduler. + Constant: SeDenyBatchLogonRight + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + 1. When you assign this user right, thoroughly test that the effect is what you intended. 2. Within a domain, modify this setting on the applicable Group Policy Object (GPO). 3. **Deny log on as a batch job** prevents administrators or operators from using their personal accounts to schedule tasks, which helps with business continuity when that person transitions to other positions or responsibilities. + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault 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

+ +| 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 and tools available 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. + This policy setting might conflict with and negate the **Log on as a batch job** setting. + ### Group Policy + On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting. -For example, if you are trying to configure Task Scheduler on your domain controller, check the Settings tab of your two domain controller policy and domain policy GPOs in the Group Policy Management Console (GPMC). Verify the targeted account is not present in the **Deny log on as a batch job** User Rights Assignment and also correctly configured in the **Log on as a batch job** setting. + +For example, if you are trying to configure Task Scheduler on your domain controller, check the Settings tab of your two domain controller policy and domain policy GPOs in the Group Policy Management Console (GPMC). Verify the targeted account is not present in the **Deny log on as a batch job** + +User Rights Assignment and also correctly configured in the **Log on as a batch job** setting. + 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 + Accounts that have the **Deny log on as a batch job** user right could be used to schedule jobs that could consume excessive computer resources and cause a denial-of-service condition. + ### Countermeasure + Assign the **Deny log on as a batch job** user right to the local Guest account. + ### Potential impact + If you assign the **Deny log on as a batch job** user right to other accounts, you could deny the ability to perform required job activities to users who are assigned specific administrative roles. You should confirm that delegated tasks are not affected adversely. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/deny-log-on-as-a-service.md b/windows/keep-secure/deny-log-on-as-a-service.md index af4556d1b8..8fa66ee734 100644 --- a/windows/keep-secure/deny-log-on-as-a-service.md +++ b/windows/keep-secure/deny-log-on-as-a-service.md @@ -2,91 +2,95 @@ title: Deny log on as a service (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on as a service security policy setting. ms.assetid: f1114964-df86-4278-9b11-e35c66949794 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deny log on as a service + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Deny log on as a service** security policy setting. + ## Reference + This policy setting determines which users are prevented from logging on to the service applications on a device. + A service is an application type that runs in the system background without a user interface. It provides core operating system features, such as web serving, event logging, file serving, printing, cryptography, and error reporting. + Constant: SeDenyServiceLogonRight + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + 1. When you assign this user right, thoroughly test that the effect is what you intended. 2. Within a domain, modify this setting on the applicable Group Policy Object (GPO). + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault 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

+ +| 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 and tools available 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 + On a domain-joined device, including the domain controller, this policy can be overwritten by a domain policy, which will prevent you from modifying the local policy setting. + This policy setting might conflict with and negate the **Log on as a service** setting. + 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 -Accounts that can log on to a service application could be used to configure and start new unauthorized services, such as a keylogger or other malware. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative rights can install and configure services, and an attacker who has already attained that level of access could configure the service to run by using the System account. + +Accounts that can log on to a service application could be used to configure and start new unauthorized services, such as a keylogger or other malware. The benefit of the specified countermeasure is somewhat reduced by the fact that only users with administrative rights can install and configure +services, and an attacker who has already attained that level of access could configure the service to run by using the System account. + ### Countermeasure + We recommend that you not assign the **Deny log on as a service** user right to any accounts. This is the default configuration. Organizations that are extremely concerned about security might assign this user right to groups and accounts when they are certain that they will never need to log on to a service application. + ### Potential impact + If you assign the **Deny log on as a service** user right to specific accounts, services may not start and a denial-of-service condition could result. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/deny-log-on-locally.md b/windows/keep-secure/deny-log-on-locally.md index e8bc095116..916d358f89 100644 --- a/windows/keep-secure/deny-log-on-locally.md +++ b/windows/keep-secure/deny-log-on-locally.md @@ -2,90 +2,92 @@ title: Deny log on locally (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on locally security policy setting. ms.assetid: 00150e88-ec9c-43e1-a70d-33bfe10434db -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deny log on locally + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Deny log on locally** security policy setting. + ## Reference + This policy setting determines which users are prevented from logging on directly at the device's console. + Constant: SeDenyInteractiveLogonRight + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + 1. Assign the **Deny log on locally** user right to the local guest account to restrict access by potentially unauthorized users. 2. Test your modifications to this policy setting in conjunction with the **Allow log on locally** policy setting to determine if the user account is subject to both policies. + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault 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

+ +| 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 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. + If you apply this policy setting to the Everyone group, no one will be able to log on locally. + ### Group Policy + This policy setting supersedes the **Allow log on locally** policy setting if a user account is subject to both policies. + Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update: + 1. Local policy settings 2. Site policy settings 3. Domain policy settings 4. OU policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Any account with the ability to log on locally could be used to log on at the console of the device. If this user right is not restricted to legitimate users who must log on to the console of the device, unauthorized users might download and run malicious software that elevates their user rights. + ### Countermeasure + Assign the **Deny log on locally** user right to the local Guest account. If you have installed optional components such as ASP.NET, you may want to assign this user right to additional accounts that are required by those components. + ### Potential impact + If you assign the **Deny log on locally** user right to additional accounts, you could limit the abilities of users who are assigned to specific roles in your environment. However, this user right should explicitly be assigned to the ASPNET account on device that are configured with the Web Server role. You should confirm that delegated activities are not adversely affected. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/deny-log-on-through-remote-desktop-services.md b/windows/keep-secure/deny-log-on-through-remote-desktop-services.md index 85f6651839..6877912bae 100644 --- a/windows/keep-secure/deny-log-on-through-remote-desktop-services.md +++ b/windows/keep-secure/deny-log-on-through-remote-desktop-services.md @@ -2,89 +2,91 @@ title: Deny log on through Remote Desktop Services (Windows 10) description: Describes the best practices, location, values, policy management, and security considerations for the Deny log on through Remote Desktop Services security policy setting. ms.assetid: 84bbb807-287c-4acc-a094-cf0ffdcbca67 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deny log on through Remote Desktop Services + **Applies to** - Windows 10 + Describes the best practices, location, values, policy management, and security considerations for the **Deny log on through Remote Desktop Services** security policy setting. + ## Reference + This policy setting determines which users are prevented from logging on to the device through a Remote Desktop connection through Remote Desktop Services. It is possible for a user to establish a Remote Desktop connection to a particular server, but not be able to log on to the console of that server. + Constant: SeDenyRemoteInteractiveLogonRight + ### Possible values + - User-defined list of accounts - Not defined + ### Best practices + - To control who can open a Remote Desktop connection and log on to the device, add the user account to or remove user accounts from the Remote Desktop Users group. + ### 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. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Server type or GPODefault 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

+ +| 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. + The **Remote System** property controls settings for Remote Desktop Services (**Allow or prevent remote connections to the computer**) and for Remote Assistance (**Allow Remote Assistance connections to this computer**). + ### Group Policy + This policy setting supersedes the [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md) policy setting if a user account is subject to both policies. + Group Policy settings are applied in the following order. They 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. Organizational unit policy settings + When a local setting is greyed out, it indicates that a GPO currently controls that setting. + ## Security considerations + This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. + ### Vulnerability + Any account with the right to log on through Remote Desktop Services could be used to log on to the remote console of the device. If this user right is not restricted to legitimate users who need to log on to the console of the computer, malicious users might download and run software that elevates their user rights. + ### Countermeasure + Assign the **Deny log on through Remote Desktop Services** user right to the built-in local guest account and all service accounts. If you have installed optional components, such as ASP.NET, you may want to assign this user right to additional accounts that are required by those components. + ### Potential impact + If you assign the **Deny log on through Remote Desktop Services** user right to other groups, you could limit the abilities of users who are assigned to specific administrative roles in your environment. Accounts that have this user right cannot connect to the device through Remote Desktop Services or Remote Assistance. You should confirm that delegated tasks are not negatively affected. + ## Related topics -[User Rights Assignment](user-rights-assignment.md) -  -  + +- [User Rights Assignment](user-rights-assignment.md) diff --git a/windows/keep-secure/deploy-the-applocker-policy-into-production.md b/windows/keep-secure/deploy-the-applocker-policy-into-production.md index 1fbb0a2cc3..32e3cd0d65 100644 --- a/windows/keep-secure/deploy-the-applocker-policy-into-production.md +++ b/windows/keep-secure/deploy-the-applocker-policy-into-production.md @@ -2,31 +2,45 @@ title: Deploy the AppLocker policy into production (Windows 10) description: This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings. ms.assetid: ebbb1907-92dc-499e-8cee-8e637483c9ae -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Deploy the AppLocker policy into production + **Applies to** - Windows 10 + This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker application control settings. + After successfully testing and modifying the AppLocker policy for each Group Policy Object (GPO), you are ready to deploy the enforcement settings into production. For most organizations, this means switching the AppLocker enforcement setting from **Audit only** to **Enforce rules**. However, it is important to follow the deployment plan that you created earlier. For more info, see the [AppLocker Design Guide](applocker-policies-design-guide.md). Depending on the needs of different business groups in your organization, you might deploy different enforcement settings for linked GPOs. + ### Understand your design decisions + Before you deploy an AppLocker policy, you should determine: + - For each business group, which applications will be controlled and in what manner. For more info, see [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md). - How to handle requests for application access. For info about what to consider when developing your support policies, see [Plan for AppLocker policy management](plan-for-applocker-policy-management.md). - How to manage events, including forwarding events. For info about event management in AppLocker, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md). - Your GPO structure, including how to include policies generated by Software Restriction Policies and AppLocker policies. For more info, see [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md). + For info about how AppLocker deployment is dependent on design decisions, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md). + ### AppLocker deployment methods -If you have configured a reference device, you can create and update your AppLocker policies on this device, test the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create the policies and set the enforcement setting on **Audit only**, then observe the events that are generated. + +If you have configured a reference device, you can create and update your AppLocker policies on this device, test the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create the policies and set the enforcement setting on **Audit only**, then +observe the events that are generated. - [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md) + This topic describes the steps to use an AppLocker reference computer to prepare application control policies for deployment by using Group Policy or other means. + - [Deploy AppLocker policies by using the enforce rules setting](deploy-applocker-policies-by-using-the-enforce-rules-setting.md) + This topic describes the steps to deploy the AppLocker policy by changing the enforcement setting to **Audit only** or to **Enforce rules**. + ## See also -[AppLocker deployment guide](applocker-policies-deployment-guide.md) -  -  + +- [AppLocker deployment guide](applocker-policies-deployment-guide.md) diff --git a/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md b/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md index 68200b376d..5733fd532e 100644 --- a/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md +++ b/windows/keep-secure/determine-group-policy-structure-and-rule-enforcement.md @@ -2,51 +2,33 @@ title: Determine the Group Policy structure and rule enforcement (Windows 10) description: This overview topic describes the process to follow when you are planning to deploy AppLocker rules. ms.assetid: f435fcbe-c7ac-4ef0-9702-729aab64163f -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Determine the Group Policy structure and rule enforcement + **Applies to** - Windows 10 + This overview topic describes the process to follow when you are planning to deploy AppLocker rules. + ## In this section - ---- - - - - - - - - - - - - - - - - - - - - -
TopicDescription

[Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)

This topic describes the AppLocker enforcement settings for rule collections.

[Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)

This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.

[Document the Group Policy structure and AppLocker rule enforcement](document-group-policy-structure-and-applocker-rule-enforcement.md)

This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker.

+ +| Topic | Description | +| - | - | +| [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md) | This topic describes the AppLocker enforcement settings for rule collections. | +| [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md) | This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.| +| [Document the Group Policy structure and AppLocker rule enforcement](document-group-policy-structure-and-applocker-rule-enforcement.md) | This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker. |   When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker policy in your organization, you should consider the following: + - Whether you are creating new GPOs or using existing GPOs - Whether you are implementing Software Restriction Policies (SRP) policies and AppLocker policies in the same GPO - GPO naming conventions - GPO size limits -**Note**   -There is no default limit on the number of AppLocker rules that you can create. However, in Windows Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to 100 MB. -  -  -  + +>**Note:**  There is no default limit on the number of AppLocker rules that you can create. However, in Windows Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to 100 MB. diff --git a/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md b/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md index ad2925ee0a..a02d55ecc7 100644 --- a/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md +++ b/windows/keep-secure/determine-which-applications-are-digitally-signed-on-a-reference-computer.md @@ -2,24 +2,35 @@ title: Determine which apps are digitally signed on a reference device (Windows 10) description: This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed. ms.assetid: 24609a6b-fdcb-4083-b234-73e23ff8bcb8 -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Determine which apps are digitally signed on a reference device + **Applies to** - Windows 10 + This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed. + The Windows PowerShell cmdlet **Get-AppLockerFileInformation** can be used to determine which apps installed on your reference devices are digitally signed. Perform the following steps on each reference computer that you used to define the AppLocker policy. The device does not need to be joined to the domain. + Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure. + **To determine which apps are digitally signed on a reference device** 1. Run **Get-AppLockerFileInformation** with the appropriate parameters. + The **Get-AppLockerFileInformation** cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information. + 2. Analyze the publisher's name and digital signature status from the output of the command. + For command parameters, syntax, and examples, see [Get-AppLockerFileInformation](http://technet.microsoft.com/library/ee460961.aspx). + ## Related topics -[Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md) + +- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)     diff --git a/windows/keep-secure/determine-your-application-control-objectives.md b/windows/keep-secure/determine-your-application-control-objectives.md index 55e77bdb3b..65098f5d72 100644 --- a/windows/keep-secure/determine-your-application-control-objectives.md +++ b/windows/keep-secure/determine-your-application-control-objectives.md @@ -2,19 +2,26 @@ title: Determine your application control objectives (Windows 10) description: This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker. ms.assetid: 0e84003e-6095-46fb-8c4e-2065869bb53b -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- + # Determine your application control objectives + **Applies to** - Windows 10 + This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker. + AppLocker is very effective for organizations with app restriction requirements whose environments have a simple topography and the application control policy goals are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the PCs that they manage for a relatively small number of apps. + There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of application control policies is to allow or prevent employees from using apps that might actually be productivity tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly, creating user support processes and network support processes to keep the organization productive are also concerns. + Use the following table to develop your own objectives and determine which application control feature best addresses those objectives. + @@ -149,5 +156,3 @@ Use the following table to develop your own objectives and determine which appli
  For more general info, see [AppLocker](applocker-overview.md). -  -  diff --git a/windows/keep-secure/manage-tpm-lockout.md b/windows/keep-secure/manage-tpm-lockout.md index efe696a11e..7c75700ed0 100644 --- a/windows/keep-secure/manage-tpm-lockout.md +++ b/windows/keep-secure/manage-tpm-lockout.md @@ -2,48 +2,73 @@ title: Manage TPM lockout (Windows 10) description: This topic for the IT professional describes how to manage the lockout feature for the Trusted Platform Module (TPM) in Windows. ms.assetid: bf27adbe-404c-4691-a644-29ec722a3f7b -ms.pagetype: security ms.prod: W10 ms.mktglfcycl: deploy ms.sitesec: library +ms.pagetype: security author: brianlic-msft --- # Manage TPM lockout + **Applies to** - Windows 10 + This topic for the IT professional describes how to manage the lockout feature for the Trusted Platform Module (TPM) in Windows. + ## About TPM lockout + The TPM will lock itself to prevent tampering or malicious attacks. TPM lockout often lasts for a variable amount of time or until the computer is turned off. While the TPM is in lockout mode, it generally returns an error message when it receives commands that require an authorization value. One exception is that the TPM always allows the owner at least one attempt to reset the TPM lockout when it is in lockout mode. + TPM ownership is commonly taken the first time BitLocker Drive Encryption is turned on for the computer. In this case, the TPM owner authorization password is saved with the BitLocker recovery key. When the BitLocker recovery key is saved to a file, BitLocker also saves a TPM owner password file (.tpm) with the TPM owner password hash value. When the BitLocker recovery key is printed, the TPM owner password is printed at the same time. You can also save your TPM owner password hash value to Active Directory Domain Services (AD DS) if your organization's Group Policy settings are configured to do so. + In some cases, encryption keys are protected by a TPM by requiring a valid authorization value to access the key. A common example is configuring BitLocker Drive Encryption to use the TPM plus PIN key protector. In this scenario, the user must type the correct PIN during the boot process to access the volume encryption key protected by the TPM. To prevent malicious users or software from discovering authorization values, TPMs implement protection logic. The protection logic is designed to slow or stop responses from the TPM if it detects that an entity might be trying to guess authorization values. + The industry standards from the Trusted Computing Group (TCG) specify that TPM manufacturers must implement some form of protection logic in TPM 1.2 and TPM 2.0 chips. TPM manufacturers implement different protection mechanisms and behavior. The general guidance is for the TPM chip to take exponentially longer to respond if incorrect authorization values are sent to the TPM. Some TPM chips may not store failed attempts over time. Other TPM chips may store every failed attempt indefinitely. Therefore, some users may experience increasingly longer delays when they mistype an authorization value that is sent to the TPM. This can prevent them from using the TPM for a period of time. + If your TPM has entered lockout mode or is responding slowly to commands, you can reset the lockout value by using the following procedures. Resetting the TPM lockout requires the TPM owner’s authorization. + ## Reset the TPM lockout by using the TPM MMC + The following procedure explains the steps to reset the TPM lockout by using the TPM MMC. + **To reset the TPM lockout** + 1. Open the TPM MMC (tpm.msc). 2. In the **Action** pane, click **Reset TPM Lockout** to start the Reset TPM Lockout Wizard. 3. Choose one of the following methods to enter the TPM owner password: - If you saved your TPM owner password to a .tpm file, click **I have the owner password file**, and then type the path to the file, or click **Browse** to navigate to the file location. - If you want to manually enter your TPM owner password, click **I want to enter the owner password**, and then type the password in the text box provided. - **Note**   - If you enabled BitLocker and your TPM at the same time, and you printed your BitLocker recovery password when you turned on BitLocker, your TPM owner password may have printed with it. + + >**Note:**  If you enabled BitLocker and your TPM at the same time, and you printed your BitLocker recovery password when you turned on BitLocker, your TPM owner password may have printed with it.   ## Use Group Policy to manage TPM lockout settings + The TPM Group Policy settings in the following list are located at: + **Computer Configuration\\Administrative Templates\\System\\Trusted Platform Module Services\\** + - [Standard User Lockout Duration](trusted-platform-module-services-group-policy-settings.md#bkmk-individual) + This policy setting allows you to manage the duration in minutes for counting standard user authorization failures for TPM commands that require authorization. An authorization failure occurs each time a user sends a command to the TPM and receives an error message that indicates an authorization failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM commands with an authorization failure within the lockout duration equals a threshold, the user is prevented from sending commands to the TPM that require authorization. + - [Standard User Individual Lockout Threshold](trusted-platform-module-services-group-policy-settings.md#bkmk-tpmgp-suld) + This policy setting allows you to manage the maximum number of authorization failures for the TPM for each user. This value is the maximum number of authorization failures that each user can have before the user is not allowed to send commands to the TPM that require authorization. If the number of authorization failures equals the duration that is set for the policy setting, the user is prevented from sending commands to the TPM that require authorization. + - [Standard User Total Lockout Threshold](trusted-platform-module-services-group-policy-settings.md#bkmk-total) + This policy setting allows you to manage the maximum number of authorization failures for the TPM for all standard users. If the total number of authorization failures for all users equals the duration that is set for the policy, all users are prevented from sending commands to the TPM that require authorization. + For information about mitigating dictionary attacks that use the lockout settings, see [TPM fundamentals](tpm-fundamentals.md#bkmk-howtpmmitigates). + ## 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** + 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 [TPM technology overview](trusted-platform-module-overview.md#bkmk-additionalresources). -  -  + +For more info about TPM, see [TPM technology overview](trusted-platform-module-overview.md#bkmk-additionalresources). \ No newline at end of file