Merge pull request #6756 from MicrosoftDocs/v-smandalika-5694287-B16

windows - v-smandalika-5694287 - Acrolinx

windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md

@@ -28,7 +28,7 @@ This article discusses different methods to administer security policy settings
 
 Security policy settings should be used as part of your overall security implementation to help secure domain controllers, servers, client devices, and other resources in your organization.
 
-Security settings policies are rules that you can configure on a device, or multiple devices, for the purpose of protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in (Gpedit.msc) allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, and organizational units, and they enable administrators to manage security settings for multiple computers from any device joined to the domain.
+Security settings policies are rules that you can configure on a device, or multiple devices, for protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in (Gpedit.msc) allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, and organizational units, and they enable administrators to manage security settings for multiple computers from any device joined to the domain.
 
 Security settings can control:
 
@@ -83,10 +83,10 @@ The secedit command-line tool works with security templates and provides six pri
 
 - The **Configure** parameter helps you resolve security discrepancies between devices by applying the correct security template to the errant server.
 - The **Analyze** parameter compares the server's security configuration with the selected template.
-- The **Import** parameter allows you to create a database from an existing template. The Security Configuration and Analysis tool does this also.
+- The **Import** parameter allows you to create a database from an existing template. The Security Configuration and Analysis tool does this cloning also.
 - The **Export** parameter allows you to export the settings from a database into a security settings template.
-- The **Validate** parameter allows you to validate the syntax of each or any lines of text that you created or added to a security template. This ensures that if the template fails to apply syntax, the template will not be the issue.
-- The **Generate Rollback** parameter saves the server's current security settings into a security template so it can be used to restore most of the server's security settings to a known state. The exceptions are that, when applied, the rollback template will not change access control list entries on files or registry entries that were changed by the most recently applied template.
+- The **Validate** parameter allows you to validate the syntax of each or any lines of text that you created or added to a security template. This validation ensures that if the template fails to apply syntax, the template won't be the issue.
+- The **Generate Rollback** parameter saves the server's current security settings into a security template so it can be used to restore most of the server's security settings to a known state. The exceptions are that, when applied, the rollback template won't change access control list entries on files or registry entries that were changed by the most recently applied template.
 
 ## <a href="" id="bkmk-scm"></a>Using the Security Compliance Manager
 
@@ -107,9 +107,9 @@ SCW is a role-based tool: You can use it to create a policy that enables service
 The following are considerations for using SCW:
 
 - SCW disables unnecessary services and provides Windows Firewall with Advanced Security support.
-- Security policies that are created with SCW are not the same as security templates, which are files with an .inf extension. Security templates contain more security settings than those that can be set with SCW. However, it is possible to include a security template in an SCW security policy file.
+- Security policies that are created with SCW aren't the same as security templates, which are files with an .inf extension. Security templates contain more security settings than those settings that can be set with SCW. However, it's possible to include a security template in an SCW security policy file.
 - You can deploy security policies that you create with SCW by using Group Policy.
-- SCW does not install or uninstall the features necessary for the server to perform a role. You can install server role-specific features through Server Manager.
+- SCW doesn't install or uninstall the features necessary for the server to perform a role. You can install server role-specific features through Server Manager.
 - SCW detects server role dependencies. If you select a server role, it automatically selects dependent server roles.
 - All apps that use the IP protocol and ports must be running on the server when you run SCW.
 - In some cases, you must be connected to the Internet to use the links in the SCW help.
@@ -149,20 +149,19 @@ Security Configuration and Analysis is an MMC snap-in for analyzing and configur
 
 ### <a href="" id="h2-359808543"></a>Security analysis
 
-The state of the operating system and apps on a device is dynamic. For example, you may need to temporarily change security levels so that you can immediately resolve an administration or network issue. However, this change can often go unreversed. This means that a computer may no longer meet the requirements for enterprise security.
+The state of the operating system and apps on a device is dynamic. For example, you may need to temporarily change security levels so that you can immediately resolve an administration or network issue. However, this change can often go unreversed. This unreversed state of the changes means that a computer may no longer meet the requirements for enterprise security.
 
 Regular analysis enables you to track and ensure an adequate level of security on each computer as part of an enterprise risk management program. You can tune the security levels and, most importantly, detect any security flaws that may occur in the system over time.
 
-Security Configuration and Analysis enables you to quickly review security analysis results. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings do not match the proposed level of security. Security
-Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals.
+Security Configuration and Analysis enables you to quickly review security analysis results. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings don't match the proposed level of security. Security Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals.
 
 ### <a href="" id="h2-359810173"></a>Security configuration
 
-Security Configuration and Analysis can also be used to directly configure local system security. Through its use of personal databases, you can import security templates that have been created with Security Templates and apply these templates to the local computer. This immediately configures the system security with the levels specified in the template.
+Security Configuration and Analysis can also be used to directly configure local system security. Through its use of personal databases, you can import security templates that have been created with Security Templates and apply these templates to the local computer. These security templates immediately configure the system security with the levels specified in the template.
 
 ### <a href="" id="bkmk-sectmpl"></a>Security templates
 
-With the Security Templates snap-in for Microsoft Management Console, you can create a security policy for your device or for your network. It is a single point of entry where the full range of system security can be taken into account. The Security Templates snap-in does not introduce new security parameters, it simply organizes all existing security attributes into one place to ease security administration.
+With the Security Templates snap-in for Microsoft Management Console, you can create a security policy for your device or for your network. It's a single point of entry where the full range of system security can be taken into account. The Security Templates snap-in doesn't introduce new security parameters, it simply organizes all existing security attributes into one place to ease security administration.
 
 Importing a security template to a Group Policy Object eases domain administration by configuring security for a domain or organizational unit at once.
 
@@ -184,18 +183,18 @@ Security templates can be used to define:
 - Registry: Permissions for registry keys
 - File System: Permissions for folders and files
 
-Each template is saved as a text-based .inf file. This enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes can be contained in a security template.
+Each template is saved as a text-based .inf file. This file enables you to copy, paste, import, or export some or all of the template attributes. With the exceptions of Internet Protocol security and public key policies, all security attributes can be contained in a security template.
 
 ### <a href="" id="bkmk-secextensions"></a>Security settings extension to Group Policy
 
-Organizational units, domains, and sites are linked to Group Policy Objects. The security settings tool allows you change the security configuration of the Group Policy Object, in turn, affecting multiple computers. With security settings, you can modify the security settings of many devices, depending on the Group Policy Object you modify, from just one device joined to a domain.
+Organizational units, domains, and sites are linked to Group Policy Objects. The security settings tool allows you to change the security configuration of the Group Policy Object, in turn, affecting multiple computers. With security settings, you can modify the security settings of many devices, depending on the Group Policy Object you modify, from just one device joined to a domain.
 
-Security settings or security policies are rules that are configured on a device or multiple device for protecting resources on a device or network. Security settings can control:
+Security settings or security policies are rules that are configured on a device or multiple devices for protecting resources on a device or network. Security settings can control:
 
 - How users are authenticated to a network or device
-- What resources users are authorized to use.
-- Whether or not a user's or group's actions are recorded in the event log.
-- Group membership.
+- What resources users are authorized to use
+- Whether or not a user's or group's actions are recorded in the event log
+- Group membership
 
 You can change the security configuration on multiple computers in two ways:
 
@@ -208,18 +207,18 @@ A security policy is a combination of security settings that affect the security
 
 With the local security policy, you can control:
 
-- Who accesses your device.
-- What resources users are authorized to use on your device.
-- Whether or not a user's or group's actions are recorded in the event log.
+- Who accesses your device
+- What resources users are authorized to use on your device
+- Whether or not a user's or group's actions are recorded in the event log
 
-If your local device is joined to a domain, you are subject to obtaining a security policy from the domain's policy or from the policy of any organizational unit that you are a member of. If you are getting a policy from more than one source, conflicts are resolved in the following order of precedence.
+If your local device is joined to a domain, you're subject to obtaining a security policy from the domain's policy or from the policy of any organizational unit that you're a member of. If you're getting a policy from more than one source, conflicts are resolved in the following order of precedence.
 
 1. Organizational unit policy
 1. Domain policy
 1. Site policy
 1. Local computer policy
 
-If you modify the security settings on your local device by using the local security policy, then you are directly modifying the settings on your device. Therefore, the settings take effect immediately, but this may only be temporary. The settings will actually remain in effect on your local device until the next refresh of Group Policy security settings, when the security settings that are received from Group Policy will override your local settings wherever there are conflicts.
+If you modify the security settings on your local device by using the local security policy, then you're directly modifying the settings on your device. Therefore, the settings take effect immediately, but this effect may only be temporary. The settings will actually remain in effect on your local device until the next refresh of Group Policy security settings, when the security settings that are received from Group Policy will override your local settings wherever there are conflicts.
 
 ### Using the Security Configuration Manager
 
