Acrolinx Enhancement Effort

windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md

@@ -30,7 +30,7 @@ Describes the best practices, location, values, policy management, and security
 This security setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller that provides Kerberos authentication.
 
 To prevent "replay attacks," the Kerberos v5 protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be in sync as much as possible. In other words, both devices must be set to the same time and date. 
-Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, any time stamp that is used in a session between the two devices is considered to be authentic.
+Because the clocks of two computers are often out of sync, you can use this policy setting to establish the maximum acceptable difference to the Kerberos protocol between a client clock and domain controller clock. If the difference between a client computer clock and the domain controller clock is less than the maximum time difference that is specified in this policy, anytime stamp that is used in a session between the two devices is considered to be authentic.
 
 The possible values for this Group Policy setting are:
 
@@ -39,7 +39,7 @@ The possible values for this Group Policy setting are:
 
 ### Best practices
 
--   It is advisable to set **Maximum tolerance for computer clock synchronization** to a value of 5 minutes.
+-   It's advisable to set **Maximum tolerance for computer clock synchronization** to a value of 5 minutes.
 
 ### Location
 
@@ -62,7 +62,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.
 
 This policy setting is configured on the domain controller.
 
@@ -85,7 +85,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock and a domain controller clock. If the difference between the client computer clock and the domain controller clock is less than the maximum time difference specified in this setting, any time stamp that is used in a session between the two computers is considered to be authentic.
+To prevent "replay attacks" (which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource), the Kerberos protocol uses time stamps as part of its definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference to the Kerberos protocol between a client computer clock and a domain controller clock. If the difference between the client computer clock and the domain controller clock is less than the maximum time difference specified in this setting, anytime stamp that is used in a session between the two computers is considered to be authentic.
 
 ### Countermeasure
 
@@ -93,7 +93,7 @@ Configure the **Maximum tolerance for computer clock synchronization** setting t
 
 ### 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/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md

@@ -28,23 +28,23 @@ Describes the best practices, location, values, policy management and security c
 
 ## Reference
 
-The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. This policy setting allows or prevents the SMB redirector to send plaintext passwords to a non-Microsoft server service that does not support password encryption during authentication.
+The Server Message Block (SMB) protocol provides the basis for file and print sharing and many other networking operations, such as remote Windows administration. This policy setting allows or prevents the SMB redirector to send plaintext passwords to a non-Microsoft server service that doesn't support password encryption during authentication.
 
 ### Possible values
 
 -   Enabled
 
-    The Server Message Block (SMB) redirector is allowed to send plaintext passwords to a non-Microsoft server service that does not support password encryption during authentication.
+    The Server Message Block (SMB) redirector is allowed to send plaintext passwords to a non-Microsoft server service that doesn't support password encryption during authentication.
 
 -   Disabled
 
-    The Server Message Block (SMB) redirector only sends encrypted passwords to non-Microsoft SMB server services. If those server services do not support password encryption, the authentication request will fail.
+    The Server Message Block (SMB) redirector only sends encrypted passwords to non-Microsoft SMB server services. If those server services don't support password encryption, the authentication request will fail.
 
 -   Not defined
 
 ### Best practices
 
--   It is advisable to set **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** to Disabled.
+-   It's advisable to set **Microsoft network client: Send unencrypted password to connect to third-party SMB servers** to Disabled.
 
 ### Location
 
@@ -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 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
 
@@ -85,7 +85,7 @@ Disable the **Microsoft network client: Send unencrypted password to connect to
 
 ### Potential impact
 
-Some older applications may not be able to communicate with the servers in your organization by means of the SMB protocol.
+Some older applications may not be able to communicate with the servers in your organization through the SMB protocol.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md

@@ -41,7 +41,7 @@ The **Microsoft network server: Amount of idle time required before suspending s
 
 ### Best practices
 
--   It is advisable to set this policy to 15 minutes. There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity.
+-   It's advisable to set this policy to 15 minutes. There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity.
 
 ### Location
 
@@ -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
 
@@ -83,7 +83,7 @@ The default behavior on a server mitigates this threat by design.
 
 ### Potential impact
 
-There is little impact because SMB sessions are reestablished automatically if the client computer resumes activity.
+There's little impact because SMB sessions are reestablished automatically if the client computer resumes activity.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md