@@ -233,10 +232,10 @@ For procedures on how to use the Security Configuration Manager, see [Security C
 
 ### <a href="" id="bkmk-applysecsettings"></a>Applying security settings
 
-Once you have edited the security settings, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object:
+Once you've edited the security settings, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object:
 
 - When a device is restarted, the settings on that device will be refreshed.
-- To force a device to refresh its security settings as well as all Group Policy settings, use gpupdate.exe.
+- To force a device to refresh its security settings and all Group Policy settings, use gpupdate.exe.
 
 **Precedence of a policy when more than one policy is applied to a computer**
 
@@ -247,7 +246,7 @@ For security settings that are defined by more than one policy, the following or
 1. Site Policy
 1. Local computer Policy
 
-For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there is a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override
+For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there's a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override
 both the domain and local settings. If the workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately contains the workstation has the highest order of precedence.
 
 > [!NOTE]
@@ -260,23 +259,23 @@ Security settings may still persist even if a setting is no longer defined in th
 
 Persistence in security settings occurs when:
 
-- The setting has not been previously defined for the device.
+- The setting hasn't been previously defined for the device.
 - The setting is for a registry object.
 - The setting is for a file system object.
 
-All settings applied through local policy or a Group Policy Object are stored in a local database on your device. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the device. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database, then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."
+All settings applied through local policy or a Group Policy Object are stored in a local database on your device. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the device. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value doesn't exist in the database, then the setting doesn't revert to anything and remains defined as is. This behavior is sometimes called "tattooing."
 
 Registry and file settings will maintain the values applied through policy until that setting is set to other values.
 
 **Filtering security settings based on group membership**
 
-You can also decide what users or groups will or will not have a Group Policy Object applied to them regardless of what computer they have logged onto by denying them either the Apply Group Policy or Read permission on that Group Policy Object. Both of these permissions are needed to apply Group Policy.
+You can also decide what users or groups will or won't have a Group Policy Object applied to them regardless of what computer they've signed into by denying them either the Apply Group Policy or Read permission on that Group Policy Object. Both of these permissions are needed to apply Group Policy.
 
 ### <a href="" id="bkmk-impexpsectmpl"></a>Importing and exporting security templates
 
-Security Configuration and Analysis provides the ability to import and export security templates into or from a database.
+Security Configuration and Analysis enables import and export of security templates into or from a database.
 
-If you have made any changes to the analysis database, you can save those settings by exporting them into a template. The export feature provides the ability to save the analysis database settings as a new template file. This template file can then be used to analyze or configure a system, or it can be imported to a Group Policy Object.
+If you have made any changes to the analysis database, you can save those settings by exporting them into a template. The export feature enables saving the analysis database settings as a new template file. This template file can then be used to analyze or configure a system, or it can be imported to a Group Policy Object.
 
 ### <a href="" id="bkmk-anasecviewresults"></a>Analyzing security and viewing results
 
@@ -286,26 +285,26 @@ Security Configuration and Analysis displays the analysis results by security ar
 
 |Visual flag  |Meaning  |
 |---------|---------|
-|Red X |The entry is defined in the analysis database and on the system, but the security setting values do not match.|
+|Red X |The entry is defined in the analysis database and on the system, but the security setting values don't match.|
 |Green check mark |The entry is defined in the analysis database and on the system and the setting values match.|
-|Question mark |The entry is not defined in the analysis database and, therefore, was not analyzed. <br> If an entry is not analyzed, it may be that it was not defined in the analysis database or that the user who is running the analysis may not have sufficient permission to perform analysis on a specific object or area.|
-|Exclamation point |This item is defined in the analysis database, but does not exist on the actual system. For example, there may be a restricted group that is defined in the analysis database but does not actually exist on the analyzed system.|
-|No highlight |The item is not defined in the analysis database or on the system.|
+|Question mark |The entry isn't defined in the analysis database and, therefore, wasn't analyzed. <br> If an entry isn't analyzed, it may be that it wasn't defined in the analysis database or that the user who is running the analysis may not have sufficient permission to perform analysis on a specific object or area.|
+|Exclamation point |This item is defined in the analysis database, but doesn't exist on the actual system. For example, there may be a restricted group that is defined in the analysis database but doesn't actually exist on the analyzed system.|
+|No highlight |The item isn't defined in the analysis database or on the system.|
 
 If you choose to accept the current settings, the corresponding value in the base configuration is modified to match them. If you change the system setting to match the base configuration, the change will be reflected when you configure the system with Security Configuration and Analysis.
 
-To avoid continued flagging of settings that you have investigated and determined to be reasonable, you can modify the base configuration. The changes are made to a copy of the template.
+To avoid continued flagging of settings that you've investigated and determined to be reasonable, you can modify the base configuration. The changes are made to a copy of the template.
 
 ### <a href="" id="bkmk-resolvesecdiffs"></a>Resolving security discrepancies
 
 You can resolve discrepancies between analysis database and system settings by:
 
 - Accepting or changing some or all of the values that are flagged or not included in the configuration, if you determine that the local system security levels are valid due to the context (or role) of that computer. These attribute values are then updated in the database and applied to the system when you click **Configure Computer Now**.
-- Configuring the system to the analysis database values, if you determine the system is not in compliance with valid security levels.  
+- Configuring the system to the analysis database values, if you determine the system isn't in compliance with valid security levels.  
 - Importing a more appropriate template for the role of that computer into the database as the new base configuration and applying it to the system.  
 Changes to the analysis database are made to the stored template in the database, not to the security template file. The security template file will only be modified if you either return to Security Templates and edit that template or export the stored configuration to the same template file.  
 You should use **Configure Computer Now** only to modify security areas *not* affected by Group Policy settings, such as security on local files and folders, registry keys, and system services. Otherwise, when the Group Policy settings are applied, it will take precedence over local settings—such as account policies.  
-In general, do not use **Configure Computer Now** when you are analyzing security for domain-based clients, since you will have to configure each client individually. In this case, you should return to Security Templates, modify the template, and reapply it to the appropriate Group Policy Object.
+In general, don't use **Configure Computer Now** when you're analyzing security for domain-based clients, since you'll have to configure each client individually. In this case, you should return to Security Templates, modify the template, and reapply it to the appropriate Group Policy Object.
 
 ### <a href="" id="bkmk-autoseccfgtasks"></a>Automating security configuration tasks
 

windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md

@@ -1,6 +1,6 @@
 ---
 title: Allow log on through Remote Desktop Services (Windows 10)
-description: Best practices, location, values, policy management, and security considerations for the security policy setting, Allow log on through Remote Desktop Services.
+description: Best practices, location, values, policy management, and security considerations for the security policy setting. Allow a sign-in through Remote Desktop Services.
 ms.assetid: 6267c376-8199-4f2b-ae56-9c5424e76798
 ms.reviewer: 
 ms.author: dansimp
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-This policy setting determines which users or groups can access the logon screen of a remote device through a Remote Desktop Services connection. It is possible for a user to establish a Remote Desktop Services connection to a particular server but not be able to log on to the console of that same server.
+This policy setting determines which users or groups can access the sign-in screen of a remote device through a Remote Desktop Services connection. It's possible for a user to establish a Remote Desktop Services connection to a particular server but not be able to sign in to the console of that same server.
 
 Constant: SeRemoteInteractiveLogonRight
 
@@ -38,7 +38,7 @@ Constant: SeRemoteInteractiveLogonRight
 
 ### Best practices
 
--   To control who can open a Remote Desktop Services connection and log on to the device, add users to or remove users from the Remote Desktop Users group.
+-   To control who can open a Remote Desktop Services connection and sign in to the device, add users to or remove users from the Remote Desktop Users group.
 
 ### Location
 
@@ -66,13 +66,13 @@ This section describes different features and tools available to help you manage
 
 ### Group Policy
 
-To use Remote Desktop Services to successfully log on to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the **Allow log on through Remote Desktop Services** right. It is possible for a user to establish an Remote Desktop Services session to a particular server, but not be able to log on to the console of that same server.
+To use Remote Desktop Services to successfully sign in to a remote device, the user or group must be a member of the Remote Desktop Users or Administrators group and be granted the **Allow log on through Remote Desktop Services** right. It's possible for a user to establish a Remote Desktop Services session to a particular server, but not be able to sign in to the console of that same server.
 
 To exclude users or groups, you can assign the **Deny log on through Remote Desktop Services** user right to those users or groups. However, be careful when you use this method because you could create conflicts for legitimate users or groups that have been allowed access through the **Allow log on through Remote Desktop Services** user right.
 
 For more information, see [Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md).
 
-A restart of the device is not required for this policy setting to be effective.
+A restart of the device isn't 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.
 
@@ -89,11 +89,11 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-Any account with the **Allow log on through Remote Desktop Services** user right can log on to the remote console of the device. If you do not restrict this user right to legitimate users who must log on to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.
+Any account with the **Allow log on through Remote Desktop Services** user right can sign in to the remote console of the device. If you don't restrict this user right to legitimate users who must sign in to the console of the computer, unauthorized users could download and run malicious software to elevate their privileges.
 
 ### Countermeasure
 
-For domain controllers, assign the **Allow log on through Remote Desktop Services** user right only to the Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that have the Remote Desktop (RD) Session Host role service enabled and do not run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to these groups.
+For domain controllers, assign the **Allow log on through Remote Desktop Services** user right only to the Administrators group. For other server roles and devices, add the Remote Desktop Users group. For servers that have the Remote Desktop (RD) Session Host role service enabled and don't run in Application Server mode, ensure that only authorized IT personnel who must manage the computers remotely belong to these groups.
 
 > **Caution:**  For RD Session Host servers that run in Application Server mode, ensure that only users who require access to the server have accounts that belong to the Remote Desktop Users group because this built-in group has this logon right by default.
  
@@ -101,7 +101,7 @@ Alternatively, you can assign the **Deny log on through Remote Desktop Services*
 
 ### Potential impact
 
-Removal of the **Allow log on through Remote Desktop Services** user right from other groups (or membership changes in these default groups) could limit the abilities of users who perform specific administrative roles in your environment. You should confirm that delegated activities are not adversely affected.
+Removal of the **Allow log on through Remote Desktop Services** user right from other groups (or membership changes in these default groups) could limit the abilities of users who perform specific administrative roles in your environment. You should confirm that delegated activities aren't adversely affected.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md

@@ -62,11 +62,11 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy.
 
 ### Auditing
 
-Enabling this policy setting in conjunction with the **Audit privilege use** policy setting records any instance of user rights that are being exercised in the security log. If **Audit privilege use** is enabled but **Audit: Audit the use of Backup and Restore privilege** is disabled, when users back up or restore user rights, those events will not be audited.
+Enabling this policy setting in conjunction with the **Audit privilege use** policy setting records any instance of user rights that are being exercised in the security log. If **Audit privilege use** is enabled but **Audit: Audit the use of Backup and Restore privilege** is disabled, when users back up or restore user rights, those events won't be audited.
 
 Enabling this policy setting when the **Audit privilege use** policy setting is also enabled generates an audit event for every file that is backed up or restored. This setup can help you to track down an administrator who is accidentally or maliciously restoring data in an unauthorized manner.
 

windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md

@@ -38,7 +38,7 @@ There are over 40 auditing subcategories that provide precise details about acti
 
 ### Best practices
 
--   Leave the setting enabled. This provides the ability to audit events at the category level without revising a policy.
+-   Leave the setting enabled. This "enabled" state helps audit events at the category level without revising a policy.
 
 ### Location
 
@@ -63,7 +63,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
@@ -71,9 +71,9 @@ All auditing capabilities are integrated in Group Policy. You can configure, dep
 
 ### Auditing
 
-To manage an audit policy by using subcategories without requiring a change to Group Policy, the SCENoApplyLegacyAuditPolicy registry value , prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.
+To manage an audit policy by using subcategories without requiring a change to Group Policy, the SCENoApplyLegacyAuditPolicy registry value prevents the application of category-level audit policy from Group Policy and from the Local Security Policy administrative tool.
 
-If the category level audit policy that is set here is not consistent with the events that are currently being generated, the cause might be that this registry key is set.
+If the category level audit policy that is set here isn't consistent with the events that are currently being generated, the cause might be that this registry key is set.
 
 ### Command-line tools
 

windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md

@@ -27,13 +27,13 @@ Describes the best practices, location, values, management practices, and securi
 
 ## Reference
 
-The **Audit: Shut down system immediately if unable to log security audits** policy setting determines whether the system shuts down if it is unable to log security events. This policy setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a Stop message in the case of a failure of the auditing system. Enabling this policy setting stops the system if a security audit cannot be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the value of **Retention method for security log** is **Do not overwrite events (clear log manually)** or **Overwrite events by days**.
+The **Audit: Shut down system immediately if unable to log security audits** policy setting determines whether the system shuts down if it's unable to log security events. This policy setting is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log those events. Microsoft has chosen to meet this requirement by halting the system and displaying a Stop message if there's a failure of the auditing system. Enabling this policy setting stops the system if a security audit can't be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the value of **Retention method for security log** is **Do not overwrite events (clear log manually)** or **Overwrite events by days**.
 
-With **Audit: Shut down system immediately if unable to log security audits** set to **Enabled**, if the security log is full and an existing entry cannot be overwritten, the following Stop message appears:
+With **Audit: Shut down system immediately if unable to log security audits** set to **Enabled**, if the security log is full and an existing entry can't be overwritten, the following Stop message appears:
 
 **STOP: C0000244 {Audit Failed}**: An attempt to generate a security audit failed.
 
-To recover, you must log on, archive the log (optional), clear the log, and reset this option as desired.
+To recover, you must sign in, archive the log (optional), clear the log, and reset this option as desired.
 
 If the computer is unable to record events to the security log, critical evidence or important troubleshooting information might not be available for review after a security incident.
 
@@ -67,11 +67,11 @@ The following table lists the actual and effective default values for this polic
 ## Policy management
 
 This section describes features and tools that are available to help you manage this policy.
-The administrative burden of enabling this policy setting can be very high, especially if you also set the **Retention method for security log** to **Do not overwrite events (clear log manually)**. This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be forced to shut down if it is overwhelmed with logon events and other security events that are written to the security log. Additionally, because the shutdown is not graceful, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system will guarantee that the file system's integrity will be maintained during a sudden system shutdown, it cannot guarantee that every data file for every application will still be in a usable form when the system is restarted.
+The administrative burden of enabling this policy setting can be high, especially if you also set the **Retention method for security log** to **Do not overwrite events (clear log manually)**. This setting turns a repudiation threat (a backup operator could deny that they backed up or restored data) into a denial-of-service threat, because a server can be forced to shut down if it's overwhelmed with sign-in events and other security events that are written to the security log. Additionally, because the shutdown isn't graceful, it's possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system will guarantee that the file system's integrity will be maintained during a sudden system shutdown, it can't guarantee that every data file for every application will still be in a usable form when the system is restarted.
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
@@ -91,7 +91,7 @@ Enable the **Audit: Shut down system immediately if unable to log security audit
 
 ### Potential impact
 
-If you enable this policy setting, the administrative burden can be significant, especially if you also configure the **Retention method for the Security log** to **Do not overwrite events** (clear log manually). This configuration causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a denial of service (DoS) vulnerability because a server could be forced to shut down if it is overwhelmed with logon events and other security events that are written to the security event log. Also, because the shutdown is abrupt, it is possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system maintains its integrity when this type of computer shutdown occurs, there is no guarantee that every data file for every application will still be in a usable form when the device restarts.
+If you enable this policy setting, the administrative burden can be significant, especially if you also configure the **Retention method for the Security log** to **Do not overwrite events** (clear log manually). This configuration causes a repudiation threat (a backup operator could deny that they backed up or restored data) to become a denial of service (DoS) vulnerability because a server could be forced to shut down if it's overwhelmed with sign-in events and other security events that are written to the security event log. Also, because the shutdown is abrupt, it's possible that irreparable damage to the operating system, applications, or data could result. Although the NTFS file system maintains its integrity when this type of computer shutdown occurs, there's no guarantee that every data file for every application will still be in a usable form when the device restarts.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md

@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-This policy setting determines which users (or a process that acts on behalf of the user’s account) have permission to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder special access permission. This user right does not allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders.
+This policy setting determines which users (or a process that acts on behalf of the user’s account) have permission to navigate an object path in the NTFS file system or in the registry without being checked for the Traverse Folder special access permission. This user right doesn't allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders.
 
 Constant: SeChangeNotifyPrivilege
 
@@ -40,7 +40,7 @@ Constant: SeChangeNotifyPrivilege
 
 ### Best practices
 
-1.  Use access–based enumeration when you want to prevent users from seeing any folder or file to which they do not have access.
+1.  Use access–based enumeration when you want to prevent users from seeing any folder or file to which they don't have access.
 2.  Use the default settings of this policy in most cases. If you change the settings, verify your intent through testing.
 
 ### Location
@@ -62,9 +62,9 @@ The following table lists the actual and effective default policy values. Defaul
  
 ## Policy management
 
-Permissions to files and folders are controlled though the appropriate configuration of file system access control lists (ACLs).The ability to traverse the folder does not provide any Read or Write permissions to the user.
+Permissions to files and folders are controlled through the appropriate configuration of file system access control lists (ACLs). The ability to traverse the folder doesn't provide any Read or Write permissions to the user.
 
-A restart of the computer is not required for this policy setting to be effective.
+A restart of the computer isn't 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.
 
@@ -85,11 +85,11 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-The default configuration for the **Bypass traverse checking** setting is to allow all users to bypass traverse checking. Permissions to files and folders are controlled though the appropriate configuration of file system access control lists (ACLs) because the ability to traverse the folder does not provide any Read or Write permissions to the user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who configures permissions does not understand how this policy setting works. For example, the administrator might expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a situation is unlikely, and, therefore, this vulnerability presents little risk.
+The default configuration for the **Bypass traverse checking** setting is to allow all users to bypass traverse checking. Permissions to files and folders are controlled through the appropriate configuration of file system access control lists (ACLs) because the ability to traverse the folder doesn't provide any Read or Write permissions to the user. The only scenario in which the default configuration could lead to a mishap would be if the administrator who configures permissions doesn't understand how this policy setting works. For example, the administrator might expect that users who are unable to access a folder are unable to access the contents of any child folders. Such a situation is unlikely, and, therefore, this vulnerability presents little risk.
 
 ### Countermeasure
 
-Organizations that are extremely concerned about security may want to remove the Everyone group, and perhaps the Users group, from the list of groups that have the **Bypass traverse checking** user right. Taking explicit control over traversal assignments can be an effective way to limit access to sensitive information. Access–based enumeration can also be used. If you use access–based enumeration, users cannot see any folder or file to which they do not have access. For more info about this feature, see [Access-based Enumeration](/previous-versions/windows/it-pro/windows-server-2003/cc784710(v=ws.10)).
+Organizations that are concerned about security may want to remove the Everyone group, and perhaps the Users group, from the list of groups that have the **Bypass traverse checking** user right. Taking explicit control over traversal assignments can be an effective way to limit access to sensitive information. Access–based enumeration can also be used. If you use access–based enumeration, users can't see any folder or file to which they don't have access. For more info about this feature, see [Access-based Enumeration](/previous-versions/windows/it-pro/windows-server-2003/cc784710(v=ws.10)).
 
 ### Potential impact
 

windows/security/threat-protection/security-policy-settings/change-the-system-time.md

@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-This policy setting determines which users can adjust the time on the device's internal clock. This right allows the computer user to change the date and time associated with records in the event logs, database transactions, and the file system. This right is also required by the process that performs time synchronization. This setting does not impact the user’s ability to change the time zone or other display characteristics of the system time. For info about assigning the right to change the time zone, see [Change the time zone](change-the-time-zone.md).
+This policy setting determines which users can adjust the time on the device's internal clock. This right allows the computer user to change the date and time associated with records in the event logs, database transactions, and the file system. This right is also required by the process that performs time synchronization. This setting doesn't impact the user’s ability to change the time zone or other display characteristics of the system time. For info about assigning the right to change the time zone, see [Change the time zone](change-the-time-zone.md).
 
 Constant: SeSystemtimePrivilege
 
@@ -63,7 +63,7 @@ The following table lists the actual and effective default policy values. Defaul
 
 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.
+A restart of the device isn't 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.
 
@@ -89,7 +89,7 @@ Users who can change the time on a computer could cause several problems. For ex
 -   Time stamps on event log entries could be made inaccurate
 -   Time stamps on files and folders that are created or modified could be incorrect
 -   Computers that belong to a domain might not be able to authenticate themselves
--   Users who try to log on to the domain from devices with inaccurate time might not be able to authenticate.
+-   Users who try to sign in to the domain from devices with inaccurate time might not be able to authenticate.
 
 Also, because the Kerberos authentication protocol requires that the requester and authenticator have their clocks synchronized within an administrator-defined skew period, an attacker who changes a device's time may cause that computer to be unable to obtain or grant Kerberos protocol tickets.
 
@@ -100,7 +100,7 @@ The risk from these types of events is mitigated on most domain controllers, mem
 -   All PDC emulator operations masters follow the hierarchy of domains in the selection of their inbound time partner.
 -   The PDC emulator operations master at the root of the domain is authoritative for the organization. Therefore, we recommend that you configure this computer to synchronize with a reliable external time server.
 
-This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the Windows Time Service or reconfigure it to synchronize with a time server that is not accurate.
+This vulnerability becomes much more serious if an attacker is able to change the system time and then stop the Windows Time Service or reconfigure it to synchronize with a time server that isn't accurate.
 
 ### Countermeasure
 
@@ -108,7 +108,7 @@ Restrict the **Change the system time** user right to users with a legitimate ne
 
 ### Potential impact
 
-There should be no impact because time synchronization for most organizations should be fully automated for all computers that belong to the domain. Computers that do not belong to the domain should be configured to synchronize with an external source, such as a web service.
+There should be no impact because time synchronization for most organizations should be fully automated for all computers that belong to the domain. Computers that don't belong to the domain should be configured to synchronize with an external source, such as a web service.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/create-a-pagefile.md

@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-Windows designates a section of the hard drive as virtual memory known as the page file, or more specifically, as pagefile.sys. It is used to supplement the computer’s Random Access Memory (RAM) to improve performance for frequently used programs and data. Although the file is hidden from browsing, you can manage it using the system settings.
+Windows designates a section of the hard drive as virtual memory known as the page file, or more specifically, as pagefile.sys. It's used to supplement the computer’s Random Access Memory (RAM) to improve performance for frequently used programs and data. Although the file is hidden from browsing, you can manage it using the system settings.
 
 This policy setting determines which users can create and change the size of a page file. It determines whether users can specify a page file size for a particular drive in the **Performance Options** box located on the **Advanced** tab of the **System Properties** dialog box or through using internal application interfaces (APIs).
 
@@ -63,7 +63,7 @@ The following table lists the actual and effective default policy values for the
  
 ## Policy management
 
-A restart of the device is not required for this policy setting to be effective.
+A restart of the device isn't 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.
 
@@ -84,7 +84,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-Users who can change the page file size could make it extremely small or move the file to a highly fragmented storage volume, which could cause reduced device performance.
+Users who can change the page file size could make it small or move the file to a highly fragmented storage volume, which could cause reduced device performance.
 
 ### Countermeasure
 

windows/security/threat-protection/security-policy-settings/create-a-token-object.md

@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
 
 This policy setting determines which accounts a process can use to create a token, and which accounts it can then use to gain access to local resources when the process uses NtCreateToken() or other token-creation APIs.
 
-When a user logs on to the local device or connects to a remote device through a network, Windows builds the user’s access token. Then the system examines the token to determine the level of the user's privileges. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects.
+When a user signs in to the local device or connects to a remote device through a network, Windows builds the user’s access token. Then the system examines the token to determine the level of the user's privileges. When you revoke a privilege, the change is immediately recorded, but the change isn't reflected in the user's access token until the next time the user logs on or connects.
 
 Constant: SeCreateTokenPrivilege
 
@@ -40,7 +40,7 @@ Constant: SeCreateTokenPrivilege
 
 ### Best practices
 
--   This user right is used internally by the operating system. Unless it is necessary, do not assign this user right to a user, group, or process other than Local System.
+-   This user right is used internally by the operating system. Unless it's necessary, don't assign this user right to a user, group, or process other than Local System.
 
 ### Location
 
@@ -48,7 +48,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
 
 ### Default values
 
-This user right is used internally by the operating system. By default, it is not assigned to any user groups.
+This user right is used internally by the operating system. By default, it isn't assigned to any user groups.
 
 The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
 
@@ -63,7 +63,7 @@ The following table lists the actual and effective default policy values. Defaul
  
 ## Policy management
 
-A restart of the device is not required for this policy setting to be effective.
+A restart of the device isn't 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.
 
@@ -86,11 +86,11 @@ This section describes how an attacker might exploit a feature or its configurat
 
 >**Caution:**  A user account that is given this user right has complete control over the system, and it can lead to the system being compromised. We highly recommend that you do not assign this right to any user accounts.
  
-Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users log on to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any account on a computer if they are currently logged on. They could escalate their privileges or create a DoS condition.
+Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users sign in to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change isn't reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any account on a computer if they're currently logged on. They could escalate their privileges or create a DoS condition.
 
 ### Countermeasure
 
-Do not assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account that has this user right assigned.
+Don't assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account that has this user right assigned.
 
 ### Potential impact
 

windows/security/threat-protection/security-policy-settings/create-global-objects.md

@@ -27,9 +27,9 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they do not have this user right.
+This policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they don't have this user right.
 
-A global object is an object that is created to be used by any number of processes or threads, even those not started within the user’s session. Remote Desktop Services uses global objects in its processes to facilitate connections and access.
+A global object is an object that can be used by any number of processes or threads, even those processes or threads not started within the user’s session. Remote Desktop Services uses global objects in its processes to facilitate connections and access.
 
 Constant: SeCreateGlobalPrivilege
 
@@ -40,7 +40,7 @@ Constant: SeCreateGlobalPrivilege
 
 ### Best practices
 
--   Do not assign any user accounts this right.
+-   Don't assign any user accounts this right.
 
 ### Location
 
@@ -63,7 +63,7 @@ The following table lists the actual and effective default policy values. Defaul
  
 ## Policy management
 
-A restart of the device is not required for this policy setting to take effect.
+A restart of the device isn't required for this policy setting to take effect.
 
 Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
 
@@ -90,7 +90,7 @@ By default, members of the **Administrators** group, the System account, and ser
 
 ### Countermeasure
 
-When non-administrators need to access a server using Remote Desktop, add the users to the **Remote Desktop Users** group rather than assining them this user right.
+When non-administrators need to access a server using Remote Desktop, add the users to the **Remote Desktop Users** group rather than assigning them this user right.
 
 ### Potential impact
 

windows/security/threat-protection/security-policy-settings/create-symbolic-links.md

@@ -27,9 +27,9 @@ Describes the best practices, location, values, policy management, and security
 
 ## Reference
 
-This user right determines if users can create a symbolic link from the device they are logged on to.
+This user right determines if users can create a symbolic link from the device they're logged on to.
 
-A symbolic link is a file-system object that points to another file-system object. The object that's pointed to is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links.
+A symbolic link is a file-system object that points to another file-system object that is called the target. Symbolic links are transparent to users. The links appear as normal files or directories, and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links.
 
 >**Warning:**   This privilege should only be given to trusted users. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them.
 Constant: SeCreateSymbolicLinkPrivilege
@@ -41,7 +41,7 @@ Constant: SeCreateSymbolicLinkPrivilege
 
 ### Best practices
 
--   Only trusted users should get this user right. Symbolic links can expose security vulnerabilities in applications that are not designed to handle them.
+-   Only trusted users should get this user right. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them.
 
 ### Location
 
@@ -66,7 +66,7 @@ The following table lists the actual and effective default policy values. Defaul
 
 This section describes different 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.
+A restart of the device isn't 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.
 
@@ -95,7 +95,7 @@ Users who have the **Create symbolic links** user right could inadvertently or m
 
 ### Countermeasure
 
-Do not assign the **Create symbolic links** user right to standard users. Restrict this right to trusted administrators. You can use the **fsutil** command to establish a symbolic link file system setting that controls the kind of symbolic links that can be created on a computer.
+Don't assign the **Create symbolic links** user right to standard users. Restrict this right to trusted administrators. You can use the **fsutil** command to establish a symbolic link file system setting that controls the kind of symbolic links that can be created on a computer.
 
 ### Potential impact
 

windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md

@@ -27,13 +27,13 @@ Describes the best practices, location, values, and security considerations for
 
 ## 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.
+This policy setting allows you to define other 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 extra 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.
+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're running.
 
 ### Possible values
 
@@ -43,7 +43,7 @@ This policy setting allows you to specify an ACL in two different ways. You can
 
 -   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.
+    This value 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
 
@@ -67,14 +67,14 @@ The following table lists the actual and effective default values for this polic
 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.
+None. Changes to this policy become effective without a computer restart when they're 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.
+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 precedence means that previously existing registry settings are no longer effective, and if you make changes to the existing settings, device access permissions for users aren't 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 setting will restore control of the DCOM application to the administrator and users. To define this setting, 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 information defines the setting and sets the appropriate SDDL value.
 
 ## Security considerations
 
@@ -82,7 +82,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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.
+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 can't 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.
 
@@ -92,7 +92,7 @@ To protect individual COM-based applications or services, set the **DCOM: Machin
 
 ### 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.
+Windows implements default COM ACLs when they're 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 doesn't, you must change your application-specific permission ACL to provide appropriate users with activation rights so that applications and Windows components that use DCOM don't fail.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md

@@ -27,17 +27,17 @@ Describes the best practices, location, values, and security considerations for
 
 ## 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.
+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 more 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 extra 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.
+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're 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.
+    This value 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
 
@@ -66,15 +66,15 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a computer restart when they're 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.
+If you're 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.
+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 setting restores control of the DCOM application to the administrator and specified users. To define this setting, 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 information defines the setting and sets the appropriate SDDL value.
 
 ## Security considerations
 
@@ -82,9 +82,9 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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.
+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 can't 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.
+Also, the COM infrastructure includes the Remote Procedure Call Service (RPCSS), a system service that runs during computer startup and always runs after the 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 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
 
@@ -92,7 +92,7 @@ To protect individual COM-based applications or services, set this policy settin
 
 ### 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.
+Windows implements default COM ACLs when they're 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 doesn't, 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 don't fail.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md

@@ -64,7 +64,7 @@ The following table lists the actual and effective default policy values. Defaul
 
 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.
+A restart of the device isn't 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.
 
@@ -87,25 +87,25 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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.
+Users who can sign in 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
+- Anonymous sign in
 - 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.
+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've 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 sign in to the server with the shared folder from the network. This user right is effective when you must configure servers and workstations on which sensitive information is handled because of regulatory compliance concerns.
 
 > [!NOTE]
 > If the service account is configured in the logon properties of a Windows service, it requires network logon rights to the domain controllers to start properly.
 
 ### 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.
+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 aren't negatively affected.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md

@@ -27,8 +27,7 @@ This article describes the recommended practices, location, values, policy manag
 
 ## 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 sign in by using a batch-queue tool is needed for any account that is used to start scheduled jobs with the Task Scheduler.
 
 Constant: SeDenyBatchLogonRight
 

windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md

@@ -89,12 +89,12 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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 
+Accounts that can sign in 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 reduced by the fact that only users with administrative rights can install and configure 
 services, and an attacker who already has that level of access could configure the service to run by using the System account.
 
 ### Countermeasure
 
-We recommend that you don't assign the **Deny log on as a service** user right to any accounts. This configuration is the default. Organizations that have strong concerns about security might assign this user right to groups and accounts when they're certain that they'll never need to log on to a service application.
+We recommend that you don't assign the **Deny log on as a service** user right to any accounts. This configuration is the default. Organizations that have strong concerns about security might assign this user right to groups and accounts when they're certain that they'll never need to sign in to a service application.
 
 ### Potential impact
 

windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md

@@ -62,11 +62,11 @@ The following table lists the actual and effective default policy values for the
 
 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.
+A restart of the device isn't 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.
+If you apply this policy setting to the Everyone group, no one will be able to sign in locally.
 
 ### Group Policy
 
@@ -87,15 +87,15 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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.
+Any account with the ability to sign in locally could be used to sign in at the console of the device. If this user right isn't restricted to legitimate users who must sign in 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.
+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 other 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.
+If you assign the **Deny log on locally** user right to other 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 devices that are configured with the Web Server role. You should confirm that delegated activities aren't adversely affected.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md

@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
 
 ## 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.
+This policy setting determines which users are prevented from logging on to the device through a Remote Desktop connection through Remote Desktop Services. It's possible for a user to establish a Remote Desktop connection to a particular server, but not be able to sign in to the console of that server.
 
 Constant: SeDenyRemoteInteractiveLogonRight
 
@@ -38,7 +38,7 @@ Constant: SeDenyRemoteInteractiveLogonRight
 
 ### 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.
+-   To control who can open a Remote Desktop connection and sign in to the device, add the user account to or remove user accounts from the Remote Desktop Users group.
 
 ### Location
 
@@ -61,7 +61,7 @@ The following table lists the actual and effective default policy values for the
 
 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.
+A restart of the computer isn't 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.
 
@@ -86,15 +86,15 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### 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.
+Any account with the right to sign in through Remote Desktop Services could be used to sign in to the remote console of the device. If this user right isn't restricted to legitimate users who need to sign in 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.
+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 other 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.
+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 can't connect to the device through Remote Desktop Services or Remote Assistance. You should confirm that delegated tasks aren't negatively affected.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md

@@ -1,6 +1,6 @@
 ---
 title: Devices Allow undock without having to log on (Windows 10)
-description: Describes the best practices, location, values, and security considerations for the Devices Allow undock without having to log on security policy setting.
+description: Describes the best practices, location, values, and security considerations for the Devices Allow undock without having to sign in security policy setting.
 ms.assetid: 1d403f5d-ad41-4bb4-9f4a-0779c1c14b8c
 ms.reviewer: 
 ms.author: dansimp
@@ -27,11 +27,11 @@ Describes the best practices, location, values, and security considerations for
 
 ## Reference
 
-This policy setting enables or disables the ability of a user to remove a portable device from a docking station without logging on. If you enable this policy setting, users can press a docked portable device's physical eject button to safely undock the device. If you disable this policy setting, the user must log on to receive permission to undock the device. Only users who have the **Remove Computer from Docking Station** privilege can obtain this permission.
+This policy setting enables or disables the ability of a user to remove a portable device from a docking station without logging on. If you enable this policy setting, users can press a docked portable device's physical eject button to safely undock the device. If you disable this policy setting, the user must sign in to receive permission to undock the device. Only users who have the **Remove Computer from Docking Station** privilege can obtain this permission.
 
 >**Note:**  Disabling this policy setting only reduces theft risk for portable devices that cannot be mechanically undocked. Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
  
-Enabling this policy setting means that anyone with physical access to a device that has been placed in its docking station can remove the computer and possibly tamper with it. For devices that do not have docking stations, this policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access to these devices
+Enabling this policy setting means that anyone with physical access to a device that has been placed in its docking station can remove the computer and possibly tamper with it. For devices that don't have docking stations, this policy setting has no impact. However, for users with a mobile computer that is normally docked while they are in the office, this policy setting will help lower the risk of equipment theft or a malicious user gaining physical access to these devices
 
 ### Possible values
 
@@ -41,7 +41,7 @@ Enabling this policy setting means that anyone with physical access to a device
 
 ### Best practices
 
-It is advisable to disable the **Devices: Allow undock without having to log on** policy setting. Users who have docked their devices will have to log on to the local console before they can undock their systems.
+It's advisable to disable the **Devices: Allow undock without having to log on** policy setting. Users who have docked their devices will have to sign in to the local console before they can undock their systems.
 
 ### Location
 
@@ -66,7 +66,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -79,9 +79,10 @@ If this policy setting is enabled, anyone with physical access to portable compu
 ### Countermeasure
 
 Disable the **Devices: Allow undock without having to log on** setting.
+
 ### Potential impact
 
-Users who have docked their device must log on to the local console before they can undock their computers. For devices that do not have docking stations, this policy setting has no impact.
+Users who have docked their device must sign in to the local console before they can undock their computers. For devices that don't have docking stations, this policy setting has no impact.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md

@@ -40,7 +40,7 @@ Users can move removable disks to a different device where they have administrat
 
 ### Best practices
 
--   It is advisable to set **Allowed to format and eject removable media** to **Administrators**. Only administrators will be able to eject NTFS-formatted removable media.
+-   It's advisable to set **Allowed to format and eject removable media** to **Administrators**. Only administrators will be able to eject NTFS-formatted removable media.
 
 ### Location
 
@@ -65,7 +65,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 

windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md

@@ -29,9 +29,9 @@ Describes the best practices, location, values, and security considerations for
 
 For a device to print to a network printer, the driver for that network printer must be installed locally. The **Devices: Prevent users from installing printer drivers** policy setting determines who can install a printer driver as part of adding a network printer. When you set the value to **Enabled**, only Administrators and Power Users can install a printer driver as part of adding a network printer. Setting the value to **Disabled** allows any user to install a printer driver as part of adding a network printer. This setting prevents unprivileged users from downloading and installing an untrusted printer driver.
 
-This setting has no impact if you have configured a trusted path for downloading drivers. When using trusted paths, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver is not installed and the network printer is not added.
+This setting has no impact if you've configured a trusted path for downloading drivers. If trusted paths are being used, the print subsystem attempts to use the trusted path to download the driver. If the trusted path download succeeds, the driver is installed on behalf of any user. If the trusted path download fails, the driver isn't installed and the network printer isn't added.
 
-Although it might be appropriate in some organizations to allow users to install printer drivers on their own workstations, this is not suitable for servers. Installing a printer driver on a server can cause the system to become less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to damage the system by installing inappropriate printer drivers.
+Although it might be appropriate in some organizations to allow users to install printer drivers on their own workstations, this idea isn't suitable for servers. Installing a printer driver on a server can cause the system to become less stable. Only administrators should have this user right on servers. A malicious user might deliberately try to damage the system by installing inappropriate printer drivers.
 
 ### Possible values
 
@@ -41,7 +41,7 @@ Although it might be appropriate in some organizations to allow users to install
 
 ### Best practices
 
--   It is advisable to set **Devices: Prevent users from installing printer drivers** to Enabled. Only users in the Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy setting is enabled, but the driver for a network printer already exists on the local computer, users can still add the network printer. This policy setting does not affect a user's ability to add a local printer.
+-   It's advisable to set **Devices: Prevent users from installing printer drivers** to Enabled. Only users in the Administrative, Power User, or Server Operator groups will be able to install printers on servers. If this policy setting is enabled, but the driver for a network printer already exists on the local computer, users can still add the network printer. This policy setting doesn't affect a user's ability to add a local printer.
 
 > [!NOTE]
 > After applying the [July 6, 2021 updates](https://support.microsoft.com/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7), non-administrators, including delegated admin groups like printer operators, cannot install signed and unsigned printer drivers to a print server. By default, only administrators can install both signed and unsigned printer drivers to a print server. 
@@ -69,7 +69,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a computer restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a computer restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 

windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md

@@ -29,9 +29,9 @@ Describes the best practices, location, values, and security considerations for
 
 This policy setting determines whether a CD is accessible to local and remote users simultaneously. If you enable this policy setting, only the interactively logged-on user is allowed to access removable CDs. If this policy setting is enabled and no one is logged on interactively, the CD can be accessed over the network.
 
-The security benefit of enabling this policy setting is small because it only prevents network users from accessing the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives are not automatically made available as network shared drives; you must deliberately choose to share the drive. This is important when administrators are installing software or copying data from a CD-ROM, and they do not want network users to be able to execute the applications or view the data.
+The security benefit of enabling this policy setting is small because it only prevents network users from accessing the drive when someone is logged on to the local console of the system at the same time. Additionally, CD drives aren't automatically made available as network shared drives; you must deliberately choose to share the drive. This setting to share is important when administrators are installing software or copying data from a CD-ROM, and they don't want network users to be able to execute the applications or view the data.
 
-If this policy setting is enabled, users who connect to the server over the network will not be able to use any CD drives that are installed on the server when anyone is logged on to the local console of the server. Enabling this policy setting is not suitable for a system that serves as a CD jukebox for network users.
+If this policy setting is enabled, users who connect to the server over the network won't be able to use any CD drives that are installed on the server when anyone is logged on to the local console of the server. Enabling this policy setting isn't suitable for a system that serves as a CD jukebox for network users.
 
 ### Possible values
 
@@ -67,7 +67,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -75,14 +75,14 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because CD drives are not automatically made available as shared drives; you must deliberately choose to share the drive. However, you can deny network users the ability to view data or run 
+A remote user could potentially access a mounted CD that contains sensitive information. This risk is small because CD drives aren't automatically made available as shared drives; you must deliberately choose to share the drive. However, you can deny network users the ability to view data or run 
 applications from removable media on the server.
 
 ### Countermeasure
 Enable the **Devices: Restrict CD-ROM drive access to locally logged-on user only** setting.
 
 ### Potential impact
-Users who connect to the server over the network cannot use any CD drives that are installed on the server when anyone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. This policy setting would not be suitable for a computer that serves as a CD jukebox for network users.
+Users who connect to the server over the network can't use any CD drives that are installed on the server when anyone is logged on to the local console of the server. System tools that require access to the CD drive will fail. For example, the Volume Shadow Copy service attempts to access all CD and floppy disk drives that are present on the computer when it initializes, and if the service can't access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail. This policy setting wouldn't be suitable for a computer that serves as a CD jukebox for network users.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md

@@ -29,9 +29,9 @@ Describes the best practices, location, values, and security considerations for
 
 This policy setting determines whether removable floppy disks are accessible to local and remote users simultaneously. Enabling this policy setting allows only the interactively logged-on user to access removable floppy disks. If this policy setting is enabled and no one is logged on interactively, the floppy disk can be accessed over the network.
 
-The security benefit of enabling this policy setting is small because it only prevents network users from accessing the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally, floppy disk drives are not automatically made available as network shared drives; you must deliberately choose to share the drive. This becomes important when you are installing software or copying data from a floppy disk and they do not want network users to be able to execute the applications or view the data.
+The security benefit of enabling this policy setting is small because it only prevents network users from accessing the floppy disk drive when someone is logged on to the local console of the system at the same time. Additionally, floppy disk drives aren't automatically made available as network shared drives; you must deliberately choose to share the drive. This setting to share becomes important when you're installing software or copying data from a floppy disk and they don't want network users to be able to execute the applications or view the data.
 
-If this policy setting is enabled, users who connect to the server over the network will not be able to use any floppy disk drives that are installed on the server when anyone is logged on to the local console of the server.
+If this policy setting is enabled, users who connect to the server over the network won't be able to use any floppy disk drives that are installed on the server when anyone is logged on to the local console of the server.
 
 ### Possible values
 
@@ -66,7 +66,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -74,7 +74,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small because floppy disk drives are not automatically shared; administrators must deliberately choose to share the drive. However, you can deny network users the ability to view data or run applications from removable media on the server.
+A remote user could potentially access a mounted floppy disk that contains sensitive information. This risk is small because floppy disk drives aren't automatically shared; administrators must deliberately choose to share the drive. However, you can deny network users the ability to view data or run applications from removable media on the server.
 
 ### Countermeasure
 
@@ -82,7 +82,7 @@ Enable the **Devices: Restrict floppy access to locally logged-on user only** se
 
 ### Potential impact
 
-Users who connect to the server over the network cannot use any floppy disk drives that are installed on the device when anyone is logged on to the local console of the server. System tools that require access to floppy disk drives fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are present on the computer when it initializes, and if the service cannot access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail.
+Users who connect to the server over the network can't use any floppy disk drives that are installed on the device when anyone is logged on to the local console of the server. System tools that require access to floppy disk drives fail. For example, the Volume Shadow Copy service attempts to access all CD-ROM and floppy disk drives that are present on the computer when it initializes, and if the service can't access one of these drives, it fails. This condition causes the Windows Backup tool to fail if volume shadow copies were specified for the backup job. Any non-Microsoft backup products that use volume shadow copies also fail.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md

@@ -31,9 +31,9 @@ This policy setting determines whether server operators can use the **at** comma
 
 >**Note:**  This security option setting affects only the scheduler tool for the **at** command. It does not affect the Task Scheduler tool.
  
-Enabling this policy setting means jobs that are created by server operators through the **at** command will be executed in the context of the account that is running that service—by default, that is the Local System account. This means that server operators can perform tasks that the Local System account is able to do, but server operators would normally not be able to do, such as add their account to the local Administrators group.
+Enabling this policy setting means jobs that are created by server operators through the **at** command will be executed in the context of the account that is running that service—by default, that is, the Local System account. This synchronization with the local account means that server operators can perform tasks that the Local System account is able to do, but server operators would normally not be able to do, such as add their account to the local Administrators group.
 
-The impact of enabling this policy setting should be small for most organizations. Users, including those in the Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run in the context of the account that the user authenticates with when setting up the job.
+The impact of enabling this policy setting should be small for most organizations. Users, including those users in the Server Operators group, will still be able to create jobs by using the Task Scheduler Wizard, but those jobs will run in the context of the account that the user authenticates with when setting up the job.
 
 ### Possible values
 
@@ -68,7 +68,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Command-line tools
 
@@ -88,7 +88,7 @@ Disable the **Domain controller: Allow server operators to schedule tasks** sett
 
 ### Potential impact
 
-The impact should be small for most organizations. Users (including those in the Server Operators group) can still create jobs by means of the Task Scheduler snap-in. However, those jobs run in the context of the account that the user authenticates with when setting up the job.
+The impact should be small for most organizations. Users (including those users in the Server Operators group) can still create jobs through the Task Scheduler snap-in. However, those jobs run in the context of the account that the user authenticates with when setting up the job.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md

@@ -29,9 +29,9 @@ This article describes the best practices, location, values, and security consid
 
 This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing.
 
-Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the case of an LDAP server, a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks difficult.
+Unsigned network traffic is susceptible to man-in-the-middle attacks, where an intruder captures packets between the server and the client device and modifies them before forwarding them to the client device. In the example of an LDAP server, a malicious user can cause a client device to make decisions based on false records from the LDAP directory. You can lower this risk in a corporate network by implementing strong physical security measures to protect the network infrastructure. Furthermore, implementing Internet Protocol security (IPsec) Authentication Header mode, which provides mutual authentication and packet integrity for IP traffic, can make all types of man-in-the-middle attacks difficult.
 
-This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).
+This setting doesn't have any impact on LDAP simple bind through SSL (LDAP TCP/636).
 
 If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).
 
@@ -39,13 +39,13 @@ If signing is required, then LDAP simple binds not using SSL are rejected (LDAP
  
 ### Possible values
 
--   None. Data signatures are not required to bind with the server. If the client computer requests data signing, the server supports it.
+-   None. Data signatures aren't required to bind with the server. If the client computer requests data signing, the server supports it.
 -   Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use.
 -   Not defined.
 
 ### Best practices
 
--   We recommend that you set **Domain controller: LDAP server signing requirements** to **Require signature**. Clients that do not support LDAP signing will be unable to execute LDAP queries against the domain controllers.
+-   We recommend that you set **Domain controller: LDAP server signing requirements** to **Require signature**. Clients that don't support LDAP signing will be unable to execute LDAP queries against the domain controllers.
 
 ### Location
 
@@ -70,7 +70,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -78,7 +78,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client device, modifies them, and then forwards them to the client device. Where LDAP servers are concerned, an attacker could cause a client device to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks difficult.
+Unsigned network traffic is susceptible to man-in-the-middle attacks. In such attacks, an intruder captures packets between the server and the client device, modifies them, and then forwards them to the client device. Regarding LDAP servers, an attacker could cause a client device to make decisions that are based on false records from the LDAP directory. To lower the risk of such an intrusion in an organization's network, you can implement strong physical security measures to protect the network infrastructure. You could also implement Internet Protocol security (IPsec) Authentication Header mode, which performs mutual authentication and packet integrity for IP traffic to make all types of man-in-the-middle attacks difficult.
 
 ### Countermeasure
 
@@ -86,7 +86,7 @@ Configure the **Domain controller: LDAP server signing requirements** setting to
 
 ### Potential impact
 
-Client devices that do not support LDAP signing cannot run LDAP queries against the domain controllers.
+Client devices that don't support LDAP signing can't run LDAP queries against the domain controllers.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md

@@ -30,7 +30,7 @@ This policy setting enables or disables blocking a domain controller from accept
 
 ### Possible values
 
--   **Enabled** When enabled, this setting does not allow a domain controller to accept any changes to a machine account's password.
+-   **Enabled** When enabled, this setting doesn't allow a domain controller to accept any changes to a machine account's password.
 
 -   **Disabled** When disabled, this setting allows a domain controller to accept any changes to a machine account's password.
 
@@ -38,7 +38,7 @@ This policy setting enables or disables blocking a domain controller from accept
 
 ### Best practices
 
--   Enabling this policy setting on all domain controllers in a domain prevents domain members from changing their machine account passwords. This, in turn, leaves those passwords susceptible to attack. Make sure that this conforms to your overall security policy for the domain.
+-   Enabling this policy setting on all domain controllers in a domain prevents domain members from changing their machine account passwords. This prevention, in turn, leaves those passwords susceptible to attack. Ensure that this setting conforms to your overall security policy for the domain.
 
 ### Location
 
@@ -70,7 +70,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -78,7 +78,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-If you enable this policy setting on all domain controllers in a domain, domain members cannot change their machine account passwords, and those passwords are more susceptible to attack.
+If you enable this policy setting on all domain controllers in a domain, domain members can't change their machine account passwords, and those passwords are more susceptible to attack.
 
 ### Countermeasure
 
@@ -86,7 +86,7 @@ Disable the **Domain controller: Refuse machine account password changes** setti
 
 ### Potential impact
 
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md

@@ -27,30 +27,29 @@ Describes the best practices, location, values, and security considerations for
 
 ## Reference
 
-This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. Logon information that is 
-transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
+This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. Sign-in information that is transmitted over the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
 
-The following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
+The following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic:
 
 -   Domain member: Digitally encrypt or sign secure channel data (always)
 -   [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
 -   [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
 
-Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
+Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data.
 
-To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a device running Windows that has joined a domain to have access to the user account database in its domain and in any trusted domains.
+To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a device running Windows that has joined a domain to have access to the user account database in its domain and in any trusted domains.
 
 To enable the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of signing or encrypting all secure-channel data.
 
 Enabling the **Domain member: Digitally encrypt or sign secure channel data (always)** policy setting automatically enables the [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) policy setting.
 
-When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass-through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After being connected to the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass-through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Possible values
 
 - Enabled
 
-  The policy [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure 
+  The policy [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md) is assumed to be enabled regardless of its current setting. This enablement ensures that the domain member attempts to negotiate at least signing of the secure 
   channel traffic.
 
 - Disabled
@@ -92,7 +91,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
@@ -104,8 +103,8 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and 
-sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the device is configured to encrypt or sign secure channel data, when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and 
+sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the device is configured to encrypt or sign secure channel data, when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Countermeasure
 
@@ -117,7 +116,7 @@ Select one of the following settings as appropriate for your environment to conf
 
 ### Potential impact
 
-Digital encryption and signing of the secure channel is a good idea because the secure channel protects domain credentials as they are sent to the domain controller.
+Digital encryption and signing of the secure channel is a good idea because the secure channel protects domain credentials as they're sent to the domain controller.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md

@@ -27,31 +27,31 @@ Describes the best practices, location, values, and security considerations for
 
 ## Reference
 
-This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be encrypted. Logon information that is transmitted over 
+This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be encrypted. Sign-in information that is transmitted over 
 the secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
 
-In addition to this policy setting, the following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
+In addition to this policy setting, the following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic:
 
 -   [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
 -   [Domain member: Digitally sign secure channel data (when possible)](domain-member-digitally-sign-secure-channel-data-when-possible.md)
 
-Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
+Setting **Domain member: Digitally encrypt or sign secure channel data (always)** to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data.
 
-To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
+To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate machine accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
 
 Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting.
 
-When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Possible values
 
 -   Enabled
 
-    The domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise, only logon information that is transmitted over the secure channel will be encrypted.
+    The domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise, only sign-in information that is transmitted over the secure channel will be encrypted.
 
 -   Disabled
 
-    The domain member will not attempt to negotiate secure channel encryption.
+    The domain member won't attempt to negotiate secure channel encryption.
 
     >**Note:**  If the security policy setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled, this setting will be overwritten.
      
@@ -86,11 +86,11 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
-Distribution of this policy through Group Policy does not override the Local Security Policy setting.
+Distribution of this policy through Group Policy doesn't override the Local Security Policy setting.
 
 ## Security considerations
 
@@ -98,7 +98,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Countermeasure
 
@@ -110,7 +110,7 @@ Select one of the following settings as appropriate for your environment to conf
 
 ### Potential impact
 
-Digital signing of the secure channel is a good idea because it protects domain credentials as they are sent to the domain controller.
+Digital signing of the secure channel is a good idea because it protects domain credentials as they're sent to the domain controller.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md

@@ -27,30 +27,30 @@ Describes the best practices, location, values, and security considerations for
 
 ## Reference
 
-This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed. Logon information that is transmitted over the 
+This setting determines whether all secure channel traffic that is initiated by the domain member meets minimum security requirements. Specifically, it determines whether all secure channel traffic that is initiated by the domain member must be signed. Sign-in information that is transmitted over the 
 secure channel is always encrypted regardless of whether the encryption of all other secure channel traffic is negotiated.
 
-The following policy settings determine whether a secure channel can be established with a domain controller that is not capable of signing or encrypting secure channel traffic:
+The following policy settings determine whether a secure channel can be established with a domain controller that isn't capable of signing or encrypting secure channel traffic:
 -   [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md)
 -   [Domain member: Digitally encrypt secure channel data (when possible)](domain-member-digitally-encrypt-secure-channel-data-when-possible.md)
 -   Domain member: Digitally sign secure channel data (when possible)
 
-Setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled** prevents establishing a secure channel with any domain controller that cannot sign or encrypt all secure channel data.
+Setting [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) to **Enabled** prevents establishing a secure channel with any domain controller that can't sign or encrypt all secure channel data.
 
-To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
+To protect authentication traffic from man-in-the-middle, replay, and other types of network attacks, Windows-based computers create a communication channel through NetLogon called secure channels. These channels authenticate computer accounts. They also authenticate user accounts when a remote user connects to a network resource and the user account exists in a trusted domain. This authentication is called pass-through authentication, and it allows a computer running the Windows operating system that has joined a domain to have access to the user account database in its domain and in any trusted domains.
 
 Enabling the [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) policy setting automatically enables the **Domain member: Digitally sign secure channel data (when possible)** policy setting.
-When a device joins a domain, a machine account is created. After joining the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel is not checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After the device is joined with the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. This secure channel is used to perform operations such as NTLM pass through authentication and LSA SID/name Lookup. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the integrity of the channel isn't checked, and not all information is encrypted. If a system is set to always encrypt or sign secure channel data, a secure channel can't be established with a domain controller that isn't capable of signing or encrypting all secure channel traffic. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Possible values
 
 -   Enabled
 
-    The domain member will request signing of all secure channel traffic. If the domain controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it cannot be tampered with in transit.
+    The domain member will request to sign all secure channel traffic. If the domain controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it can't be tampered with in transit.
 
 -   Disabled
 
-    Signing will not be negotiated unless the policy [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled.
+    Signing won't be negotiated unless the policy [Domain member: Digitally encrypt or sign secure channel data (always)](domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md) is enabled.
 
 -   Not defined
 
@@ -84,11 +84,11 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
-Distribution of this policy through Group Policy does not override the Local Security Policy setting.
+Distribution of this policy through Group Policy doesn't override the Local Security Policy setting.
 
 ## Security considerations
 
@@ -96,7 +96,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel is not integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller cannot sign or encrypt any portion of the secure channel data, the computer and domain controller cannot establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
+When a device joins a domain, a machine account is created. After it joins the domain, the device uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests that are sent on the secure channel are authenticated—and sensitive information such as passwords are encrypted—but the channel isn't integrity-checked, and not all information is encrypted. If a device is configured to always encrypt or sign secure channel data but the domain controller can't sign or encrypt any portion of the secure channel data, the computer and domain controller can't establish a secure channel. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.
 
 ### Countermeasure
 
@@ -108,7 +108,7 @@ Because these policies are closely related and useful depending on your environm
 
 ### Potential impact
 
-Digital signing of the secure channel is a good idea because the secure channel protects domain credentials as they are sent to the domain controller.
+Digital signing of the secure channel is a good idea because the secure channel protects domain credentials as they're sent to the domain controller.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md

@@ -39,12 +39,12 @@ Verify that the **Domain member: Disable machine account password changes** opti
 
 ### Best practices
 
-1. Do not enable this policy setting. Machine account passwords are used to establish secure channel communications between members and domain controllers and between the domain controllers within the domain. After it is established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions.
-2. Do not use this policy setting to try to support dual-boot scenarios that use the same machine account. If you want to configure dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to help organizations that stockpile pre-built computers that are put into production months later. Those devices do not have to be rejoined to the domain.
-3. You may want to consider using this policy setting in specific environments, such as the following:
+1. Don't enable this policy setting. Machine account passwords are used to establish secure channel communications between members and domain controllers and between the domain controllers within the domain. After it's established, the secure channel transmits sensitive information that is necessary for making authentication and authorization decisions.
+2. Don't use this policy setting to try to support dual-boot scenarios that use the same machine account. If you want to configure dual-boot installations that are joined to the same domain, give the two installations different computer names. This policy setting was added to the Windows operating system to help organizations that stockpile pre-built computers that are put into production months later. Those devices don't have to be rejoined to the domain.
+3. You may want to consider using this policy setting in specific environments, such as the following ones:
 
      - Non-persistent Virtual Desktop Infrastructure implementations. In such implementations, each session starts from a read-only base image.
-     - Embedded devices that do not have write access to the OS volume.  
+     - Embedded devices that don't have write access to the OS volume.  
   
     In either case, a password change that was made during normal operations would be lost as soon as the session ends. We strongly recommend that you plan password changes for maintenance windows. Add the password changes to the updates and modifications that Windows performs during maintenance windows. To trigger a password update on a specific OS volume, run the following command:
 
@@ -77,7 +77,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ## Security considerations
 
@@ -86,7 +86,7 @@ This section describes how an attacker might exploit a feature or its configurat
 ### Vulnerability
 
 By default, devices running Windows Server that belong to a domain automatically change their passwords for their accounts every certain number of days, typically 30. If you disable this policy setting, devices that run Windows Server retain the same passwords as their machine accounts. Devices 
-that cannot automatically change their account password are at risk from an attacker who could determine the password for the machine's domain account.
+that can't automatically change their account password are at risk from an attacker who could determine the password for the machine's domain account.
 
 ### Countermeasure
 
@@ -94,7 +94,7 @@ Verify that the **Domain member: Disable machine account password changes** sett
 
 ### Potential impact
 
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
 
 ## Related topics