@@ -30,9 +30,9 @@ Describes the best practices, location, values, management, and security conside
 This security setting supports client devices running a version of Windows prior to Windows 8 that are trying to access a file share that requires user claims. This setting determines whether the local file server will attempt to use Kerberos Service-for-User-to-Self (S4U2Self) functionality to obtain a network client principal’s claims from the client’s account domain. This setting should only be enabled if the file server is using user claims to control access to files, and if the file server will support client principals whose accounts might be in a domain that has client computers 
 and domain controllers running a version of Windows prior to Windows 8 or Windows Server 2012.
 
-When enabled, this security setting causes the Windows file server to examine the access token of an authenticated network client principal and determines if claim information is present. If claims are not present, the file server will then use the Kerberos S4U2Self feature to attempt to contact a Windows Server 2012 domain controller in the client’s account domain and obtain a claims-enabled access token for the client principal. A claims-enabled token might be needed to access files or folders that have claim-based access control policy applied.
+When enabled, this security setting causes the Windows file server to examine the access token of an authenticated network client principal and determines if claim information is present. If claims aren't present, the file server will then use the Kerberos S4U2Self feature to attempt to contact a Windows Server 2012 domain controller in the client’s account domain and obtain a claims-enabled access token for the client principal. A claims-enabled token might be needed to access files or folders that have claim-based access control policy applied.
 
-If this setting is disabled, the Windows file server will not attempt to obtain a claim-enabled access token for the client principal.
+If this setting is disabled, the Windows file server won't attempt to obtain a claim-enabled access token for the client principal.
 
 ### Possible values
 
@@ -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.
 
 ### Group Policy
 
@@ -89,7 +89,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-None. Enabling this policy setting allows you take advantage of features in Windows Server 2012 and Windows 8 and later for specific scenarios to use claims-enabled tokens to access files or folders that have claim-based access control policy applied on Windows operating systems prior to Windows Server 2012 
+None. Enabling this policy setting allows you to take advantage of features in Windows Server 2012 and Windows 8 and later for specific scenarios to use claims-enabled tokens to access files or folders that have claim-based access control policy applied on Windows operating systems prior to Windows Server 2012 
 and Windows 8.
 
 ### Countermeasure

windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md

@@ -34,7 +34,7 @@ Implementation of digital signatures in high-security networks helps prevent the
 
 Beginning with SMBv2 clients and servers, signing can be either required or not required. If this policy setting is enabled, SMBv2 clients will digitally sign all packets. Another policy setting determines whether signing is required for SMBv3 and SMBv2 server communications: [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
 
-There is a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. The following table has the effective behavior for SMBv3 and SMBv2.
+There's a negotiation done between the SMB client and the SMB server to decide whether signing will effectively be used. The following table has the effective behavior for SMBv3 and SMBv2.
 
 
 |                           |  Server – Required  | Server – Not Required  |
@@ -46,7 +46,7 @@ There is a negotiation done between the SMB client and the SMB server to decide
 <sup>1</sup> Default for domain controller SMB traffic</br>
 <sup>2</sup> Default for all other SMB traffic
 
-Performance of SMB signing is improved in SMBv2. For more details, see [Potential impact](#potential-impact). 
+Performance of SMB signing is improved in SMBv2. For more information, see [Potential impact](#potential-impact). 
 
 ### Possible values
 
@@ -80,7 +80,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
 
@@ -90,7 +90,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 Session hijacking uses tools that allow attackers who have access to the same network as the client device or server to interrupt, end, or steal a session in progress. Attackers can potentially intercept and modify unsigned Server Message Block (SMB) packets and then modify the traffic and forward it so that the server might perform objectionable actions. Alternatively, the attacker could pose as the server or client device after legitimate authentication and gain unauthorized access to data.
 
-SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. If either side fails the authentication process, data transmission does not take place.
+SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of many modern features like Storage Spaces Direct, Storage Replica, and SMB Direct, as well as many legacy protocols and tools. If either side fails the authentication process, data transmission doesn't take place.
 
 ### Countermeasure
 
@@ -101,7 +101,7 @@ Enable **Microsoft network server: Digitally sign communications (always)**.
 
 ### Potential impact
 
-Storage speeds impact performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. If you are using a 1 Gb Ethernet network or slower storage speed with a modern CPU, there is limited degradation in performance. If you are using a faster network (such as 10 Gb), the performance impact of signing may be greater.
+Storage speeds impact performance. A faster drive on the source and destination allows more throughput, which causes more CPU usage of signing. If you're using a 1-GB Ethernet network or slower storage speed with a modern CPU, there's limited degradation in performance. If you're using a faster network (such as 10 Gb), the performance impact of signing may be greater.
 
 ## Related topics