From cefd60d7cfc9816f300090d7c7f72b34babc4782 Mon Sep 17 00:00:00 2001
From: MaratMussabekov <48041687+MaratMussabekov@users.noreply.github.com>
Date: Wed, 18 Aug 2021 11:38:52 +0500
Subject: [PATCH 001/299] Update hello-hybrid-aadj-sso-cert.md
---
.../hello-for-business/hello-hybrid-aadj-sso-cert.md | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index b8ce7af3da..2a7ae63ab9 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -200,9 +200,10 @@ Sign-in to the issuing certificate authority or management workstations with _Do
5. On the **Subject** tab, select **Supply in the request**.
6. On the **Cryptography** tab, validate the **Minimum key size** is **2048**.
7. On the **Security** tab, click **Add**.
-8. Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
-9. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
-10. Click on the **Apply** to save changes and close the console.
+8. Select **Object Types**, then, in the appeared window, choose **Computers** and click **OK**
+9. Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
+10. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
+11. Click on the **Apply** to save changes and close the console.
### Create an Azure AD joined Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows 10 requests an authentication certificate from Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring the NDES Server.
From 731d2d151e9bef92702af7f5a1d1eea84ce3e373 Mon Sep 17 00:00:00 2001
From: MaratMussabekov <48041687+MaratMussabekov@users.noreply.github.com>
Date: Wed, 18 Aug 2021 15:11:18 +0500
Subject: [PATCH 002/299] Update
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com>
---
.../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
index 2a7ae63ab9..f40d2342c4 100644
--- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
+++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
@@ -200,7 +200,7 @@ Sign-in to the issuing certificate authority or management workstations with _Do
5. On the **Subject** tab, select **Supply in the request**.
6. On the **Cryptography** tab, validate the **Minimum key size** is **2048**.
7. On the **Security** tab, click **Add**.
-8. Select **Object Types**, then, in the appeared window, choose **Computers** and click **OK**
+8. Select **Object Types**, then, in the window that appears, choose **Computers** and click **OK**.
9. Type **NDES server** in the **Enter the object names to select** text box and click **OK**.
10. Select **NDES server** from the **Group or users names** list. In the **Permissions for** section, select the **Allow** check box for the **Enroll** permission. Clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list if the check boxes are not already cleared. Click **OK**.
11. Click on the **Apply** to save changes and close the console.
From c17cb0d827ad8ea1e8438f0149d30f196d48c886 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Thu, 16 Jun 2022 20:44:51 +0530
Subject: [PATCH 003/299] Acrolinx Enhancement
---
.../threat-protection/auditing/event-4913.md | 22 +++++++++----------
.../threat-protection/auditing/event-4928.md | 4 ++--
.../threat-protection/auditing/event-4929.md | 6 ++---
.../threat-protection/auditing/event-4930.md | 8 +++----
.../threat-protection/auditing/event-4931.md | 6 ++---
.../threat-protection/auditing/event-4945.md | 8 +++----
.../threat-protection/auditing/event-4946.md | 12 +++++-----
.../threat-protection/auditing/event-4948.md | 12 +++++-----
.../threat-protection/auditing/event-4950.md | 4 ++--
.../threat-protection/auditing/event-4951.md | 20 ++++++++---------
10 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/windows/security/threat-protection/auditing/event-4913.md b/windows/security/threat-protection/auditing/event-4913.md
index 9c173860f4..dc79e60f50 100644
--- a/windows/security/threat-protection/auditing/event-4913.md
+++ b/windows/security/threat-protection/auditing/event-4913.md
@@ -77,13 +77,13 @@ This event always generates, regardless of the object’s [SACL](/windows/win32/
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policy on the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policy on the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the Central Access Policy on the object.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -137,7 +137,7 @@ This event always generates, regardless of the object’s [SACL](/windows/win32/
- **Original Security Descriptor** \[Type = UnicodeString\]**:** the Security Descriptor Definition Language (SDDL) value for the old Central Policy ID (for the policy that was formerly applied to the object).
- SDDL contains Central Access Policy SID, here is an example: S:ARAI(SP;ID;;;;S-1-17-1442530252-1178042555-1247349694-2318402534), Central Access Policy SID here is “**S-1-17-1442530252-1178042555-1247349694-2318402534**”. To resolve this SID to the real Central Access Policy name you need to do the following:
+ SDDL contains Central Access Policy SID, here's an example: S:ARAI(SP;ID;;;;S-1-17-1442530252-1178042555-1247349694-2318402534), Central Access Policy SID here is “**S-1-17-1442530252-1178042555-1247349694-2318402534**”. To resolve this SID to the real Central Access Policy name, you need to do the following steps:
1. Find Central Access Policy Active Directory object in: “CN=Central Access Policies,CN=Claims Configuration,CN=Services,CN=Configuration,DC=XXX,DC=XX” Active Directory container.
@@ -166,11 +166,11 @@ This event always generates, regardless of the object’s [SACL](/windows/win32/
|-------|--------------------------------------|-------|---------------------------------|
| "AO" | Account operators | "PA" | Group Policy administrators |
| "RU" | Alias to allow previous Windows 2000 | "IU" | Interactively logged-on user |
-| "AN" | Anonymous logon | "LA" | Local administrator |
+| "AN" | Anonymous sign in | "LA" | Local administrator |
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
-| "BO" | Backup operators | "NU" | Network logon user |
+| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@@ -182,7 +182,7 @@ This event always generates, regardless of the object’s [SACL](/windows/win32/
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
-| "WD" | Everyone | "SU" | Service logon user |
+| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@@ -202,7 +202,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
-"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
+"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@@ -228,7 +228,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
-"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
+"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@@ -239,7 +239,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
-- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
+- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@@ -261,7 +261,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
-- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
+- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: , .
@@ -277,7 +277,7 @@ For 4913(S): Central Access Policy on the object was changed.
- If you have a pre-defined “**Process Name**” for the process reported in this event, monitor all events with “**Process Name**” not equal to your defined value.
-- You can monitor to see if “**Process Name**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Process Name**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
diff --git a/windows/security/threat-protection/auditing/event-4928.md b/windows/security/threat-protection/auditing/event-4928.md
index 2899b77a51..64481ef466 100644
--- a/windows/security/threat-protection/auditing/event-4928.md
+++ b/windows/security/threat-protection/auditing/event-4928.md
@@ -97,12 +97,12 @@ Failure event generates if an error occurs (**Status Code** != 0).
-- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here:
+- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here:
## Security Monitoring Recommendations
For 4928(S, F): An Active Directory replica source naming context was established.
-- Monitor for **Source Address** field, because the source of new replication (new DRA) must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
+- Monitor for **Source Address** field, because the source of new replication (new DRA) must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-4929.md b/windows/security/threat-protection/auditing/event-4929.md
index 8d4802ca42..bd67b19fac 100644
--- a/windows/security/threat-protection/auditing/event-4929.md
+++ b/windows/security/threat-protection/auditing/event-4929.md
@@ -89,18 +89,18 @@ Failure event generates if an error occurs (**Status Code** != 0).
- **Source Address** \[Type = UnicodeString\]: DNS record of the server from which the “remove” request was received.
-- **Naming Context** \[Type = UnicodeString\]**:** naming context which was removed.
+- **Naming Context** \[Type = UnicodeString\]**:** naming context that was removed.
> **Note** The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
-- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here:
+- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here:
## Security Monitoring Recommendations
For 4929(S, F): An Active Directory replica source naming context was removed.
-- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
+- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-4930.md b/windows/security/threat-protection/auditing/event-4930.md
index ad5d6086a1..c63813a961 100644
--- a/windows/security/threat-protection/auditing/event-4930.md
+++ b/windows/security/threat-protection/auditing/event-4930.md
@@ -27,7 +27,7 @@ This event generates every time Active Directory replica source naming context w
Failure event generates if an error occurs (**Status Code** != 0).
-It is not possible to understand what exactly was modified from this event.
+It isn't possible to understand what exactly was modified from this event.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -91,18 +91,18 @@ It is not possible to understand what exactly was modified from this event.
- **Source Address** \[Type = UnicodeString\]: DNS record of computer from which the modification request was received.
-- **Naming Context** \[Type = UnicodeString\]**:** naming context which was modified.
+- **Naming Context** \[Type = UnicodeString\]**:** naming context that was modified.
> **Note** The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
-- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here:
+- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here:
## Security Monitoring Recommendations
For 4930(S, F): An Active Directory replica source naming context was modified.
-- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA you should trigger an event.
+- Monitor for **Source Address** field, because the source of the request must be authorized for this action. If you find any unauthorized DRA, you should trigger an event.
- This event is typically used for Active Directory replication troubleshooting.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-4931.md b/windows/security/threat-protection/auditing/event-4931.md
index 39a7be5a64..46b91b742c 100644
--- a/windows/security/threat-protection/auditing/event-4931.md
+++ b/windows/security/threat-protection/auditing/event-4931.md
@@ -27,7 +27,7 @@ This event generates every time Active Directory replica destination naming cont
Failure event generates if an error occurs (**Status Code** != 0).
-It is not possible to understand what exactly was modified from this event.
+It isn't possible to understand what exactly was modified from this event.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -91,13 +91,13 @@ It is not possible to understand what exactly was modified from this event.
- **Destination Address** \[Type = UnicodeString\]: DNS record of computer to which the modification request was sent.
-- **Naming Context** \[Type = UnicodeString\]**:** naming context which was modified.
+- **Naming Context** \[Type = UnicodeString\]**:** naming context that was modified.
> **Note** The Directory Tree of Active Directory tree is partitioned to allow sections to be distributed (replicated) to domain controllers in different domains within the forest. Each domain controller stores a copy of a specific part of the directory tree, called a **Naming Context** also known as Directory Partition. **Naming Context** is replicated as a unit to other domain controllers in the forest that contain a replica of the same sub tree. A **Naming Context** is also called a Directory Partition.
- **Options** \[Type = UInt32\]: decimal value of [DRS Options](/openspecs/windows_protocols/ms-drsr/ac9c8a11-cd46-4080-acbf-9faa86344030).
-- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you will receive Failure event and Status Code will not be equal to “**0**”. You can check error code meaning here:
+- **Status Code** \[Type = UInt32\]**:** if there are no issues or errors, the status code will be 0. If an error happened, you'll receive Failure event and Status Code won't be equal to “**0**”. You can check error code meaning here:
## Security Monitoring Recommendations
diff --git a/windows/security/threat-protection/auditing/event-4945.md b/windows/security/threat-protection/auditing/event-4945.md
index f5581407ab..cc7ffb2eec 100644
--- a/windows/security/threat-protection/auditing/event-4945.md
+++ b/windows/security/threat-protection/auditing/event-4945.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time Windows Firewall service starts.
-This event shows the inbound and/or outbound rule which was listed when the Windows Firewall started and applied for “Public” profile.
+This event shows the inbound and/or outbound rule that was listed when the Windows Firewall started and applied for “Public” profile.
This event generates per rule.
@@ -75,11 +75,11 @@ This event generates per rule.
- **Rule ID** \[Type = UnicodeString\]: the unique firewall rule identifier.
- To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
-- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was listed when the Windows Firewall started. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
+- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was listed when the Windows Firewall started. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
@@ -89,5 +89,5 @@ For 4945(S): A rule was listed when the Windows Firewall started.
- Typically this event has an informational purpose.
-- Unfortunately this event shows rules only for **Public** profile, but you still can compare this list with your organization's Windows Firewall baseline for Public profile rules on different computers, and trigger an alert if the configuration is not the same.
+- Unfortunately this event shows rules only for **Public** profile, but you still can compare this list with your organization's Windows Firewall baseline for Public profile rules on different computers, and trigger an alert if the configuration isn't the same.
diff --git a/windows/security/threat-protection/auditing/event-4946.md b/windows/security/threat-protection/auditing/event-4946.md
index 505cec18fb..5a3a44929a 100644
--- a/windows/security/threat-protection/auditing/event-4946.md
+++ b/windows/security/threat-protection/auditing/event-4946.md
@@ -71,11 +71,11 @@ This event doesn't generate when new rule was added via Group Policy.
- All
-- Domain,Public
+- Domain, Public
-- Domain,Private
+- Domain, Private
-- Private,Public
+- Private, Public
- Public
@@ -87,11 +87,11 @@ This event doesn't generate when new rule was added via Group Policy.
- **Rule ID** \[Type = UnicodeString\]: the unique new firewall rule identifier.
- To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
-- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was added. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
+- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was added. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
@@ -99,5 +99,5 @@ This event doesn't generate when new rule was added via Group Policy.
For 4946(S): A change has been made to Windows Firewall exception list. A rule was added.
-- This event can be helpful in case you want to monitor all creations of new Firewall rules which were done locally.
+- This event can be helpful in case you want to monitor all creations of new Firewall rules that were done locally.
diff --git a/windows/security/threat-protection/auditing/event-4948.md b/windows/security/threat-protection/auditing/event-4948.md
index 65c71e3cd4..ecc34d3112 100644
--- a/windows/security/threat-protection/auditing/event-4948.md
+++ b/windows/security/threat-protection/auditing/event-4948.md
@@ -71,11 +71,11 @@ This event doesn't generate when the rule was deleted via Group Policy.
- All
-- Domain,Public
+- Domain, Public
-- Domain,Private
+- Domain, Private
-- Private,Public
+- Private, Public
- Public
@@ -87,11 +87,11 @@ This event doesn't generate when the rule was deleted via Group Policy.
- **Rule ID** \[Type = UnicodeString\]: the unique identifier for deleted firewall rule.
- To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
-- **Rule Name** \[Type = UnicodeString\]: the name of the rule which was deleted. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
+- **Rule Name** \[Type = UnicodeString\]: the name of the rule that was deleted. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
@@ -99,5 +99,5 @@ This event doesn't generate when the rule was deleted via Group Policy.
For 4948(S): A change has been made to Windows Firewall exception list. A rule was deleted.
-- This event can be helpful in case you want to monitor all deletions of Firewall rules which were done locally.
+- This event can be helpful in case you want to monitor all deletions of Firewall rules that were done locally.
diff --git a/windows/security/threat-protection/auditing/event-4950.md b/windows/security/threat-protection/auditing/event-4950.md
index 69db4a04e2..8c7148eb98 100644
--- a/windows/security/threat-protection/auditing/event-4950.md
+++ b/windows/security/threat-protection/auditing/event-4950.md
@@ -77,7 +77,7 @@ This event doesn't generate when Windows Firewall setting was changed via Group
**New Setting:**
-- **Type** \[Type = UnicodeString\]: the name of the setting which was modified. You can use “**netsh advfirewall**” command to see or set Windows Firewall settings, for example, to see settings for current\\active Windows Firewall profile you need to execute “**netsh advfirewall show currentprofile**” command:
+- **Type** \[Type = UnicodeString\]: the name of the setting that was modified. You can use “**netsh advfirewall**” command to see or set Windows Firewall settings, for example, to see settings for current\\active Windows Firewall profile you need to execute “**netsh advfirewall show currentprofile**” command:
@@ -89,5 +89,5 @@ For 4950(S): A Windows Firewall setting has changed.
- If you have a standard or baseline for Windows Firewall settings defined, monitor this event and check whether the settings reported by the event are still the same as were defined in your standard or baseline.
-- This event can be helpful in case you want to monitor all changes in Windows Firewall settings which were done locally.
+- This event can be helpful in case you want to monitor all changes in Windows Firewall settings that were done locally.
diff --git a/windows/security/threat-protection/auditing/event-4951.md b/windows/security/threat-protection/auditing/event-4951.md
index 060b9c4b83..6f7ede1970 100644
--- a/windows/security/threat-protection/auditing/event-4951.md
+++ b/windows/security/threat-protection/auditing/event-4951.md
@@ -1,6 +1,6 @@
---
-title: 4951(F) A rule has been ignored because its major version number was not recognized by Windows Firewall. (Windows 10)
-description: Describes security event 4951(F) A rule has been ignored because its major version number was not recognized by Windows Firewall.
+title: 4951(F) A rule has been ignored because its major version number wasn't recognized by Windows Firewall. (Windows 10)
+description: Describes security event 4951(F) A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,7 +14,7 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 4951(F): A rule has been ignored because its major version number was not recognized by Windows Firewall.
+# 4951(F): A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
@@ -25,7 +25,7 @@ ms.technology: windows-sec
When you create or edit a Windows Firewall rule, the settings that you can include depend upon the version of Windows you use when creating the rule. As new settings are added to later versions of Windows or to service packs for existing versions of Windows, the version number of the rules processing engine is updated, and that version number is stamped into rules that are created by using that version of Windows. For example, Windows Vista produces firewall rules that are stamped with version "v2.0". Future versions of Windows might use "v2.1", or "v3.0" to indicate, respectively, minor or major changes and additions.
-If you create a firewall rule on a newer version of Windows that references firewall settings that are not available on earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows, the firewall engine produces this error to indicate that it cannot process the rule.
+If you create a firewall rule on a newer version of Windows that references firewall settings that aren't available on earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows, the firewall engine produces this error to indicate that it can't process the rule.
The only solution is to remove the incompatible rule, and then deploy a compatible rule.
@@ -73,11 +73,11 @@ The only solution is to remove the incompatible rule, and then deploy a compatib
- All
-- Domain,Public
+- Domain, Public
-- Domain,Private
+- Domain, Private
-- Private,Public
+- Private, Public
- Public
@@ -89,17 +89,17 @@ The only solution is to remove the incompatible rule, and then deploy a compatib
- **ID** \[Type = UnicodeString\]: the unique identifier for ignored firewall rule.
- To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
-- **Name** \[Type = UnicodeString\]: the name of the rule which was ignored. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
+- **Name** \[Type = UnicodeString\]: the name of the rule that was ignored. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
## Security Monitoring Recommendations
-For 4951(F): A rule has been ignored because its major version number was not recognized by Windows Firewall.
+For 4951(F): A rule has been ignored because its major version number wasn't recognized by Windows Firewall.
- This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition. Typically this event indicates configuration issues, not security issues.
From 5fbd3e07d79ac80f4a6e27a3acfdaa17d7929c04 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Fri, 17 Jun 2022 15:46:12 +0530
Subject: [PATCH 004/299] Acrolinx enhancement effort
---
.../threat-protection/auditing/event-4953.md | 18 +++++++++---------
.../threat-protection/auditing/event-4957.md | 16 ++++++++--------
.../threat-protection/auditing/event-4958.md | 12 ++++++------
.../threat-protection/auditing/event-5030.md | 4 ++--
.../threat-protection/auditing/event-5031.md | 6 +++---
.../threat-protection/auditing/event-5038.md | 12 ++++++------
.../threat-protection/auditing/event-5039.md | 6 +++---
.../threat-protection/auditing/event-5051.md | 6 +++---
.../threat-protection/auditing/event-5056.md | 4 ++--
.../threat-protection/auditing/event-5057.md | 6 +++---
.../threat-protection/auditing/event-5058.md | 10 +++++-----
.../threat-protection/auditing/event-5060.md | 4 ++--
.../threat-protection/auditing/event-5061.md | 10 +++++-----
.../threat-protection/auditing/event-5063.md | 6 +++---
.../threat-protection/auditing/event-5064.md | 6 +++---
.../threat-protection/auditing/event-5065.md | 7 +++----
.../threat-protection/auditing/event-5066.md | 6 +++---
.../threat-protection/auditing/event-5067.md | 8 ++++----
.../threat-protection/auditing/event-5068.md | 8 ++++----
.../threat-protection/auditing/event-5069.md | 8 ++++----
20 files changed, 81 insertions(+), 82 deletions(-)
diff --git a/windows/security/threat-protection/auditing/event-4953.md b/windows/security/threat-protection/auditing/event-4953.md
index 2d31faae0c..c327d3a349 100644
--- a/windows/security/threat-protection/auditing/event-4953.md
+++ b/windows/security/threat-protection/auditing/event-4953.md
@@ -1,6 +1,6 @@
---
-title: 4953(F) Windows Firewall ignored a rule because it could not be parsed. (Windows 10)
-description: Describes security event 4953(F) Windows Firewall ignored a rule because it could not be parsed.
+title: 4953(F) Windows Firewall ignored a rule because it couldn't be parsed. (Windows 10)
+description: Describes security event 4953(F) Windows Firewall ignored a rule because it couldn't be parsed.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,7 +14,7 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 4953(F): Windows Firewall ignored a rule because it could not be parsed.
+# 4953(F): Windows Firewall ignored a rule because it couldn't be parsed.
@@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
-This event generates if Windows Firewall was not able to parse Windows Firewall rule for some reason.
+This event generates if Windows Firewall wasn't able to parse Windows Firewall rule for some reason.
It can happen if Windows Firewall rule registry entry was corrupted.
@@ -72,11 +72,11 @@ It can happen if Windows Firewall rule registry entry was corrupted.
- All
-- Domain,Public
+- Domain, Public
-- Domain,Private
+- Domain, Private
-- Private,Public
+- Private, Public
- Public
@@ -90,7 +90,7 @@ It can happen if Windows Firewall rule registry entry was corrupted.
- **ID** \[Type = UnicodeString\]: the unique identifier for ignored firewall rule.
- To see the unique ID of the rule, navigate to the “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, navigate to the “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
@@ -100,7 +100,7 @@ It can happen if Windows Firewall rule registry entry was corrupted.
## Security Monitoring Recommendations
-For 4953(F): Windows Firewall ignored a rule because it could not be parsed.
+For 4953(F): Windows Firewall ignored a rule because it couldn't be parsed.
- This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition. Typically this event indicates configuration issues, not security issues.
diff --git a/windows/security/threat-protection/auditing/event-4957.md b/windows/security/threat-protection/auditing/event-4957.md
index b83701e32b..0f2cc44b6b 100644
--- a/windows/security/threat-protection/auditing/event-4957.md
+++ b/windows/security/threat-protection/auditing/event-4957.md
@@ -1,6 +1,6 @@
---
-title: 4957(F) Windows Firewall did not apply the following rule. (Windows 10)
-description: Describes security event 4957(F) Windows Firewall did not apply the following rule.
+title: 4957(F) Windows Firewall didn't apply the following rule. (Windows 10)
+description: Describes security event 4957(F) Windows Firewall didn't apply the following rule.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,7 +14,7 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 4957(F): Windows Firewall did not apply the following rule.
+# 4957(F): Windows Firewall didn't apply the following rule.
@@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
-This event generates when Windows Firewall starts or apply new rule, and the rule cannot be applied for some reason.
+This event generates when Windows Firewall starts or apply new rule, and the rule can't be applied for some reason.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -69,21 +69,21 @@ This event generates when Windows Firewall starts or apply new rule, and the rul
- **ID** \[Type = UnicodeString\]: the unique identifier for not applied firewall rule.
- To see the unique ID of the rule you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you will see the list of Windows Firewall rule IDs (Name column) with parameters:
+ To see the unique ID of the rule, you need to navigate to “**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\SharedAccess\\Parameters\\FirewallPolicy\\FirewallRules”** registry key and you'll see the list of Windows Firewall rule IDs (Name column) with parameters:
-- **Name** \[Type = UnicodeString\]: the name of the rule which was not applied. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
+- **Name** \[Type = UnicodeString\]: the name of the rule that wasn't applied. You can see the name of Windows Firewall rule using Windows Firewall with Advanced Security management console (**wf.msc**), check “Name” column:
**Error Information:**
-- **Reason** \[Type = UnicodeString\]: the reason why the rule was not applied.
+- **Reason** \[Type = UnicodeString\]: the reason why the rule wasn't applied.
## Security Monitoring Recommendations
-For 4957(F): Windows Firewall did not apply the following rule.
+For 4957(F): Windows Firewall didn't apply the following rule.
- This event can be a sign of software issues, Windows Firewall registry errors or corruption, or Group Policy setting misconfigurations. We recommend monitoring this event and investigating the reason for the condition. Typically this event indicates configuration issues, not security issues.
diff --git a/windows/security/threat-protection/auditing/event-4958.md b/windows/security/threat-protection/auditing/event-4958.md
index 3fc2c85a83..5e6f8b57f9 100644
--- a/windows/security/threat-protection/auditing/event-4958.md
+++ b/windows/security/threat-protection/auditing/event-4958.md
@@ -1,6 +1,6 @@
---
-title: 4958(F) Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer. (Windows 10)
-description: Describes security event 4958(F) Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer.
+title: 4958(F) Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer. (Windows 10)
+description: Describes security event 4958(F) Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,18 +14,18 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 4958(F): Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer.
+# 4958(F): Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer.
-Windows Firewall with Advanced Security processed a rule that contains parameters that cannot be resolved on the local computer. The rule is therefore not enforceable on the computer and so is excluded from the runtime state of the firewall. This is not necessarily an error. Examine the rule for applicability on the computers to which it was applied.
+Windows Firewall with Advanced Security processed a rule that contains parameters that can't be resolved on the local computer. The rule is therefore not enforceable on the computer and so is excluded from the runtime state of the firewall. This exclusion isn't necessarily an error. Examine the rule for applicability on the computers to which it was applied.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md)
***Event Schema:***
-*Windows Firewall did not apply the following rule because the rule referred to items not configured on this computer:
+*Windows Firewall didn't apply the following rule because the rule referred to items not configured on this computer:
Rule Information:
%tID:%t%1
%tName:%t%2
diff --git a/windows/security/threat-protection/auditing/event-5030.md b/windows/security/threat-protection/auditing/event-5030.md
index 9216275f2d..86502afb98 100644
--- a/windows/security/threat-protection/auditing/event-5030.md
+++ b/windows/security/threat-protection/auditing/event-5030.md
@@ -19,9 +19,9 @@ ms.technology: windows-sec
Windows logs this event if the Windows Firewall service fails to start, or if it unexpectedly terminates. The error message indicates the cause of the service failure by including an error code in the text of the message.
-This event doesn't generate during Windows Firewall service failures if Windows Firewall policy is incorrect\\corrupted or one of the service dependencies was not started.
+This event doesn't generate during Windows Firewall service failures if Windows Firewall policy is incorrect\\corrupted or one of the service dependencies wasn't started.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other System Events](audit-other-system-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5031.md b/windows/security/threat-protection/auditing/event-5031.md
index b54933cde7..0e6d81e9ac 100644
--- a/windows/security/threat-protection/auditing/event-5031.md
+++ b/windows/security/threat-protection/auditing/event-5031.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates when an application was blocked from accepting incoming connections on the network by [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page).
-If you don’t have any firewall rules (Allow or Deny) in Windows Firewall for specific applications, you will get this event from [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page) layer, because by default this layer is denying any incoming connections.
+If you don’t have any firewall rules (Allow or Deny) in Windows Firewall for specific applications, you'll get this event from [Windows Filtering Platform](/windows/win32/fwp/windows-filtering-platform-start-page) layer, because by default this layer is denying any incoming connections.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -82,8 +82,8 @@ For 5031(F): The Windows Firewall Service blocked an application from accepting
- You can use this event to detect applications for which no Windows Firewall rules were created.
-- If you have a pre-defined application which should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
+- If you have a pre-defined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5038.md b/windows/security/threat-protection/auditing/event-5038.md
index dbb32f1459..44d9fafb84 100644
--- a/windows/security/threat-protection/auditing/event-5038.md
+++ b/windows/security/threat-protection/auditing/event-5038.md
@@ -1,6 +1,6 @@
---
-title: 5038(F) Code integrity determined that the image hash of a file is not valid. (Windows 10)
-description: Describes security event 5038(F) Code integrity determined that the image hash of a file is not valid.
+title: 5038(F) Code integrity determined that the image hash of a file isn't valid. (Windows 10)
+description: Describes security event 5038(F) Code integrity determined that the image hash of a file isn't valid.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,16 +14,16 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 5038(F): Code integrity determined that the image hash of a file is not valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
+# 5038(F): Code integrity determined that the image hash of a file isn't valid. The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
The file could be corrupt due to unauthorized modification or the invalid hash could indicate a potential disk device error.
-This event generates by [Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) feature, if signature of a file is not valid.
+This event generates by [Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) feature, if signature of a file isn't valid.
-Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
+Code Integrity is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it's loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/event-5039.md b/windows/security/threat-protection/auditing/event-5039.md
index 7194197d62..aec25c2291 100644
--- a/windows/security/threat-protection/auditing/event-5039.md
+++ b/windows/security/threat-protection/auditing/event-5039.md
@@ -19,9 +19,9 @@ ms.technology: windows-sec
This event should be generated when registry key was virtualized using [LUAFV](https://blogs.msdn.com/b/alexcarp/archive/2009/06/25/the-deal-with-luafv-sys.aspx).
-This event occurs very rarely during standard LUAFV registry key virtualization.
+This event occurs rarely during standard LUAFV registry key virtualization.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Registry](audit-registry.md)
@@ -59,7 +59,7 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
+- There's no recommendation for this event in this document.
diff --git a/windows/security/threat-protection/auditing/event-5051.md b/windows/security/threat-protection/auditing/event-5051.md
index 67f25e7071..530cebdbe3 100644
--- a/windows/security/threat-protection/auditing/event-5051.md
+++ b/windows/security/threat-protection/auditing/event-5051.md
@@ -19,9 +19,9 @@ ms.technology: windows-sec
This event should be generated when file was virtualized using [LUAFV](https://blogs.msdn.com/b/alexcarp/archive/2009/06/25/the-deal-with-luafv-sys.aspx).
-This event occurs very rarely during standard LUAFV file virtualization.
+This event occurs rarely during standard LUAFV file virtualization.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit File System](audit-file-system.md)
@@ -59,5 +59,5 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
+- There's no recommendation for this event in this document.
diff --git a/windows/security/threat-protection/auditing/event-5056.md b/windows/security/threat-protection/auditing/event-5056.md
index a0be07f3bf..b8d749b9fe 100644
--- a/windows/security/threat-protection/auditing/event-5056.md
+++ b/windows/security/threat-protection/auditing/event-5056.md
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for CNG troubleshooting.
+This event is used for CNG troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/event-5057.md b/windows/security/threat-protection/auditing/event-5057.md
index 8ef262994a..6f251535e5 100644
--- a/windows/security/threat-protection/auditing/event-5057.md
+++ b/windows/security/threat-protection/auditing/event-5057.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5057(F): A cryptographic primitive operation failed.
-This event generates in case of CNG primitive operation failure.
+This event generates if there's a CNG primitive operation failure.
For more information about Cryptographic Next Generation (CNG) visit these pages:
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/event-5058.md b/windows/security/threat-protection/auditing/event-5058.md
index eaa7c1b441..42a31d7a3a 100644
--- a/windows/security/threat-protection/auditing/event-5058.md
+++ b/windows/security/threat-protection/auditing/event-5058.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
-This event generates when an operation (read, write, delete, and so on) was performed on a file that contains a KSP key by using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs were used:
+This event generates when an operation (read, write, delete, and so on) was performed on a file that contains a KSP key by using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs was used:
- Microsoft Software Key Storage Provider
@@ -81,13 +81,13 @@ You can see these events, for example, during certificate renewal or export oper
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested key file operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested key file operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested key file operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -109,7 +109,7 @@ You can see these events, for example, during certificate renewal or export oper
- Microsoft Smart Card Key Storage Provider
-- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this typically has “**UNKNOWN**” value. Can also have one of the following values:
+- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this algorithm has “**UNKNOWN**” value. Can also have one of the following values:
- RSA – algorithm created by Ron Rivest, Adi Shamir, and Leonard Adleman.
@@ -129,7 +129,7 @@ You can see these events, for example, during certificate renewal or export oper
- ECDSA\_P521 – Elliptic Curve Digital Signature Algorithm with 521-bit key length.
-- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here is an output example:
+- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here's an output example:
diff --git a/windows/security/threat-protection/auditing/event-5060.md b/windows/security/threat-protection/auditing/event-5060.md
index e20a614013..b8f9fb0ef7 100644
--- a/windows/security/threat-protection/auditing/event-5060.md
+++ b/windows/security/threat-protection/auditing/event-5060.md
@@ -27,9 +27,9 @@ For more information about CNG, visit these pages:
-
-This event is mainly used for CNG troubleshooting.
+This event is used for CNG troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/event-5061.md b/windows/security/threat-protection/auditing/event-5061.md
index af59c9ccb8..58bcd9848d 100644
--- a/windows/security/threat-protection/auditing/event-5061.md
+++ b/windows/security/threat-protection/auditing/event-5061.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
***Event Description:***
-This event generates when a cryptographic operation (open key, create key, create key, and so on) was performed using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs were used:
+This event generates when a cryptographic operation (open key, create key, create key, and so on) was performed using a [Key Storage Provider](/windows/win32/seccertenroll/cng-key-storage-providers) (KSP). This event generates only if one of the following KSPs was used:
- Microsoft Software Key Storage Provider
@@ -78,13 +78,13 @@ This event generates when a cryptographic operation (open key, create key, creat
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested specific cryptographic operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested specific cryptographic operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested specific cryptographic operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -106,7 +106,7 @@ This event generates when a cryptographic operation (open key, create key, creat
- Microsoft Smart Card Key Storage Provider
-- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this typically has “**UNKNOWN**” value. Can also have one of the following values:
+- **Algorithm Name** \[Type = UnicodeString\]: the name of cryptographic algorithm through which the key was used or accessed. For “Read persisted key from file” operation, this algorithm has “**UNKNOWN**” value. Can also have one of the following values:
- RSA – algorithm created by Ron Rivest, Adi Shamir, and Leonard Adleman.
@@ -126,7 +126,7 @@ This event generates when a cryptographic operation (open key, create key, creat
- ECDSA\_P521 – Elliptic Curve Digital Signature Algorithm with 521-bit key length.
-- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here is an output example:
+- **Key Name** \[Type = UnicodeString\]: the name of the key (key container) with which operation was performed. For example, to get the list of **Key Names** for certificates for logged in user you can use “**certutil -store -user my**” command and check **Key Container** parameter in the output. Here's an output example:
diff --git a/windows/security/threat-protection/auditing/event-5063.md b/windows/security/threat-protection/auditing/event-5063.md
index 5038c7efce..ca597eccaf 100644
--- a/windows/security/threat-protection/auditing/event-5063.md
+++ b/windows/security/threat-protection/auditing/event-5063.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5063(S, F): A cryptographic provider operation was attempted.
-This event generates in BCryptUnregisterProvider() and BCryptRegisterProvider() functions. These are Cryptographic Next Generation (CNG) functions.
+This event generates in BCryptUnregisterProvider() and BCryptRegisterProvider() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic provider was registered or unregistered.
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5064.md b/windows/security/threat-protection/auditing/event-5064.md
index 58926d7958..ae83f4488b 100644
--- a/windows/security/threat-protection/auditing/event-5064.md
+++ b/windows/security/threat-protection/auditing/event-5064.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5064(S, F): A cryptographic context operation was attempted.
-This event generates in [BCryptCreateContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptcreatecontext)() and [BCryptDeleteContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptdeletecontext)() functions. These are Cryptographic Next Generation (CNG) functions.
+This event generates in [BCryptCreateContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptcreatecontext)() and [BCryptDeleteContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptdeletecontext)() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic context was created or deleted.
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5065.md b/windows/security/threat-protection/auditing/event-5065.md
index 7e24add6fe..e382f07e2f 100644
--- a/windows/security/threat-protection/auditing/event-5065.md
+++ b/windows/security/threat-protection/auditing/event-5065.md
@@ -16,8 +16,7 @@ ms.technology: windows-sec
# 5065(S, F): A cryptographic context modification was attempted.
-
-This event generates in [BCryptConfigureContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontext)() function. This is a Cryptographic Next Generation (CNG) function.
+This event generates in [BCryptConfigureContext](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontext)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when configuration information was changed for existing CNG context.
@@ -27,9 +26,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5066.md b/windows/security/threat-protection/auditing/event-5066.md
index 310525c71a..6a40bb0b06 100644
--- a/windows/security/threat-protection/auditing/event-5066.md
+++ b/windows/security/threat-protection/auditing/event-5066.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5066(S, F): A cryptographic function operation was attempted.
-This event generates in [BCryptAddContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptaddcontextfunction)() and [BCryptRemoveContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptremovecontextfunction)() functions. These are Cryptographic Next Generation (CNG) functions.
+This event generates in [BCryptAddContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptaddcontextfunction)() and [BCryptRemoveContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptremovecontextfunction)() functions. These functions are Cryptographic Next Generation (CNG) functions.
This event generates when cryptographic function was added or removed from the list of functions that are supported by an existing CNG context.
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5067.md b/windows/security/threat-protection/auditing/event-5067.md
index 509b5d140a..02b76446df 100644
--- a/windows/security/threat-protection/auditing/event-5067.md
+++ b/windows/security/threat-protection/auditing/event-5067.md
@@ -17,19 +17,19 @@ ms.technology: windows-sec
# 5067(S, F): A cryptographic function modification was attempted.
-This event generates in [BCryptConfigureContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontextfunction)() function. This is a Cryptographic Next Generation (CNG) function.
+This event generates in [BCryptConfigureContextFunction](/windows/win32/api/bcrypt/nf-bcrypt-bcryptconfigurecontextfunction)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when configuration information for the cryptographic function of an existing CNG context was changed.
-For more information about Cryptographic Next Generation (CNG) visit these pages:
+For more information about Cryptographic Next Generation (CNG), visit these pages:
-
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5068.md b/windows/security/threat-protection/auditing/event-5068.md
index 1214a053db..ed2e8582db 100644
--- a/windows/security/threat-protection/auditing/event-5068.md
+++ b/windows/security/threat-protection/auditing/event-5068.md
@@ -17,17 +17,17 @@ ms.technology: windows-sec
# 5068(S, F): A cryptographic function provider operation was attempted.
-This event generates in BCryptAddContextFunctionProvider() and BCryptRemoveContextFunctionProvider() functions. These are Cryptographic Next Generation (CNG) functions.
+This event generates in BCryptAddContextFunctionProvider() and BCryptRemoveContextFunctionProvider() functions. These functions are Cryptographic Next Generation (CNG) functions.
-For more information about Cryptographic Next Generation (CNG) visit these pages:
+For more information about Cryptographic Next Generation (CNG), visit these pages:
-
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5069.md b/windows/security/threat-protection/auditing/event-5069.md
index dadbcf3347..fc14219958 100644
--- a/windows/security/threat-protection/auditing/event-5069.md
+++ b/windows/security/threat-protection/auditing/event-5069.md
@@ -17,19 +17,19 @@ ms.technology: windows-sec
# 5069(S, F): A cryptographic function property operation was attempted.
-This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This is a Cryptographic Next Generation (CNG) function.
+This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was added or removed.
-For more information about Cryptographic Next Generation (CNG) visit these pages:
+For more information about Cryptographic Next Generation (CNG), visit these pages:
-
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
From 6b2d7ef2092d81cd8debde881a5ba0491b7f7105 Mon Sep 17 00:00:00 2001
From: Nick White <104782157+nicholasswhite@users.noreply.github.com>
Date: Fri, 17 Jun 2022 15:32:57 -0400
Subject: [PATCH 005/299] fix MicrosoftDocs/windows-itpro-docs#7147
---
.../access-control/local-accounts.md | 87 ++++++++++---------
1 file changed, 44 insertions(+), 43 deletions(-)
diff --git a/windows/security/identity-protection/access-control/local-accounts.md b/windows/security/identity-protection/access-control/local-accounts.md
index 655ef0f5b4..bcbb8ba3a5 100644
--- a/windows/security/identity-protection/access-control/local-accounts.md
+++ b/windows/security/identity-protection/access-control/local-accounts.md
@@ -14,7 +14,7 @@ ms.collection:
- highpri
ms.topic: article
ms.localizationpriority: medium
-ms.date: 02/28/2019
+ms.date: 06/17/2022
---
# Local Accounts
@@ -25,13 +25,13 @@ ms.date: 02/28/2019
- Windows Server 2019
- Windows Server 2016
-This reference topic for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
+This reference article for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
## About local user accounts
Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
-This topic describes the following:
+This article describes the following:
- [Default local user accounts](#sec-default-accounts)
@@ -61,9 +61,9 @@ For information about security principals, see [Security Principals](security-pr
The default local user accounts are built-in accounts that are created automatically when you install Windows.
-After Windows is installed, the default local user accounts cannot be removed or deleted. In addition, default local user accounts do not provide access to network resources.
+After Windows is installed, the default local user accounts can't be removed or deleted. In addition, default local user accounts don't provide access to network resources.
-Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this topic.
+Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this article.
Default local user accounts are described in the following sections.
@@ -73,23 +73,23 @@ The default local Administrator account is a user account for the system adminis
The Administrator account has full control of the files, directories, services, and other resources on the local computer. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can take control of local resources at any time simply by changing the user rights and permissions.
-The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled.
+The default Administrator account can't be deleted or locked out, but it can be renamed or disabled.
From Windows 10, Windows 11 and Windows Server 2016, Windows setup disables the built-in Administrator account and creates another local account that is a member of the Administrators group. Members of the Administrators groups can run apps with elevated permissions without using the **Run as Administrator** option. Fast User Switching is more secure than using Runas or different-user elevation.
**Account group membership**
-By default, the Administrator account is installed as a member of the Administrators group on the server. It is a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
+By default, the Administrator account is installed as a member of the Administrators group on the server. It's a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
-The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed.
+The Administrator account can't be deleted or removed from the Administrators group, but it can be renamed.
**Security considerations**
-Because the Administrator account is known to exist on many versions of the Windows operating system, it is a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.
+Because the Administrator account is known to exist on many versions of the Windows operating system, it's a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.
You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see [Disable or activate a local user account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732112(v=ws.11)) and [Rename a local user account](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc725595(v=ws.11)).
-As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Do not use the Administrator account to sign in to your computer unless it is entirely necessary. For more information, see [Run a program with administrative credentials](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732200(v=ws.11)).
+As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Don't use the Administrator account to sign in to your computer unless it's entirely necessary. For more information, see [Run a program with administrative credentials](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732200(v=ws.11)).
In comparison, on the Windows client operating system, a user with a local user account that has Administrator rights is considered the system administrator of the client computer. The first local user account that is created during installation is placed in the local Administrators group. However, when multiple users run as local administrators, the IT staff has no control over these users or their client computers.
@@ -103,7 +103,7 @@ In this case, Group Policy can be used to enable secure settings that can contro
### Guest account
-The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who do not have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it is a security risk. For this reason, it is a best practice to leave the Guest account disabled, unless its use is entirely necessary.
+The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who don't have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it's a security risk. For this reason, it's a best practice to leave the Guest account disabled, unless its use is entirely necessary.
**Account group membership**
@@ -111,26 +111,26 @@ By default, the Guest account is the only member of the default Guests group (SI
**Security considerations**
-When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
+When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account shouldn't be used over the network and made accessible to other computers.
-In addition, the guest user in the Guest account should not be able to view the event logs. After the Guest account is enabled, it is a best practice to monitor the Guest account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
+In addition, the guest user in the Guest account shouldn't be able to view the event logs. After the Guest account is enabled, it's a best practice to monitor the Guest account frequently to ensure that other users can't use services and other resources. This includes resources that were unintentionally left available by a previous user.
## HelpAssistant account (installed with a Remote Assistance session)
The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
-HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user’s invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
+HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it's initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the users invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
**Security considerations**
The SIDs that pertain to the default HelpAssistant account include:
-- SID: S-1-5-<domain>-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
+- SID: S-1-5-<domain>-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note: In Windows Server 2008, Remote Desktop Services are called Terminal Services.
- SID: S-1-5-<domain>-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
-For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
+For the Windows Server operating system, Remote Assistance is an optional component that isn't installed by default. You must install Remote Assistance before it can be used.
For details about the HelpAssistant account attributes, see the following table.
@@ -144,14 +144,14 @@ For details about the HelpAssistant account attributes, see the following table.
|Default members|None|
|Default member of|Domain Guests
Guests|
|Protected by ADMINSDHOLDER?|No|
-|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
+|Safe to move out of default container?|Can be moved out, but we don't recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
### DefaultAccount
The DefaultAccount, also known as the Default System Managed Account (DSMA), is a built-in account introduced in Windows 10 version 1607 and Windows Server 2016.
The DSMA is a well-known user account type.
-It is a user neutral account that can be used to run processes that are either multi-user aware or user-agnostic.
+It's a user neutral account that can be used to run processes that are either multi-user aware or user-agnostic.
The DSMA is disabled by default on the desktop SKUs (full windows SKUs) and WS 2016 with the Desktop.
The DSMA has a well-known RID of 503. The security identifier (SID) of the DSMA will thus have a well-known SID in the following format: S-1-5-21-\-503
@@ -171,24 +171,24 @@ Today, Xbox automatically signs in as Guest account and all apps run in this con
All the apps are multi-user-aware and respond to events fired by user manager.
The apps run as the Guest account.
-Similarly, Phone auto logs in as a “DefApps” account which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
+Similarly, Phone auto logs in as a “DefApps” account, which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
In the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context different from that of the users.
For this purpose, the system creates DSMA.
#### How the DefaultAccount gets created on domain controllers
-If the domain was created with domain controllers that run Windows Server 2016, the DefaultAccount will exist on all domain controllers in the domain.
-If the domain was created with domain controllers that run an earlier version of Windows Server, the DefaultAccount will be created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount will then be replicated to all other domain controllers in the domain.
+If the domain was created with domain controllers running Windows Server 2016, the DefaultAccount will exist on all domain controllers in the domain.
+If the domain was created with domain controllers running an earlier version of Windows Server, the DefaultAccount will be created after the PDC Emulator role is transferred to a domain controller that runs Windows Server 2016. The DefaultAccount will then be replicated to all other domain controllers in the domain.
#### Recommendations for managing the Default Account (DSMA)
-Microsoft does not recommend changing the default configuration, where the account is disabled. There is no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
+Microsoft doesn't recommend changing the default configuration, where the account is disabled. There's no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
## Default local system accounts
### SYSTEM
-The SYSTEM account is used by the operating system and by services that run under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account’s user rights. It is an internal account that does not show up in User Manager, and it cannot be added to any groups.
+The SYSTEM account is used by the operating system and by services running under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account’s user rights. It's an internal account that doesn't show up in User Manager, and it can't be added to any groups.
On the other hand, the SYSTEM account does appear on an NTFS file system volume in File Manager in the **Permissions** portion of the **Security** menu. By default, the SYSTEM account is granted Full Control permissions to all files on an NTFS volume. Here the SYSTEM account has the same functional rights and permissions as the Administrator account.
@@ -204,22 +204,22 @@ The LOCAL SERVICE account is a predefined local account used by the service cont
## How to manage local user accounts
-The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
+The default local user accounts, and the local user accounts you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
-You can use Local Users and Groups to assign rights and permissions on the local server, and that server only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
+You can use Local Users and Groups to assign rights and permissions on only the local server to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
-You cannot use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that are not domain controllers on the network.
+You can't use Local Users and Groups on a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that aren't domain controllers on the network.
> [!NOTE]
> You use Active Directory Users and Computers to manage users and groups in Active Directory.
-You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using a variety of PowerShell cmdlets and other scripting technologies.
+You can also manage local users by using NET.EXE USER and manage local groups by using NET.EXE LOCALGROUP, or by using various PowerShell cmdlets and other scripting technologies.
### Restrict and protect local accounts with administrative rights
-An administrator can use a number of approaches to prevent malicious users from using stolen credentials, such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights; this is also called "lateral movement".
+An administrator can use many approaches to prevent malicious users from using stolen credentials such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights. This is also called "lateral movement".
-The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks, for example, to browse the Internet, send email, or use a word processor. When you want to perform an administrative task, for example, to install a new program or to change a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
+The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks. For example, use a standard account to browse the Internet, send email, or use a word processor. When you want to perform administrative tasks such as installing a new program or changing a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
The other approaches that can be used to restrict and protect user accounts with administrative rights include:
@@ -244,7 +244,7 @@ UAC makes it possible for an account with administrative rights to be treated as
In addition, UAC can require administrators to specifically approve applications that make system-wide changes before those applications are granted permission to run, even in the administrator's user session.
-For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it is issued a standard user token with no administrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon cannot access administrative shares such as C$, or ADMIN$, or perform any remote administration.
+For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it's issued a standard user token with no administrative rights, but without the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon can't access administrative shares such as C$, or ADMIN$, or perform any remote administration.
For more information about UAC, see [User Account Control](/windows/access-protection/user-account-control/user-account-control-overview).
@@ -253,7 +253,8 @@ The following table shows the Group Policy and registry settings that are used t
|No.|Setting|Detailed Description|
|--- |--- |--- |
||Policy location|Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options|
-|1|Policy name|[User Account Control: Run all administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode)|
+
+|1|Policy name|[User Account Control: Admin Approval Mode for the Built-in Administrator account](/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)|
||Policy setting|Enabled|
|2|Policy location|Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options|
||Policy name|[User Account Control: Run all administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode)|
@@ -285,7 +286,7 @@ The following table shows the Group Policy and registry settings that are used t

-6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by doing the following:
+6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by following these steps:
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\, and > **Security Options**.
@@ -293,7 +294,7 @@ The following table shows the Group Policy and registry settings that are used t
3. Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** > **Enabled** > **OK**.
-7. Ensure that the local account restrictions are applied to network interfaces by doing the following:
+7. Ensure that the local account restrictions are applied to network interfaces by following these steps:
1. Navigate to Computer Configuration\\Preferences and Windows Settings, and > **Registry**.
@@ -305,7 +306,7 @@ The following table shows the Group Policy and registry settings that are used t
4. Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
- 5. Click (**…**), browse to the following location for **Key Path** > **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
+ 5. Select (**…**), browse to the following location for **Key Path** > **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
6. In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
@@ -325,7 +326,7 @@ The following table shows the Group Policy and registry settings that are used t

- 3. Select the GPO that you just created, and > **OK**.
+ 3. Select the GPO that you created, and > **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
@@ -335,7 +336,7 @@ The following table shows the Group Policy and registry settings that are used t
### Deny network logon to all local Administrator accounts
-Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that the credentials for local accounts that are stolen from a compromised operating system cannot be used to compromise additional computers that use the same credentials.
+Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that stolen credentials for local accounts from a compromised operating system can't be used to compromise other computers that use the same credentials.
> [!NOTE]
> To perform this procedure, you must first identify the name of the local, default Administrator account, which might not be the default user name "Administrator", and any other accounts that are members of the local Administrators group.
@@ -361,7 +362,7 @@ The following table shows the Group Policy settings that are used to deny networ
3. In the console tree, right-click **Group Policy Objects**, and > **New**.
-4. In the **New GPO** dialog box, type <**gpo\_name**>, and then > **OK** where *gpo\_name* is the name of the new GPO indicates that it is being used to restrict the local administrative accounts from interactively signing in to the computer.
+4. In the **New GPO** dialog box, type <**gpo\_name**>, and then > **OK** where *gpo\_name* is the name of the new GPO indicates that it's being used to restrict the local administrative accounts from interactively signing in to the computer.

@@ -375,15 +376,15 @@ The following table shows the Group Policy settings that are used to deny networ
2. Double-click **Deny access to this computer from the network**.
- 3. Click **Add User or Group**, type **Local account and member of Administrators group**, and > **OK**.
+ 3. Select **Add User or Group**, type **Local account and member of Administrators group**, and > **OK**.
7. Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
- 1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then click **User Rights Assignment**.
+ 1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then select **User Rights Assignment**.
2. Double-click **Deny log on through Remote Desktop Services**.
- 3. Click **Add User or Group**, type **Local account and member of Administrators group**, and > **OK**.
+ 3. Select **Add User or Group**, type **Local account and member of Administrators group**, and > **OK**.
8. Link the GPO to the first **Workstations** OU as follows:
@@ -391,7 +392,7 @@ The following table shows the Group Policy settings that are used to deny networ
2. Right-click the **Workstations** OU, and > **Link an existing GPO**.
- 3. Select the GPO that you just created, and > **OK**.
+ 3. Select the GPO that you created, and > **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
@@ -405,9 +406,9 @@ The following table shows the Group Policy settings that are used to deny networ
### Create unique passwords for local accounts with administrative rights
-Passwords should be unique per individual account. While this is generally true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
+Passwords should be unique per individual account. While it's true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
-Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hampers the ability of malicious users to use password hashes of those accounts to compromise other computers.
+Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hamper the ability of malicious users to use password hashes of those accounts to compromise other computers.
Passwords can be randomized by:
From 21dc3f138bbe7c1d7fd87beb029408a2d61436f2 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Mon, 20 Jun 2022 17:28:48 +0530
Subject: [PATCH 006/299] Acrolinx Enhancement Effort
---
.../threat-protection/auditing/event-5070.md | 6 ++---
.../threat-protection/auditing/event-5136.md | 22 +++++++++----------
.../threat-protection/auditing/event-5137.md | 14 ++++++------
.../threat-protection/auditing/event-5138.md | 16 +++++++-------
.../threat-protection/auditing/event-5139.md | 14 ++++++------
.../threat-protection/auditing/event-5140.md | 12 +++++-----
.../threat-protection/auditing/event-5141.md | 14 ++++++------
.../threat-protection/auditing/event-5143.md | 20 ++++++++---------
8 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/windows/security/threat-protection/auditing/event-5070.md b/windows/security/threat-protection/auditing/event-5070.md
index 5763a4dba1..f21b182de2 100644
--- a/windows/security/threat-protection/auditing/event-5070.md
+++ b/windows/security/threat-protection/auditing/event-5070.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5070(S, F): A cryptographic function property modification was attempted.
-This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This is a Cryptographic Next Generation (CNG) function.
+This event generates in [BCryptSetContextFunctionProperty](/windows/win32/api/bcrypt/nf-bcrypt-bcryptsetcontextfunctionproperty)() function. This function is a Cryptographic Next Generation (CNG) function.
This event generates when named property for a cryptographic function in an existing CNG context was updated.
@@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
-
-This event is mainly used for Cryptographic Next Generation (CNG) troubleshooting.
+This event is used for Cryptographic Next Generation (CNG) troubleshooting.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Policy Change Events](audit-other-policy-change-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5136.md b/windows/security/threat-protection/auditing/event-5136.md
index 2d8d45b93a..26b6d241f5 100644
--- a/windows/security/threat-protection/auditing/event-5136.md
+++ b/windows/security/threat-protection/auditing/event-5136.md
@@ -27,7 +27,7 @@ This event generates every time an Active Directory object is modified.
To generate this event, the modified object must have an appropriate entry in [SACL](/windows/win32/secauthz/access-control-lists): the “**Write”** action auditing for specific attributes.
-For a change operation you will typically see two 5136 events for one action, with different **Operation\\Type** fields: “Value Deleted” and then “Value Added”. “Value Deleted” event typically contains previous value and “Value Added” event contains new value.
+For a change operation, you'll typically see two 5136 events for one action, with different **Operation\\Type** fields: “Value Deleted” and then “Value Added”. “Value Deleted” event typically contains previous value and “Value Added” event contains new value.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -82,13 +82,13 @@ For a change operation you will typically see two 5136 events for one action, wi
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify object” operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -142,13 +142,13 @@ For a change operation you will typically see two 5136 events for one action, wi
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- - Take first 3 sections a6b34ab5-551b-4626.
+ - Take first three sections a6b34ab5-551b-4626.
- - For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
+ - For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- - Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
+ - Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- - Delete - : b54ab3a61b552646b8ee2b36b3ee6672
+ - Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@@ -180,7 +180,7 @@ For a change operation you will typically see two 5136 events for one action, wi
> **Note** [LDAP Display Name](/windows/win32/adschema/a-ldapdisplayname) is the name used by LDAP clients, such as the ADSI LDAP provider, to read and write the attribute by using the LDAP protocol.
-- **Syntax (OID)** \[Type = UnicodeString\]**:** The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. Whether the attribute value must be a string, a number, or a unit of time is also defined. Every attribute of every object is associated with exactly one syntax. The syntaxes are not represented as objects in the schema, but they are programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined.
+- **Syntax (OID)** \[Type = UnicodeString\]**:** The syntax for an attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. Whether the attribute value must be a string, a number, or a unit of time is also defined. Every attribute of every object is associated with exactly one syntax. The syntaxes aren't represented as objects in the schema, but they're programmed to be understood by Active Directory. The allowable syntaxes in Active Directory are predefined.
| OID | Syntax Name | Description |
|----------|--------------------------------------------|----------------------------------------------------------|
@@ -189,7 +189,7 @@ For a change operation you will typically see two 5136 events for one action, wi
| 2.5.5.2 | String(Object-Identifier) | The object identifier. |
| 2.5.5.3 | Case-Sensitive String | General String. |
| 2.5.5.4 | CaseIgnoreString(Teletex) | Differentiates uppercase and lowercase. |
-| 2.5.5.5 | String(Printable), String(IA5) | Teletex. Does not differentiate uppercase and lowercase. |
+| 2.5.5.5 | String(Printable), String(IA5) | Teletex. Doesn't differentiate uppercase and lowercase. |
| 2.5.5.6 | String(Numeric) | Printable string or IA5-String. |
| 2.5.5.7 | Object(DN-Binary) | Both character sets are case-sensitive. |
| 2.5.5.8 | Boolean | A sequence of digits. |
@@ -205,7 +205,7 @@ For a change operation you will typically see two 5136 events for one action, wi
> Table 10. LDAP Attribute Syntax OIDs.
-- **Value** \[Type = UnicodeString\]: the value which was added or deleted, depending on the **Operation\\Type** field.
+- **Value** \[Type = UnicodeString\]: the value that was added or deleted, depending on the **Operation\\Type** field.
**Operation:**
@@ -235,4 +235,4 @@ For 5136(S): A directory service object was modified.
- If you need to monitor modifications to specific Active Directory attributes, monitor for **LDAP Display Name** field with specific attribute name.
-- It is better to monitor **Operation\\Type = Value Added** events, because you will see the new value of attribute. At the same time you can correlate to previous **Operation\\Type = Value Deleted** event with the same **Correlation ID** to see the previous value.
\ No newline at end of file
+- It's better to monitor **Operation\\Type = Value Added** events, because you'll see the new value of attribute. At the same time, you can correlate to previous **Operation\\Type = Value Deleted** event with the same **Correlation ID** to see the previous value.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5137.md b/windows/security/threat-protection/auditing/event-5137.md
index f5b8f335af..0a90a9f3a9 100644
--- a/windows/security/threat-protection/auditing/event-5137.md
+++ b/windows/security/threat-protection/auditing/event-5137.md
@@ -76,13 +76,13 @@ This event only generates if the parent object has a particular entry in its [SA
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested the “create object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested the “create object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create object” operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -136,13 +136,13 @@ This event only generates if the parent object has a particular entry in its [SA
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- - Take first 3 sections a6b34ab5-551b-4626.
+ - Take first three sections a6b34ab5-551b-4626.
- - For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
+ - For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- - Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
+ - Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- - Delete - : b54ab3a61b552646b8ee2b36b3ee6672
+ - Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@@ -182,4 +182,4 @@ For 5137(S): A directory service object was created.
- If you need to monitor creation of Active Directory objects with specific classes, monitor for **Class** field with specific class name. For example, we recommend that you monitor all new group policy objects creations: **groupPolicyContainer** class.
-- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5137](event-5137.md). There is no reason to audit all creation events for all types of Active Directory objects; find the most important locations (organizational units, folders, etc.) and monitor for creation of specific classes only (user, computer, group, etc.).
\ No newline at end of file
+- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5137](event-5137.md). There's no reason to audit all creation events for all types of Active Directory objects; find the most important locations (organizational units, folders, etc.) and monitor for creation of specific classes only (user, computer, group, etc.).
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5138.md b/windows/security/threat-protection/auditing/event-5138.md
index 93dac293aa..0757dcd92c 100644
--- a/windows/security/threat-protection/auditing/event-5138.md
+++ b/windows/security/threat-protection/auditing/event-5138.md
@@ -77,13 +77,13 @@ This event only generates if the container to which the Active Directory object
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested that the object be undeleted or restored. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested that the object be undeleted or restored. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** name of account that requested that the object be undeleted or restored.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -105,7 +105,7 @@ This event only generates if the container to which the Active Directory object
**Object:**
-- **Old DN** \[Type = UnicodeString\]: Old distinguished name of undeleted object. It will points to [Active Directory Recycle Bin](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392261(v=ws.10)) folder, in case if it was restored from it.
+- **Old DN** \[Type = UnicodeString\]: Old distinguished name of undeleted object. It will point to [Active Directory Recycle Bin](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd392261(v=ws.10)) folder, in case if it was restored from it.
> **Note** The LDAP API references an LDAP object by its **distinguished name (DN)**. A DN is a sequence of relative distinguished names (RDN) connected by commas.
>
@@ -139,13 +139,13 @@ This event only generates if the container to which the Active Directory object
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- - Take first 3 sections a6b34ab5-551b-4626.
+ - Take first three sections a6b34ab5-551b-4626.
- - For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
+ - For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- - Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
+ - Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- - Delete - : b54ab3a61b552646b8ee2b36b3ee6672
+ - Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@@ -185,4 +185,4 @@ For 5138(S): A directory service object was undeleted.
- If you need to monitor undelete operations (restoration) of Active Directory objects with specific classes, monitor for **Class** field with specific class name.
-- It may be a good idea to monitor all undelete events, because the operation is not performed very often. Confirm that there is a reason for the object to be undeleted.
\ No newline at end of file
+- It may be a good idea to monitor all undelete events, because the operation isn't performed often. Confirm that there's a reason for the object to be undeleted.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5139.md b/windows/security/threat-protection/auditing/event-5139.md
index 00145f3a61..eabd06efdf 100644
--- a/windows/security/threat-protection/auditing/event-5139.md
+++ b/windows/security/threat-protection/auditing/event-5139.md
@@ -77,13 +77,13 @@ This event only generates if the destination object has a particular entry in it
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested the “move object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested the “move object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “move object” operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -139,13 +139,13 @@ This event only generates if the destination object has a particular entry in it
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- - Take first 3 sections a6b34ab5-551b-4626.
+ - Take first three sections a6b34ab5-551b-4626.
- - For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
+ - For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- - Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
+ - Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- - Delete - : b54ab3a61b552646b8ee2b36b3ee6672
+ - Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@@ -185,4 +185,4 @@ For 5139(S): A directory service object was moved.
- If you need to monitor movement of Active Directory objects with specific classes, monitor for **Class** field with specific class name.
-- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5139](event-5139.md). There is no reason to audit all movement events for all types of Active Directory objects, you need to find the most important locations (organizational units, folders, etc.) and monitor for movement of specific classes only to these locations (user, computer, group, etc.).
\ No newline at end of file
+- You must set correct auditing access lists (SACLs) for specific classes within Active Directory container to get [5139](event-5139.md). There's no reason to audit all movement events for all types of Active Directory objects, you need to find the most important locations (organizational units, folders, etc.) and monitor for movement of specific classes only to these locations (user, computer, group, etc.).
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5140.md b/windows/security/threat-protection/auditing/event-5140.md
index 067637aa9b..b5ae516ec7 100644
--- a/windows/security/threat-protection/auditing/event-5140.md
+++ b/windows/security/threat-protection/auditing/event-5140.md
@@ -78,13 +78,13 @@ This event generates once per session, when first access attempt was made.
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -120,7 +120,7 @@ This event generates once per session, when first access attempt was made.
- ::1 or 127.0.0.1 means localhost.
-- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port which was used from remote or local machine to request the access.
+- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port that was used from remote or local machine to request the access.
- 0 for local access attempts.
@@ -134,7 +134,7 @@ This event generates once per session, when first access attempt was made.
- **Access Mask** \[Type = HexInt32\]: the sum of hexadecimal values of requested access rights. See “Table 13. File access codes.” for different hexadecimal values for access rights. Has always “**0x1**” value for this event.
-- **Accesses** \[Type = UnicodeString\]: the list of access rights which were requested by **Subject\\Security ID**. These access rights depend on **Object Type**. Has always “**ReadData (or ListDirectory)**” value for this event.
+- **Accesses** \[Type = UnicodeString\]: the list of access rights that were requested by **Subject\\Security ID**. These access rights depend on **Object Type**. Has always “**ReadData (or ListDirectory)**” value for this event.
## Security Monitoring Recommendations
@@ -144,9 +144,9 @@ For 5140(S, F): A network share object was accessed.
- If you have high-value computers for which you need to monitor all access to all shares or specific shares (“**Share Name**”), monitor this event. For example, you could monitor share **C$** on domain controllers.
-- Monitor this event if the **Network Information\\Source Address** is not from your internal IP range.
+- Monitor this event if the **Network Information\\Source Address** isn't from your internal IP range.
-- Monitor this event if the **Network Information\\Source Address** should not be able to connect with the specific computer (**Computer:**).
+- Monitor this event if the **Network Information\\Source Address** shouldn't be able to connect with the specific computer (**Computer:**).
- If you need to monitor access attempts to local shares from a specific IP address (“**Network Information\\Source Address”)**, use this event.
diff --git a/windows/security/threat-protection/auditing/event-5141.md b/windows/security/threat-protection/auditing/event-5141.md
index f69e095286..e63227b1ad 100644
--- a/windows/security/threat-protection/auditing/event-5141.md
+++ b/windows/security/threat-protection/auditing/event-5141.md
@@ -77,13 +77,13 @@ This event only generates if the deleted object has a particular entry in its [S
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete object” operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -137,13 +137,13 @@ This event only generates if the deleted object has a particular entry in its [S
- We have this GUID to search for: a6b34ab5-551b-4626-b8ee-2b36b3ee6672
- - Take first 3 sections a6b34ab5-551b-4626.
+ - Take first three sections a6b34ab5-551b-4626.
- - For each of these 3 sections you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
+ - For each of these three sections, you need to change (Invert) the order of bytes, like this b54ab3a6-1b55-2646
- - Add the last 2 sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
+ - Add the last two sections without transformation: b54ab3a6-1b55-2646-b8ee-2b36b3ee6672
- - Delete - : b54ab3a61b552646b8ee2b36b3ee6672
+ - Delete: b54ab3a61b552646b8ee2b36b3ee6672
- Divide bytes with backslashes: \\b5\\4a\\b3\\a6\\1b\\55\\26\\46\\b8\\ee\\2b\\36\\b3\\ee\\66\\72
@@ -193,4 +193,4 @@ For 5141(S): A directory service object was deleted.
- If you need to monitor deletion of Active Directory objects with specific classes, monitor for **Class** field with specific class name. For example, we recommend that you monitor for group policy objects deletions: **groupPolicyContainer** class.
-- If you need to monitor deletion of specific Active Directory objects, monitor for **DN** field with specific object name. For example, if you have critical Active Directory objects which should not be deleted, monitor for their deletion.
\ No newline at end of file
+- If you need to monitor deletion of specific Active Directory objects, monitor for **DN** field with specific object name. For example, if you have critical Active Directory objects that shouldn't be deleted, monitor for their deletion.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5143.md b/windows/security/threat-protection/auditing/event-5143.md
index 636a19a1bd..e533127f2a 100644
--- a/windows/security/threat-protection/auditing/event-5143.md
+++ b/windows/security/threat-protection/auditing/event-5143.md
@@ -78,13 +78,13 @@ This event generates every time network share object was modified.
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested the “modify network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify network share object” operation.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -120,9 +120,9 @@ This event generates every time network share object was modified.
-- **Old Remark** \[Type = UnicodeString\]: the old value of network share “**Comments:**” field. Has “**N/A**” value if it is not set.
+- **Old Remark** \[Type = UnicodeString\]: the old value of network share “**Comments:**” field. Has “**N/A**” value if it isn't set.
-- **New Remark** \[Type = UnicodeString\]: the new value of network share “**Comments:**” field. Has “**N/A**” value if it is not set.
+- **New Remark** \[Type = UnicodeString\]: the new value of network share “**Comments:**” field. Has “**N/A**” value if it isn't set.
- **Old MaxUsers** \[Type = HexInt32\]: old hexadecimal value of “**Limit the number of simultaneous user to:**” field. Has “**0xFFFFFFFF**” value if the number of connections is unlimited.
@@ -155,7 +155,7 @@ This event generates every time network share object was modified.
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
-| "BO" | Backup operators | "NU" | Network logon user |
+| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@@ -167,7 +167,7 @@ This event generates every time network share object was modified.
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
-| "WD" | Everyone | "SU" | Service logon user |
+| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@@ -187,7 +187,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
-"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
+"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@@ -213,7 +213,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
-"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
+"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@@ -224,7 +224,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
-- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
+- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@@ -246,7 +246,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
-- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
+- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: , .
From 07b07c29209c39a2d82b64c73c0eb6600eadb7ad Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Mon, 20 Jun 2022 19:11:24 +0530
Subject: [PATCH 007/299] Acrolinx enhancement effort
---
.../threat-protection/auditing/event-5145.md | 30 +++++++++----------
.../threat-protection/auditing/event-5148.md | 4 +--
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/windows/security/threat-protection/auditing/event-5145.md b/windows/security/threat-protection/auditing/event-5145.md
index 9c980ce0f3..1368fde95e 100644
--- a/windows/security/threat-protection/auditing/event-5145.md
+++ b/windows/security/threat-protection/auditing/event-5145.md
@@ -78,13 +78,13 @@ This event generates every time network share object (file or folder) was access
**Subject:**
-- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
+- **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID can't be resolved, you'll see the source data in the event.
> **Note** A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](/windows/access-protection/access-control/security-identifiers).
- **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -120,7 +120,7 @@ This event generates every time network share object (file or folder) was access
- ::1 or 127.0.0.1 means localhost.
-- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port which was used from remote or local machine to request the access.
+- **Source Port** \[Type = UnicodeString\]: source TCP or UDP port that was used from remote or local machine to request the access.
- 0 for local access attempts.
@@ -136,7 +136,7 @@ This event generates every time network share object (file or folder) was access
- **Access Mask** \[Type = HexInt32\]: the sum of hexadecimal values of requested access rights. See “Table 13. File access codes.” for different hexadecimal values for access rights.
-- **Accesses** \[Type = UnicodeString\]: the list of access rights which were requested by **Subject\\Security ID**. These access rights depend on **Object Type**.
+- **Accesses** \[Type = UnicodeString\]: the list of access rights that were requested by **Subject\\Security ID**. These access rights depend on **Object Type**.
## Table of file access codes
@@ -144,10 +144,10 @@ This event generates every time network share object (file or folder) was access
|-----------------------------------------------------------|----------------------------|---------------|
| ReadData (or ListDirectory) | 0x1,
%%4416 | **ReadData -** For a file object, the right to read the corresponding file data. For a directory object, the right to read the corresponding directory data.
**ListDirectory -** For a directory, the right to list the contents of the directory. |
| WriteData (or AddFile) | 0x2,
%%4417 | **WriteData -** For a file object, the right to write data to the file. For a directory object, the right to create a file in the directory (**FILE\_ADD\_FILE**).
**AddFile -** For a directory, the right to create a file in the directory. |
-| AppendData (or AddSubdirectory or CreatePipeInstance) | 0x4,
%%4418 | **AppendData -** For a file object, the right to append data to the file. (For local files, write operations will not overwrite existing data if this flag is specified without **FILE\_WRITE\_DATA**.) For a directory object, the right to create a subdirectory (**FILE\_ADD\_SUBDIRECTORY**).
**AddSubdirectory -** For a directory, the right to create a subdirectory.
**CreatePipeInstance -** For a named pipe, the right to create a pipe. |
+| AppendData (or AddSubdirectory or CreatePipeInstance) | 0x4,
%%4418 | **AppendData -** For a file object, the right to append data to the file. (For local files, write operations won't overwrite existing data if this flag is specified without **FILE\_WRITE\_DATA**.) For a directory object, the right to create a subdirectory (**FILE\_ADD\_SUBDIRECTORY**).
**AddSubdirectory -** For a directory, the right to create a subdirectory.
**CreatePipeInstance -** For a named pipe, the right to create a pipe. |
| ReadEA | 0x8,
%%4419 | The right to read extended file attributes. |
| WriteEA | 0x10,
%%4420 | The right to write extended file attributes. |
-| Execute/Traverse | 0x20,
%%4421 | **Execute** - For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.
**Traverse -** For a directory, the right to traverse the directory. By default, users are assigned the **BYPASS\_TRAVERSE\_CHECKING** [privilege](/windows/win32/secauthz/privileges), which ignores the **FILE\_TRAVERSE** [access right](/windows/win32/secauthz/access-rights-and-access-masks). See the remarks in [File Security and Access Rights](/windows/win32/fileio/file-security-and-access-rights) for more information. |
+| Execute/Traverse | 0x20,
%%4421 | **Execute** - For a native code file, the right to execute the file. This access right given to scripts may cause the script to be executable, depending on the script interpreter.
**Traverse -** For a directory, the right to traverse the directory. By default, users are assigned the **BYPASS\_TRAVERSE\_CHECKING** [privilege](/windows/win32/secauthz/privileges), which ignores the **FILE\_TRAVERSE** [access right](/windows/win32/secauthz/access-rights-and-access-masks). For more information, see the remarks in [File Security and Access Rights](/windows/win32/fileio/file-security-and-access-rights). |
| DeleteChild | 0x40,
%%4422 | For a directory, the right to delete a directory and all the files it contains, including read-only files. |
| ReadAttributes | 0x80,
%%4423 | The right to read file attributes. |
| WriteAttributes | 0x100,
%%4424 | The right to write file attributes. |
@@ -155,7 +155,7 @@ This event generates every time network share object (file or folder) was access
| READ\_CONTROL | 0x20000,
%%1538 | The right to read the information in the object's security descriptor, not including the information in the system access control list (SACL). |
| WRITE\_DAC | 0x40000,
%%1539 | The right to modify the discretionary access control list (DACL) in the object's security descriptor. |
| WRITE\_OWNER | 0x80000,
%%1540 | The right to change the owner in the object's security descriptor |
-| SYNCHRONIZE | 0x100000,
%%1541 | The right to use the object for synchronization. This enables a thread to wait until the object is in the signaled state. Some object types do not support this access right. |
+| SYNCHRONIZE | 0x100000,
%%1541 | The right to use the object for synchronization. This right enables a thread to wait until the object is in the signaled state. Some object types don't support this access right. |
| ACCESS\_SYS\_SEC | 0x1000000,
%%1542 | The ACCESS\_SYS\_SEC access right controls the ability to get or set the SACL in an object's security descriptor. |
> Table 13. File access codes.
@@ -193,7 +193,7 @@ REQUESTED\_ACCESS: RESULT ACE\_WHICH\_ ALLOWED\_OR\_DENIED\_ACCESS.
| "AU" | Authenticated users | "LG" | Local guest |
| "BA" | Built-in administrators | "LS" | Local service account |
| "BG" | Built-in guests | "SY" | Local system |
-| "BO" | Backup operators | "NU" | Network logon user |
+| "BO" | Backup operators | "NU" | Network sign-in user |
| "BU" | Built-in users | "NO" | Network configuration operators |
| "CA" | Certificate server administrators | "NS" | Network service account |
| "CG" | Creator group | "PO" | Printer operators |
@@ -205,7 +205,7 @@ REQUESTED\_ACCESS: RESULT ACE\_WHICH\_ ALLOWED\_OR\_DENIED\_ACCESS.
| "DU" | Domain users | "RC" | Restricted code |
| "EA" | Enterprise administrators | "SA" | Schema administrators |
| "ED" | Enterprise domain controllers | "SO" | Server operators |
-| "WD" | Everyone | "SU" | Service logon user |
+| "WD" | Everyone | "SU" | Service sign-in user |
- *G*: = Primary Group.
- *D*: = DACL Entries.
@@ -225,7 +225,7 @@ Example: D:(A;;FA;;;WD)
"P” - SDDL\_PROTECTED, Inheritance from containers that are higher in the folder hierarchy are blocked.
-"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Is not also set.
+"AI" - SDDL\_AUTO\_INHERITED, Inheritance is allowed, assuming that "P" Isn't also set.
"AR" - SDDL\_AUTO\_INHERIT\_REQ, Child objects inherit permissions from this object.
@@ -251,7 +251,7 @@ Example: D:(A;;FA;;;WD)
"CI" - CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
-"OI" - OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
+"OI" - OBJECT INHERIT: Child objects that aren't containers inherit the ACE as an explicit ACE.
"NP" - NO PROPAGATE: only immediate children inherit this ace.
@@ -262,7 +262,7 @@ Example: D:(A;;FA;;;WD)
"SA" - SUCCESSFUL ACCESS AUDIT
"FA" - FAILED ACCESS AUDIT
-- rights: A hexadecimal string which denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
+- rights: A hexadecimal string that denotes the access mask or reserved value, for example: FA (File All Access), FX (File Execute), FW (File Write), etc.
| Value | Description | Value | Description |
|----------------------------|---------------------------------|----------------------|--------------------------|
@@ -284,7 +284,7 @@ Example: D:(A;;FA;;;WD)
- object\_guid: N/A
- inherit\_object\_guid: N/A
-- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. See the table above for more details.
+- account\_sid: SID of specific security principal, or reserved value, for example: AN (Anonymous), WD (Everyone), SY (LOCAL\_SYSTEM), etc. For more information, see the table above.
For more information about SDDL syntax, see these articles: , .
@@ -294,9 +294,9 @@ For 5145(S, F): A network share object was checked to see whether client can be
> **Important** For this event, also see [Appendix A: Security monitoring recommendations for many audit events](appendix-a-security-monitoring-recommendations-for-many-audit-events.md).
-- Monitor this event if the **Network Information\\Source Address** is not from your internal IP range.
+- Monitor this event if the **Network Information\\Source Address** isn't from your internal IP range.
-- Monitor this event if the **Network Information\\Source Address** should not be able to connect with the specific computer (**Computer:**).
+- Monitor this event if the **Network Information\\Source Address** shouldn't be able to connect with the specific computer (**Computer:**).
- If you have critical files or folders on specific network shares, for which you need to monitor access attempts (Success and Failure), monitor for specific **Share Information\\Share Name** and **Share Information\\Relative Target Name**.
diff --git a/windows/security/threat-protection/auditing/event-5148.md b/windows/security/threat-protection/auditing/event-5148.md
index 094f91e5f3..d8739009b8 100644
--- a/windows/security/threat-protection/auditing/event-5148.md
+++ b/windows/security/threat-protection/auditing/event-5148.md
@@ -17,9 +17,9 @@ ms.technology: windows-sec
# 5148(F): The Windows Filtering Platform has detected a DoS attack and entered a defensive mode; packets associated with this attack will be discarded.
-In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack starts or was detected.
+In most circumstances, this event occurs rarely. It's designed to be generated when an ICMP DoS attack starts or was detected.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Object Access Events](audit-other-object-access-events.md)
From 2237c29387dd45d4cbcd77ba1c5afa44b1ec644e Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Tue, 21 Jun 2022 12:24:09 +0530
Subject: [PATCH 008/299] Acrolinx Enhancement Effort
---
.../threat-protection/auditing/event-5149.md | 4 ++--
.../threat-protection/auditing/event-5152.md | 12 ++++++------
.../threat-protection/auditing/event-5154.md | 10 +++++-----
.../threat-protection/auditing/event-5155.md | 10 +++++-----
.../threat-protection/auditing/event-5156.md | 12 ++++++------
.../threat-protection/auditing/event-5157.md | 12 ++++++------
.../threat-protection/auditing/event-5158.md | 10 +++++-----
.../threat-protection/auditing/event-5159.md | 6 +++---
.../threat-protection/auditing/event-5632.md | 12 ++++++------
.../threat-protection/auditing/event-6144.md | 4 ++--
.../threat-protection/auditing/event-6145.md | 6 +++---
.../threat-protection/auditing/event-6281.md | 12 ++++++------
.../threat-protection/auditing/event-6405.md | 4 ++--
.../threat-protection/auditing/event-6406.md | 4 ++--
.../threat-protection/auditing/event-6407.md | 6 +++---
.../threat-protection/auditing/event-6410.md | 8 ++++----
.../file-system-global-object-access-auditing.md | 4 ++--
...tor-central-access-policy-and-rule-definitions.md | 2 +-
.../auditing/monitor-claim-types.md | 8 ++++----
.../monitor-resource-attribute-definitions.md | 6 +++---
20 files changed, 76 insertions(+), 76 deletions(-)
diff --git a/windows/security/threat-protection/auditing/event-5149.md b/windows/security/threat-protection/auditing/event-5149.md
index 3be32e2a0c..5cbafb7fe3 100644
--- a/windows/security/threat-protection/auditing/event-5149.md
+++ b/windows/security/threat-protection/auditing/event-5149.md
@@ -17,9 +17,9 @@ ms.technology: windows-sec
# 5149(F): The DoS attack has subsided and normal processing is being resumed.
-In most circumstances, this event occurs very rarely. It is designed to be generated when an ICMP DoS attack ended.
+In most circumstances, this event occurs rarely. It's designed to be generated when an ICMP DoS attack ends.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other Object Access Events](audit-other-object-access-events.md)
diff --git a/windows/security/threat-protection/auditing/event-5152.md b/windows/security/threat-protection/auditing/event-5152.md
index 1e2cec8711..20bb33c8fc 100644
--- a/windows/security/threat-protection/auditing/event-5152.md
+++ b/windows/security/threat-protection/auditing/event-5152.md
@@ -109,7 +109,7 @@ This event is generated for every received network packet.
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number on which application received the packet.
@@ -123,7 +123,7 @@ This event is generated for every received network packet.
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number that was used from remote machine to send the packet.
@@ -167,20 +167,20 @@ For 5152(F): The Windows Filtering Platform blocked a packet.
- If you have a pre-defined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that **Source Address** is one of the addresses assigned to the computer.
-- If the computer or device should not have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5152](event-5152.md) events where **Destination Address** is an IP address from the Internet (not from private IP ranges).
+- If the computer or device shouldn't have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5152](event-5152.md) events where **Destination Address** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in **Destination Address**.
-- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in **“Destination Address”** that are not in the allow list.
+- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in **“Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5152](event-5152.md) events with that “**Source Port**.**”**
-- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
+- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computer’s communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5154.md b/windows/security/threat-protection/auditing/event-5154.md
index 4cd691deaf..4b45c0c9cd 100644
--- a/windows/security/threat-protection/auditing/event-5154.md
+++ b/windows/security/threat-protection/auditing/event-5154.md
@@ -95,10 +95,10 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
- IPv6 Address
- :: - all IP addresses in IPv6 format
-
+s
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]: source TCP\\UDP port number that was requested for listening by application.
@@ -112,7 +112,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Filter Information:**
-- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows application to listen on the specific port. By default Windows firewall won't prevent a port from being listened by an application and if this application doesn’t match any filters you will get value **0** in this field.
+- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows application to listen on the specific port. By default Windows firewall won't prevent a port from being listened by an application and if this application doesn’t match any filters you'll get value **0** in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find specific substring with required filter ID (**<filterId>**)**,** for example:
@@ -128,7 +128,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
For 5154(S): The Windows Filtering Platform has permitted an application or service to listen on a port for incoming connections.
-- If you have an “allow list” of applications that are associated with certain operating systems or server roles, and that are expected to listen on specific ports, monitor this event for **“Application Name”** and other relevant information.
+- If you've an “allowlist” of applications that are associated with certain operating systems or server roles, and that are expected to listen on specific ports, monitor this event for **“Application Name”** and other relevant information.
- If a certain application is allowed to listen only on specific port numbers, monitor this event for **“Application Name”** and **“Network Information\\Source Port**.**”**
@@ -138,7 +138,7 @@ For 5154(S): The Windows Filtering Platform has permitted an application or serv
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
diff --git a/windows/security/threat-protection/auditing/event-5155.md b/windows/security/threat-protection/auditing/event-5155.md
index b4626b59c1..06487ca949 100644
--- a/windows/security/threat-protection/auditing/event-5155.md
+++ b/windows/security/threat-protection/auditing/event-5155.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
# 5155(F): The Windows Filtering Platform has blocked an application or service from listening on a port for incoming connections.
-By default Windows firewall won't prevent a port from being listened by an application. In the other word, Windows system will not generate Event 5155 by itself.
+By default Windows firewall won't prevent a port from being listened by an application. In the other word, Windows system won't generate Event 5155 by itself.
You can add your own filters using the WFP APIs to block listen to reproduce this event: .
@@ -72,7 +72,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
**Application Information**:
-- **Process ID** \[Type = Pointer\]: Hexadecimal Process ID (PID) of the process which was permitted to bind to the local port. The PID is a number used by the operating system to uniquely identify an active process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
+- **Process ID** \[Type = Pointer\]: Hexadecimal Process ID (PID) of the process that was permitted to bind to the local port. The PID is a number used by the operating system to uniquely identify an active process. To see the PID for a specific process you can, for example, use Task Manager (Details tab, PID column):
@@ -100,7 +100,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** The port number used by the application.
@@ -126,7 +126,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
**Filter Information:**
-- **Filter Run-Time ID** \[Type = UInt64\]: A unique filter ID which blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding to an application, and if this application doesn’t match any filters, you will get a 0 value in this field.
+- **Filter Run-Time ID** \[Type = UInt64\]: A unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding to an application, and if this application doesn’t match any filters, you'll get a 0 value in this field.
To find a specific Windows Filtering Platform filter by ID, you need to execute the following command: **netsh wfp show filters**. As a result of this command, a **filters.xml** file will be generated. You need to open this file and find the specific substring with the required filter ID (**<filterId>**), for example:
@@ -134,7 +134,7 @@ This event generates every time the [Windows Filtering Platform](/windows/win32/
- **Layer Name** \[Type = UnicodeString\]: [Application Layer Enforcement](/windows/win32/fwp/application-layer-enforcement--ale-) layer name.
-- **Layer Run-Time ID** \[Type = UInt64\]: Windows Filtering Platform layer identifier. To find a specific Windows Filtering Platform layer ID, you need to execute the following command: **netsh wfp show state**. As result of this command, a **wfpstate.xml** file will be generated. You need to open this file and find the specific substring with the required layer ID (**<layerId>**), for example:
+- **Layer Run-Time ID** \[Type = UInt64\]: Windows Filtering Platform layer identifier. To find a specific Windows Filtering Platform layer ID, you need to execute the following command: **netsh wfp show state**. As a result of this command, a **wfpstate.xml** file will be generated. You need to open this file and find the specific substring with the required layer ID (**<layerId>**), for example:
diff --git a/windows/security/threat-protection/auditing/event-5156.md b/windows/security/threat-protection/auditing/event-5156.md
index f19c968a01..4c668565fa 100644
--- a/windows/security/threat-protection/auditing/event-5156.md
+++ b/windows/security/threat-protection/auditing/event-5156.md
@@ -109,7 +109,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number from which the connection was initiated.
@@ -123,7 +123,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number where the connection was received.
@@ -167,20 +167,20 @@ For 5156(S): The Windows Filtering Platform has permitted a connection.
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that “**Source Address”** is one of the addresses assigned to the computer.
-- If the computer or device should not have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5156](event-5156.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
+- If the computer or device shouldn't have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5156](event-5156.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in “**Destination Address**.**”**
-- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that are not in the allow list.
+- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5156](event-5156.md) events with that “**Source Port**.**”**
-- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
+- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computer’s communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5157.md b/windows/security/threat-protection/auditing/event-5157.md
index e860f2729c..3569920d49 100644
--- a/windows/security/threat-protection/auditing/event-5157.md
+++ b/windows/security/threat-protection/auditing/event-5157.md
@@ -109,7 +109,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number on which application received the connection.
@@ -123,7 +123,7 @@ This event generates when [Windows Filtering Platform](/windows/win32/fwp/window
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Destination Port** \[Type = UnicodeString\]**:** port number that was used from remote machine to initiate connection.
@@ -167,20 +167,20 @@ For 5157(F): The Windows Filtering Platform has blocked a connection.
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
- Check that “**Source Address”** is one of the addresses assigned to the computer.
-- If the\` computer or device should not have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5157](event-5157.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
+- If the\` computer or device shouldn't have access to the Internet, or contains only applications that don’t connect to the Internet, monitor for [5157](event-5157.md) events where “**Destination Address”** is an IP address from the Internet (not from private IP ranges).
- If you know that the computer should never contact or should never be contacted by certain network IP addresses, monitor for these addresses in “**Destination Address**.**”**
-- If you have an allow list of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that are not in the allow list.
+- If you've an allowlist of IP addresses that the computer or device is expected to contact or to be contacted by, monitor for IP addresses in “**Destination Address”** that aren't in the allowlist.
- If you need to monitor all inbound connections to a specific local port, monitor for [5157](event-5157.md) events with that “**Source Port**.**”**
-- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 1, 6, or 17.
+- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 1, 6, or 17.
- If the computer’s communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5158.md b/windows/security/threat-protection/auditing/event-5158.md
index f2a088807e..e2ecfbd040 100644
--- a/windows/security/threat-protection/auditing/event-5158.md
+++ b/windows/security/threat-protection/auditing/event-5158.md
@@ -90,7 +90,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Network Information:**
-- **Source Address** \[Type = UnicodeString\]**:** local IP address on which application was bind the port.
+- **Source Address** \[Type = UnicodeString\]**:** local IP address on which application was bound the port.
- IPv4 Address
@@ -100,7 +100,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** port number which application was bind.
@@ -126,7 +126,7 @@ This event generates every time [Windows Filtering Platform](/windows/win32/fwp/
**Filter Information:**
-- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows the application to bind the port. By default, Windows firewall won't prevent a port from being bound by an application. If this application doesn’t match any filters, you will get value 0 in this field.
+- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that allows the application to bind the port. By default, Windows firewall won't prevent a port from being bound by an application. If this application doesn’t match any filters, you'll get value 0 in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find specific substring with required filter ID (**<filterId>**)**,** for example:
@@ -144,7 +144,7 @@ For 5158(S): The Windows Filtering Platform has permitted a bind to a local port
- If you have a predefined application that should be used to perform the operation that was reported by this event, monitor events with “**Application**” not equal to your defined application.
-- You can monitor to see if “**Application**” is not in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
+- You can monitor to see if “**Application**” isn't in a standard folder (for example, not in **System32** or **Program Files**) or is in a restricted folder (for example, **Temporary Internet Files**).
- If you have a pre-defined list of restricted substrings or words in application names (for example, “**mimikatz**” or “**cain.exe**”), check for these substrings in “**Application**.”
@@ -152,6 +152,6 @@ For 5158(S): The Windows Filtering Platform has permitted a bind to a local port
- If you need to monitor all actions with a specific local port, monitor for [5158](event-5158.md) events with that “**Source Port.”**
-- Monitor for all connections with a “**Protocol Number”** that is not typical for this device or computer, for example, anything other than 6 or 17.
+- Monitor for all connections with a “**Protocol Number”** that isn't typical for this device or computer, for example, anything other than 6 or 17.
- If the computer’s communication with “**Destination Address”** should always use a specific “**Destination Port**,**”** monitor for any other “**Destination Port**.”
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5159.md b/windows/security/threat-protection/auditing/event-5159.md
index c66d53025f..61393ef168 100644
--- a/windows/security/threat-protection/auditing/event-5159.md
+++ b/windows/security/threat-protection/auditing/event-5159.md
@@ -98,7 +98,7 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
- 0.0.0.0 - all IP addresses in IPv4 format
- - 127.0.0.1 , ::1 - localhost
+ - 127.0.0.1, ::1 - localhost
- **Source Port** \[Type = UnicodeString\]**:** the port number used by the application.
@@ -124,7 +124,7 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
**Filter Information:**
-- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding by an application, and if this application doesn’t match any filters, you will get value 0 in this field.
+- **Filter Run-Time ID** \[Type = UInt64\]: unique filter ID that blocks the application from binding to the port. By default, Windows firewall won't prevent a port from binding by an application, and if this application doesn’t match any filters, you'll get value 0 in this field.
To find a specific Windows Filtering Platform filter by ID, run the following command: **netsh wfp show filters**. As a result of this command, the **filters.xml** file will be generated. Open this file and find the specific substring with the required filter ID (**<filterId>**)**,** for example:
@@ -138,4 +138,4 @@ This event is logged if the Windows Filtering Platform has blocked a bind to a l
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
\ No newline at end of file
+- There's no recommendation for this event in this document.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-5632.md b/windows/security/threat-protection/auditing/event-5632.md
index 08210802e3..7b2b12b6e5 100644
--- a/windows/security/threat-protection/auditing/event-5632.md
+++ b/windows/security/threat-protection/auditing/event-5632.md
@@ -85,7 +85,7 @@ It typically generates when network adapter connects to new wireless network.
- **Account Name** \[Type = UnicodeString\]**:** the name of the account for which 802.1x authentication request was made.
-- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following:
+- **Account Domain** \[Type = UnicodeString\]**:** subject’s domain or computer name. Formats vary, and include the following ones:
- Domain NETBIOS name example: CONTOSO
@@ -125,16 +125,16 @@ You can see interface’s GUID using the following commands:
- **Reason Code** \[Type = UnicodeString\]**:** contains Reason Text (explanation of Reason Code) and Reason Code for wireless authentication results. See more information about reason codes for wireless authentication here: , .
-- **Error Code** \[Type = HexInt32\]**:** there is no information about this field in this document.
+- **Error Code** \[Type = HexInt32\]**:** there's no information about this field in this document.
-- **EAP Reason Code** \[Type = HexInt32\]**:** there is no information about this field in this document. See additional information here: .
+- **EAP Reason Code** \[Type = HexInt32\]**:** there's no information about this field in this document. See additional information here: .
-- **EAP Root Cause String** \[Type = UnicodeString\]**:** there is no information about this field in this document.
+- **EAP Root Cause String** \[Type = UnicodeString\]**:** there's no information about this field in this document.
-- **EAP Error Code** \[Type = HexInt32\]**:** there is no information about this field in this document.
+- **EAP Error Code** \[Type = HexInt32\]**:** there's no information about this field in this document.
## Security Monitoring Recommendations
For 5632(S, F): A request was made to authenticate to a wireless network.
-- There is no recommendation for this event in this document.
\ No newline at end of file
+- There's no recommendation for this event in this document.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-6144.md b/windows/security/threat-protection/auditing/event-6144.md
index 045943bcdf..0cc09756be 100644
--- a/windows/security/threat-protection/auditing/event-6144.md
+++ b/windows/security/threat-protection/auditing/event-6144.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time settings from the “Security Settings” section in the group policy object are applied successfully to a computer, without any errors. This event generates on the target computer itself.
-It is a routine event which shows you the list of Group Policy Objects that include “Security Settings” policies, and that were applied to the computer.
+It's a routine event that shows you the list of Group Policy Objects that include “Security Settings” policies, and that were applied to the computer.
This event generates every time Group Policy is applied to the computer.
@@ -82,7 +82,7 @@ You can find specific GROUP\_POLICY\_GUID using **Get-GPO** PowerShell cmdlet wi
For 6144(S): Security policy in the group policy objects has been applied successfully.
-- If you have a pre-defined list of Group Policy Objects which contain Security Settings and must be applied to specific computers, then you can compare the list from this event with your list and in case of any difference trigger an alert.
+- If you have a pre-defined list of Group Policy Objects that contain Security Settings and must be applied to specific computers, then you can compare the list from this event with your list and if there's any difference, you must trigger an alert.
- This event is mostly an informational event.
diff --git a/windows/security/threat-protection/auditing/event-6145.md b/windows/security/threat-protection/auditing/event-6145.md
index 17484bcaf1..3a84f0746a 100644
--- a/windows/security/threat-protection/auditing/event-6145.md
+++ b/windows/security/threat-protection/auditing/event-6145.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
This event generates every time settings from the “Security Settings” section in the group policy object are applied to a computer with one or more errors. This event generates on the target computer itself.
-This event generates, for example, if the [SID](/windows/win32/secauthz/security-identifiers) of a security principal which was included in one of the Group Policy settings cannot be resolved or translated to the real account name.
+This event generates, for example, if the [SID](/windows/win32/secauthz/security-identifiers) of a security principal which was included in one of the Group Policy settings can't be resolved or translated to the real account name.
> **Note** For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@@ -66,7 +66,7 @@ This event generates, for example, if the [SID](/windows/win32/secauthz/security
***Field Descriptions:***
-**Error Code** \[Type = UInt32\]: specific error code which shows the error which happened during Group Policy processing. You can find the meaning of specific error code here: . For example, error code 1332 means that “no mapping between account names and security IDs was done”.
+**Error Code** \[Type = UInt32\]: specific error code that shows the error that happened during Group Policy processing. You can find the meaning of specific error code here: . For example, error code 1332 means that “no mapping between account names and security IDs was done”.
**GPO List** \[Type = UnicodeString\]: the list of Group Policy Objects that include “Security Settings” policies, and that were applied with errors to the computer. The format of the list item is: “GROUP\_POLICY\_GUID GROUP\_POLICY\_NAME”.
@@ -80,7 +80,7 @@ You can find specific GROUP\_POLICY\_GUID using **Get-GPO** PowerShell cmdlet wi
For 6145(F): One or more errors occurred while processing security policy in the group policy objects.
-- This event indicates that Group Policy Objects which were applied to the computer or device had some errors during processing. If you see this event, we recommend checking settings in the GPOs from **GPO List** and resolving the cause of the errors.
+- This event indicates that Group Policy Objects that were applied to the computer or device had some errors during processing. If you see this event, we recommend checking settings in the GPOs from **GPO List** and resolving the cause of the errors.
- If you have a pre-defined list of Group Policy Objects that contain Security Settings and that must be applied to specific computers, check this event to see if errors occurred when the Security Settings were applied. If so, you can review the error codes and investigate the cause of the failure.
diff --git a/windows/security/threat-protection/auditing/event-6281.md b/windows/security/threat-protection/auditing/event-6281.md
index a4404d8d5d..08849399ff 100644
--- a/windows/security/threat-protection/auditing/event-6281.md
+++ b/windows/security/threat-protection/auditing/event-6281.md
@@ -1,6 +1,6 @@
---
-title: 6281(F) Code Integrity determined that the page hashes of an image file are not valid. (Windows 10)
-description: Describes security event 6281(F) Code Integrity determined that the page hashes of an image file are not valid.
+title: 6281(F) Code Integrity determined that the page hashes of an image file aren't valid. (Windows 10)
+description: Describes security event 6281(F) Code Integrity determined that the page hashes of an image file aren't valid.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -14,16 +14,16 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# 6281(F): Code Integrity determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
+# 6281(F): Code Integrity determined that the page hashes of an image file aren't valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
The file could be improperly signed without page hashes or corrupt due to unauthorized modification. The invalid hashes could indicate a potential disk device error.
-[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
+[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it's loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
-This event generates when [code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) determined that the page hashes of an image file are not valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. This event also generates when signing certificate was revoked. The invalid hashes could indicate a potential disk device error.
+This event generates when [code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) determined that the page hashes of an image file aren't valid. The file could be improperly signed without page hashes or corrupt due to unauthorized modification. This event also generates when signing certificate was revoked. The invalid hashes could indicate a potential disk device error.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/event-6405.md b/windows/security/threat-protection/auditing/event-6405.md
index e8efbf0ec1..cd6d137b5a 100644
--- a/windows/security/threat-protection/auditing/event-6405.md
+++ b/windows/security/threat-protection/auditing/event-6405.md
@@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other System Events](audit-other-system-events.md)
@@ -35,4 +35,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
\ No newline at end of file
+- There's no recommendation for this event in this document.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-6406.md b/windows/security/threat-protection/auditing/event-6406.md
index 5f556714d7..49d868e4de 100644
--- a/windows/security/threat-protection/auditing/event-6406.md
+++ b/windows/security/threat-protection/auditing/event-6406.md
@@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other System Events](audit-other-system-events.md)
@@ -37,4 +37,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
\ No newline at end of file
+- There's no recommendation for this event in this document.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-6407.md b/windows/security/threat-protection/auditing/event-6407.md
index a5d377eb0e..791511b97c 100644
--- a/windows/security/threat-protection/auditing/event-6407.md
+++ b/windows/security/threat-protection/auditing/event-6407.md
@@ -1,6 +1,6 @@
---
title: 6407(-) 1%. (Windows 10)
-description: Describes security event 6407(-) 1%. This is a BranchCache event, which is outside the scope of this document.
+description: Describes security event 6407(-) 1%. This event is a BranchCache event, which is outside the scope of this document.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -19,7 +19,7 @@ ms.technology: windows-sec
[BranchCache](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj127252(v=ws.11)) events are outside the scope of this document.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit Other System Events](audit-other-system-events.md)
@@ -35,4 +35,4 @@ There is no example of this event in this document.
## Security Monitoring Recommendations
-- There is no recommendation for this event in this document.
\ No newline at end of file
+- There's no recommendation for this event in this document.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/event-6410.md b/windows/security/threat-protection/auditing/event-6410.md
index bc2da0e57f..36e66234e1 100644
--- a/windows/security/threat-protection/auditing/event-6410.md
+++ b/windows/security/threat-protection/auditing/event-6410.md
@@ -1,6 +1,6 @@
---
-title: 6410(F) Code integrity determined that a file does not meet the security requirements to load into a process. (Windows 10)
-description: Describes security event 6410(F) Code integrity determined that a file does not meet the security requirements to load into a process.
+title: 6410(F) Code integrity determined that a file doesn't meet the security requirements to load into a process. (Windows 10)
+description: Describes security event 6410(F) Code integrity determined that a file doesn't meet the security requirements to load into a process.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -17,11 +17,11 @@ ms.technology: windows-sec
# 6410(F): Code integrity determined that a file does not meet the security requirements to load into a process.
-[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it is loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
+[Code Integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10)) is a feature that improves the security of the operating system by validating the integrity of a driver or system file each time it's loaded into memory. Code Integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with administrative permissions. On x64-based versions of the operating system, kernel-mode drivers must be digitally signed.
This event generates due to writable [shared sections](/previous-versions/windows/desktop/cc307397(v=msdn.10)) being present in a file image.
-There is no example of this event in this document.
+There's no example of this event in this document.
***Subcategory:*** [Audit System Integrity](audit-system-integrity.md)
diff --git a/windows/security/threat-protection/auditing/file-system-global-object-access-auditing.md b/windows/security/threat-protection/auditing/file-system-global-object-access-auditing.md
index a5df9bf707..605274b0a5 100644
--- a/windows/security/threat-protection/auditing/file-system-global-object-access-auditing.md
+++ b/windows/security/threat-protection/auditing/file-system-global-object-access-auditing.md
@@ -23,9 +23,9 @@ ms.technology: windows-sec
This topic for the IT professional describes the Advanced Security Audit policy setting, **File System (Global Object Access Auditing)**, which enables you to configure a global system access control list (SACL) on the file system for an entire computer.
-If you select the **Configure security** check box on the policy’s property page, you can add a user or group to the global SACL. This enables you to define computer system access control lists (SACLs) per object type for the file system. The specified SACL is then automatically applied to every file system object type.
+If you select the **Configure security** check box on the policy’s property page, you can add a user or group to the global SACL. This user/group addition enables you to define computer system access control lists (SACLs) per object type for the file system. The specified SACL is then automatically applied to every file system object type.
-If both a file or folder SACL and a global SACL are configured on a computer, the effective SACL is derived by combining the file or folder SACL and the global SACL. This means that an audit event is generated if an activity matches either the file or folder SACL or the global SACL.
+If both a file or folder SACL and a global SACL are configured on a computer, the effective SACL is derived by combining the file or folder SACL and the global SACL. This SACL (of such a constitution) means that an audit event is generated if an activity matches either the file or folder SACL or the global SACL.
This policy setting must be used in combination with the **File System** security policy setting under Object Access. For more information, see [Audit File System](audit-file-system.md).
## Related topics
diff --git a/windows/security/threat-protection/auditing/monitor-central-access-policy-and-rule-definitions.md b/windows/security/threat-protection/auditing/monitor-central-access-policy-and-rule-definitions.md
index 3dc75d64ed..0d27bc3fda 100644
--- a/windows/security/threat-protection/auditing/monitor-central-access-policy-and-rule-definitions.md
+++ b/windows/security/threat-protection/auditing/monitor-central-access-policy-and-rule-definitions.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
This article for IT professionals describes how to monitor changes to central access policy and central access rule definitions when you use advanced security auditing options to monitor dynamic access control objects.
-Central access policies and rules determine access permissions for files on multiple file servers, so it's important to monitor changes to them. Like user claim and device claim definitions, central access policy and rule definitions reside in Active Directory Domain Services (AD DS). You can monitor them just like any other object in Active Directory. These policies and rules are critical elements in a Dynamic Access Control deployment. They are stored in AD DS, so they're less likely to be tampered with than other network objects. But it's important to monitor them for potential changes in security auditing and to verify that policies are being enforced.
+Central access policies and rules determine access permissions for files on multiple file servers, so it's important to monitor changes to them. Like user claim and device claim definitions, central access policy and rule definitions reside in Active Directory Domain Services (AD DS). You can monitor them just like any other object in Active Directory. These policies and rules are critical elements in a Dynamic Access Control deployment. They're stored in AD DS, so they're less likely to be tampered with than other network objects. But it's important to monitor them for potential changes in security auditing and to verify that policies are being enforced.
Follow the procedures in this article to configure settings to monitor changes to central access policy and central access rule definitions and to verify the changes. These procedures assume that you've configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you haven't yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (demonstration steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
diff --git a/windows/security/threat-protection/auditing/monitor-claim-types.md b/windows/security/threat-protection/auditing/monitor-claim-types.md
index 643795c7e2..1a7fbfe2d2 100644
--- a/windows/security/threat-protection/auditing/monitor-claim-types.md
+++ b/windows/security/threat-protection/auditing/monitor-claim-types.md
@@ -1,6 +1,6 @@
---
title: Monitor claim types (Windows 10)
-description: Learn how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.
+description: Learn how to monitor changes to claim types that are associated with dynamic access control when you're using advanced security auditing options.
ms.assetid: 426084da-4eef-44af-aeec-e7ab4d4e2439
ms.reviewer:
ms.author: dansimp
@@ -21,11 +21,11 @@ ms.technology: windows-sec
# Monitor claim types
-This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you are using advanced security auditing options.
+This topic for the IT professional describes how to monitor changes to claim types that are associated with dynamic access control when you're using advanced security auditing options.
Claim types are one of the basic building blocks of Dynamic Access Control. Claim types can include attributes such as the departments in an organization or the levels of security clearance that apply to classes of users. You can use security auditing to track whether claims are added, modified, enabled, disabled, or deleted.
-Use the following procedures to configure settings to monitor changes to claim types in AD DS. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic
+Use the following procedures to configure settings to monitor changes to claim types in AD DS. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you haven't yet deployed Dynamic
Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
>**Note:** Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
@@ -36,7 +36,7 @@ Access Control in your network, see [Deploy a Central Access Policy (Demonstrati
2. In Server Manager, point to **Tools**, and then click **Group Policy Management**.
3. In the console tree, right-click the default domain controller Group Policy Object, and then click **Edit**.
4. Double-click **Computer Configuration**, click **Security Settings**, expand **Advanced Audit Policy Configuration**, expand **System Audit Policies**, click **DS Access**, and then double-click **Audit directory service changes**.
-5. Select the **Configure the following audit events** check box, select the **Success** check box (andthe **Failure** check box, if desired), and then click **OK**.
+5. Select the **Configure the following audit events** check box, select the **Success** check box (and the **Failure** check box, if desired), and then click **OK**.
After you configure settings to monitor changes to claim types in AD DS, verify that the changes are being monitored.
diff --git a/windows/security/threat-protection/auditing/monitor-resource-attribute-definitions.md b/windows/security/threat-protection/auditing/monitor-resource-attribute-definitions.md
index 1be153db59..c9c75a970e 100644
--- a/windows/security/threat-protection/auditing/monitor-resource-attribute-definitions.md
+++ b/windows/security/threat-protection/auditing/monitor-resource-attribute-definitions.md
@@ -1,6 +1,6 @@
---
title: Monitor resource attribute definitions (Windows 10)
-description: Learn how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.
+description: Learn how to monitor changes to resource attribute definitions when you're using advanced security auditing options to monitor dynamic access control objects.
ms.assetid: aace34b0-123a-4b83-9e09-f269220e79de
ms.reviewer:
ms.author: dansimp
@@ -21,12 +21,12 @@ ms.technology: windows-sec
# Monitor resource attribute definitions
-This topic for the IT professional describes how to monitor changes to resource attribute definitions when you are using advanced security auditing options to monitor dynamic access control objects.
+This topic for the IT professional describes how to monitor changes to resource attribute definitions when you're using advanced security auditing options to monitor dynamic access control objects.
Resource attribute definitions define the basic properties of resource attributes, such as what it means for a resource to be defined as “high business value.” Resource attribute definitions are stored in AD DS under the Resource Properties container. Changes to these definitions could significantly change the protections that govern a resource, even if the resource attributes that apply to the resource remain unchanged. Changes can be monitored like any other AD DS object.
For information about monitoring changes to the resource attributes that apply to files, see [Monitor the resource attributes on files and folders](monitor-the-resource-attributes-on-files-and-folders.md).
-Use the following procedures to configure settings to monitor changes to resource attribute definitions in AD DS and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
+Use the following procedures to configure settings to monitor changes to resource attribute definitions in AD DS and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you haven't yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
>**Note:** Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
From a861796474084c717172f517d3b562acfe4d3aca Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Wed, 22 Jun 2022 13:12:36 +0530
Subject: [PATCH 009/299] Acrolinx Enhancement Effort
---
...ss-policies-that-apply-on-a-file-server.md | 2 +-
...esource-attributes-on-files-and-folders.md | 2 +-
...r-user-and-device-claims-during-sign-in.md | 6 +-
...loying-advanced-security-audit-policies.md | 30 ++--
.../auditing/security-auditing-overview.md | 4 +-
.../block-untrusted-fonts-in-enterprise.md | 26 ++--
...tion-based-protection-of-code-integrity.md | 24 +--
...tion-based-protection-of-code-integrity.md | 32 ++--
.../get-support-for-security-baselines.md | 8 +-
.../mbsa-removal-and-guidance.md | 6 +-
.../configure-md-app-guard.md | 20 +--
.../faq-md-app-guard.yml | 26 ++--
.../reqs-md-app-guard.md | 10 +-
.../msft-security-dev-lifecycle.md | 4 +-
...tions-for-app-related-security-policies.md | 6 +-
...iew-of-threat-mitigations-in-windows-10.md | 44 +++---
...-the-health-of-windows-10-based-devices.md | 144 +++++++++---------
.../access-this-computer-from-the-network.md | 16 +-
.../account-lockout-duration.md | 8 +-
.../security-compliance-toolkit-10.md | 6 +-
20 files changed, 212 insertions(+), 212 deletions(-)
diff --git a/windows/security/threat-protection/auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md b/windows/security/threat-protection/auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md
index a1780808e5..15c31fb0d2 100644
--- a/windows/security/threat-protection/auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md
+++ b/windows/security/threat-protection/auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
This article describes how to monitor changes to the central access policies (CAPs) that apply to a file server when using advanced security auditing options to monitor dynamic access control objects. CAPs are created on a domain controller and then applied to file servers through Group Policy management.
-Use the following procedures to configure and verify security auditing settings that are used to monitor changes to the set of CAPs on a file server. The following procedures assume that you have configured and deployed dynamic access control, including CAPs and claims, in your network. If you have not yet deployed dynamic access control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
+Use the following procedures to configure and verify security auditing settings that are used to monitor changes to the set of CAPs on a file server. The following procedures assume that you have configured and deployed dynamic access control, including CAPs and claims, in your network. If you haven't yet deployed dynamic access control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
**To configure settings to monitor changes to central access policies**
diff --git a/windows/security/threat-protection/auditing/monitor-the-resource-attributes-on-files-and-folders.md b/windows/security/threat-protection/auditing/monitor-the-resource-attributes-on-files-and-folders.md
index 20be28d785..73427802a4 100644
--- a/windows/security/threat-protection/auditing/monitor-the-resource-attributes-on-files-and-folders.md
+++ b/windows/security/threat-protection/auditing/monitor-the-resource-attributes-on-files-and-folders.md
@@ -21,7 +21,7 @@ ms.technology: windows-sec
# Monitor the resource attributes on files and folders
-This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you are using advanced security auditing options to monitor dynamic access control objects.
+This topic for the IT professional describes how to monitor attempts to change settings to the resource attributes on files when you're using advanced security auditing options to monitor dynamic access control objects.
If your organization has a carefully thought out authorization configuration for resources, changes to these resource attributes can create potential security risks. Examples include:
diff --git a/windows/security/threat-protection/auditing/monitor-user-and-device-claims-during-sign-in.md b/windows/security/threat-protection/auditing/monitor-user-and-device-claims-during-sign-in.md
index 865b1b5aaf..759bc149b4 100644
--- a/windows/security/threat-protection/auditing/monitor-user-and-device-claims-during-sign-in.md
+++ b/windows/security/threat-protection/auditing/monitor-user-and-device-claims-during-sign-in.md
@@ -21,11 +21,11 @@ ms.technology: windows-sec
# Monitor user and device claims during sign-in
-This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you are using advanced security auditing options to monitor dynamic access control objects.
+This topic for the IT professional describes how to monitor user and device claims that are associated with a user’s security token when you're using advanced security auditing options to monitor dynamic access control objects.
-Device claims are associated with the system that is used to access resources that are protected with Dynamic Access Control. User claims are attributes that are associated with a user. User claims and device claims are included in the user’s security token used at sign-on. For example, information about Department, Company, Project, or Security clearances might be included in the token.
+Device claims are associated with the system that is used to access resources that are protected with Dynamic Access Control. User claims are attributes that are associated with a user. User claims and device claims are included in the user’s security token used at the sign-in stage. For example, information about Department, Company, Project, or Security clearances might be included in the token.
-Use the following procedures to monitor changes to user claims and device claims in the user’s sign-on token and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you have not yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
+Use the following procedures to monitor changes to user claims and device claims in the user’s sign-in token and to verify the changes. These procedures assume that you have configured and deployed Dynamic Access Control, including central access policies, claims, and other components, in your network. If you haven't yet deployed Dynamic Access Control in your network, see [Deploy a Central Access Policy (Demonstration Steps)](/windows-server/identity/solution-guides/deploy-a-central-access-policy--demonstration-steps-).
>**Note:** Your server might function differently based on the version and edition of the operating system that is installed, your account permissions, and your menu settings.
diff --git a/windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md b/windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md
index 4f9f9b93e8..08a07d6718 100644
--- a/windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md
+++ b/windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
This article for IT professionals explains the options that security policy planners should consider and the tasks they must complete to deploy an effective security audit policy in a network that includes advanced security audit policies.
-Organizations invest heavily in security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on your data, the job isn't complete unless you have a well-defined, timely auditing strategy to track the effectiveness of your defenses and identify attempts to circumvent them.
+Organizations invest heavily in security applications and services, such as antimalware software, firewalls, and encryption. But no matter how much security hardware or software you deploy, how tightly you control the rights of users, or how carefully you configure security permissions on your data, the job isn't complete unless you've a well-defined, timely auditing strategy to track the effectiveness of your defenses and identify attempts to circumvent them.
To be well-defined and timely, an auditing strategy must provide useful tracking data for an organization's most important resources, critical behaviors, and potential risks. In many organizations, it must also provide proof that IT operations comply with corporate and regulatory requirements.
@@ -134,7 +134,7 @@ To effectively audit user activity, begin by listing the different types of user
Also, if external users can access your organization's data, be sure to identify them. Determine whether they're a business partner, customer, or general user; the data they have access to; and the permissions they have to access that data.
-The following table illustrates an analysis of users on a network. Our example contains only a single column titled "Possible auditing considerations," but you may want to create additional columns to differentiate between different types of network activity, such as logon hours and permission use.
+The following table illustrates an analysis of users on a network. Our example contains only a single column titled "Possible auditing considerations," but you may want to create more columns to differentiate between different types of network activity, such as sign-in hours and permission use.
| Groups | Data | Possible auditing considerations |
| - | - | - |
@@ -187,7 +187,7 @@ By using Group Policy, you can apply your security audit policy to defined group
- Decide whether every policy setting that you select should be enforced across the organization or apply only to selected users or computers. You can then combine these audit policy settings into GPOs and link them to the appropriate Active Directory containers.
- By default, options set in GPOs that are linked to higher levels of Active Directory sites, domains, and OUs are inherited by all OUs at lower levels. However, a GPO that's linked at a lower level can overwrite inherited policies.
- For example, you might use a domain GPO to assign an organization-wide group of audit settings but want a certain OU to get a defined group of additional settings. To do this, you can link a second GPO to that specific lower-level OU. Then, a logon audit setting that's applied at the OU level will override a conflicting logon audit setting that's applied at the domain level, unless you've taken special steps to apply Group Policy loopback processing.
+ For example, you might use a domain GPO to assign an organization-wide group of audit settings but want a certain OU to get a defined group of extra settings. To do this assignation, you can link a second GPO to that specific lower-level OU. Then, a sign-in audit setting that's applied at the OU level will override a conflicting sign-in audit setting that's applied at the domain level, unless you've taken special steps to apply Group Policy loopback processing.
- Audit policies are computer policies. Therefore, they must be applied through GPOs that are applied to *computer* OUs, not to *user* OUs. But in most cases, you can apply audit settings for only specified resources and groups of users by configuring SACLs on the relevant objects. This functionality enables auditing for a security group that contains only the users you specify.
@@ -270,12 +270,12 @@ Compromise to an organization's data resources can cause tremendous financial lo
The settings in the previous section relate to activity involving the files, folders, and network shares that are stored on a network. The settings in this section focus on the users who may try to access those resources, including employees, partners, and customers.
-In most cases, these attempts are legitimate, and the network needs to make data readily available to legitimate users. But in other cases, employees, partners, and others may try to access resources that they have no legitimate reason to access. You can use security auditing to track a variety of user activities on a particular computer to diagnose and resolve problems for legitimate users and to identify and address illegitimate activities. The following are important settings that you should evaluate to track user activity on your network:
+In most cases, these attempts are legitimate, and the network needs to make data readily available to legitimate users. But in other cases, employees, partners, and others may try to access resources that they have no legitimate reason to access. You can use security auditing to track various user activities on a particular computer to diagnose and resolve problems for legitimate users and to identify and address illegitimate activities. The following are important settings that you should evaluate to track user activity on your network:
-- **Account Logon\\[Audit Credential Validation](audit-credential-validation.md)**: This setting enables you to track all successful and unsuccessful logon attempts. A pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer valid. Or the user or app is trying to use a variety of credentials in succession in hope that one of these attempts will eventually succeed. These events occur on the computer that's authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
+- **Account Logon\\[Audit Credential Validation](audit-credential-validation.md)**: This setting enables you to track all successful and unsuccessful sign-in attempts. A pattern of unsuccessful attempts may indicate that a user or application is using credentials that are no longer valid. Or the user or app is trying to use various credentials in succession in hope that one of these attempts will eventually succeed. These events occur on the computer that's authoritative for the credentials. For domain accounts, the domain controller is authoritative. For local accounts, the local computer is authoritative.
- **Detailed Tracking\\[Audit Process Creation](audit-process-creation.md) and Detailed Tracking\\[Audit Process Termination](audit-process-termination.md)**: These policy settings enable you to monitor the applications that a user opens and close on a computer.
-- **DS Access\\[Audit Directory Service Access](audit-directory-service-access.md)** and **DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md)**: These policy settings provide a detailed audit trail of attempts to access, create, modify, delete, move, or undelete objects in Active Directory Domain Services (AD DS). Only domain administrators have permissions to modify AD DS objects, so it's important to identify malicious attempts to modify these objects. Also, although domain administrators should be among an organization's most trusted employees, the use of the **Audit Directory Service Access** and **Audit Directory Service Changes** settings enable you to monitor and verify that only approved changes are made to AD DS. These audit events are logged only on domain controllers.
-- **Logon/Logoff\\[Audit Account Lockout](audit-account-lockout.md)**: Another common security scenario occurs when a user attempts to log on with an account that's been locked out. It's important to identify these events and to determine whether the attempt to use an account that was locked out is malicious.
+- **DS Access\\[Audit Directory Service Access](audit-directory-service-access.md)** and **DS Access\\[Audit Directory Service Changes](audit-directory-service-changes.md)**: These policy settings provide a detailed audit trail of attempts to access, create, modify, delete, move, or undelete objects in Active Directory Domain Services (AD DS). Only domain administrators have permissions to modify AD DS objects, so it's important to identify malicious attempts to modify these objects. Also, although domain administrators should be among an organization's most trusted employees, the use of the **Audit Directory Service Access** and **Audit Directory Service Changes** settings enables you to monitor and verify that only approved changes are made to AD DS. These audit events are logged only on domain controllers.
+- **Logon/Logoff\\[Audit Account Lockout](audit-account-lockout.md)**: Another common security scenario occurs when a user attempts to sign in with an account that's been locked out. It's important to identify these events and to determine whether the attempt to use an account that was locked out is malicious.
- **Logon/Logoff\\[Audit Logoff](audit-logoff.md)** and **Logon/Logoff\\[Audit Logon](audit-logon.md)**: Logon and logoff events are essential to tracking user activity and detecting potential attacks. Logon events are related to the creation of logon sessions, and they occur on the computer that was accessed. For an interactive logon, events are generated on the computer that was logged on to. For network logon, such as accessing a shared resource, events are generated on the computer that hosts the resource that was accessed. Logoff events are generated when logon sessions are terminated.
> [!NOTE]
@@ -309,7 +309,7 @@ The following network activity policy settings enable you to monitor security-re
- **Logon/Logoff\\[Audit Network Policy Server](audit-network-policy-server.md)**: Organizations that use RADIUS (IAS) and Network Access Protection (NAP) to set and maintain security requirements for external users can use this policy setting to monitor the effectiveness of these policies and to determine whether anyone is trying to circumvent these protections.
- **Policy Change**: These policy settings and events enable you to track changes to important security policies on a local computer or network. Because policies are typically established by administrators to help secure network resources, monitoring any changes or attempted changes to these policies can be an important aspect of security management for a network.
- **Policy Change\\[Audit Audit Policy Change](audit-audit-policy-change.md)**: This policy setting allows you to monitor changes to the audit policy. If malicious users obtain domain administrator credentials, they can temporarily disable essential security audit policy settings so that their other activities on the network can't be detected.
-- **Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md)**: This policy setting can be used to monitor a variety of changes to an organization's IPsec policies.
+- **Policy Change\\[Audit Filtering Platform Policy Change](audit-filtering-platform-policy-change.md)**: This policy setting can be used to monitor various changes to an organization's IPsec policies.
- **Policy Change\\[Audit MPSSVC Rule-Level Policy Change](audit-mpssvc-rule-level-policy-change.md)**: This policy setting determines if the operating system generates audit events when changes are made to policy rules for the Microsoft Protection Service (MPSSVC.exe), which is used by Windows Firewall. Changes to firewall rules are important for understanding the security state of the computer and how well it's protected against network attacks.
### Confirm operating system version compatibility
@@ -331,9 +331,9 @@ These settings enable you to exercise much tighter control over which activities
### *Success*, *failure*, or both
-Whichever event settings you include in your plan, you also have to decide whether you want to log an event when the activity fails or succeeds or both successes *and* failures. This is an important question. The answer depends on the criticality of the event and the implications of the decision for event volume.
+Whichever event settings you include in your plan, you also have to decide whether you want to log an event when the activity fails or succeeds or both successes *and* failures. This question is an important one. The answer depends on the criticality of the event and the implications of the decision for event volume.
-For example, on a file server that's accessed frequently by legitimate users, you may want to log an event only when an *unsuccessful* attempt to access data takes place, because this could be evidence of an unauthorized or malicious user. In this case, logging *successful* attempts to access the server would quickly fill the event log with benign events.
+For example, on a file server that's accessed frequently by legitimate users, you may want to log an event only when an *unsuccessful* attempt to access data takes place, because this access failure could be evidence of an unauthorized or malicious user. In this case, logging *successful* attempts to access the server would quickly fill the event log with benign events.
But if the file share has sensitive information, such as trade secrets, you may want to log every access attempt so that you have an audit trail of every user who tries to access the resource.
@@ -341,12 +341,12 @@ But if the file share has sensitive information, such as trade secrets, you may
Networks may contain hundreds of servers that run critical services or store critical data, all of which need to be monitored. There may be tens or even hundreds of thousands of computers on the network. These numbers may not be an issue if the ratio of servers or client computers per administrator is low. And even if an administrator who is responsible for auditing security and performance issues has relatively few computers to monitor, you need to decide how the administrator will obtain event data to review. Following are some options for obtaining the event data.
-- Will you keep event data on a local computer until an administrator logs on to review this data? If so, the administrator needs to have physical or remote access to the Event Viewer on each client computer or server. And the remote access and firewall settings on each client computer or server need to be configured to enable this access. You also need to decide how often the administrator can visit each computer, and adjust the size of the audit log so that critical information isn't deleted if the log reaches capacity.
-- Will you collect event data so that it can be reviewed from a central console? If so, there are a number of computer management products, such as the Audit Collection Services in Microsoft Operations Manager 2007 and 2012, that you can use to collect and filter event data. Presumably this solution enables a single administrator to review larger amounts of data than using the local storage option. But in some cases, this method can make it more difficult to detect clusters of related events that can occur on a single computer.
+- Will you keep event data on a local computer until an administrator signs in to review this data? If so, the administrator needs to have physical or remote access to the Event Viewer on each client computer or server. And the remote access and firewall settings on each client computer or server need to be configured to enable this access. You also need to decide how often the administrator can visit each computer, and adjust the size of the audit log so that critical information isn't deleted if the log reaches capacity.
+- Will you collect event data so that it can be reviewed from a central console? If so, there are many computer management products, such as the Audit Collection Services in Microsoft Operations Manager 2007 and 2012, that you can use to collect and filter event data. Presumably this solution enables a single administrator to review larger amounts of data than using the local storage option. But in some cases, this method can make it more difficult to detect clusters of related events that can occur on a single computer.
In addition, whether you choose to leave audit data on an individual computer or consolidate it at a central location, you need to decide how large the log file should be and what happens when the log reaches its maximum size. To configure these options, open Event Viewer, expand **Windows Logs**, right-click **Security**, and select **Properties**. You can configure the following properties:
-- **Overwrite events as needed (oldest events first)**: This is the default option, which is acceptable in most situations.
+- **Overwrite events as needed (oldest events first)**: This option is the default one, which is acceptable in most situations.
- **Archive the log when full, do not overwrite events**: This option can be used when all log data needs to be saved. But the scenario suggests that you may not be reviewing audit data frequently enough.
- **Do not overwrite events (Clear logs manually)**. This option stops the collection of audit data when the log file reaches its maximum size. Older data is retained at the expense of the most recent audit events. Use this option only if you don't want to lose any audit data, don't want to create an archive of the event log, and are committed to reviewing data before the maximum log size is reached.
@@ -359,7 +359,7 @@ Configuration\\Administrative Templates\\Windows Components\\Event Log Service\\
- **Retain old events**: This policy setting controls event log behavior when the log file reaches its maximum size. When this policy setting is enabled and a log file reaches its maximum size, new events aren't written to the log and are lost. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events.
- **Backup log automatically when full**: This policy setting controls event log behavior when the log file reaches its maximum size. It takes effect only if the **Retain old events** policy setting is enabled. If you enable these policy settings, the event log file is automatically closed and renamed when it's full. A new log file is then started. If you disable or don't configure this policy setting and the **Retain old events** policy setting is enabled, new events are discarded, and the old events are retained.
-Many organizations are now required to store archived log files for a number of years. Consult with regulatory compliance officers in your organization to determine whether such guidelines apply to your organization. For more information, see the [IT Compliance Management Guide](/previous-versions/tn-archive/dd206732(v=technet.10)).
+Many organizations are now required to store archived log files for many years. Consult with regulatory compliance officers in your organization to determine whether such guidelines apply to your organization. For more information, see the [IT Compliance Management Guide](/previous-versions/tn-archive/dd206732(v=technet.10)).
## Deploy the security audit policy
@@ -373,4 +373,4 @@ However, unless you can run fairly realistic simulations of network usage patter
- A limited set of security audit policy settings, such as **Logon/Logoff** and **Account Logon**
- A combination of limited OUs and audit policy settings—for example, targeting servers in only the Accounting OU with **Object Access** policy settings
-After you successfully complete one or more limited deployments, you should confirm that the audit data that's collected is manageable with your management tools and administrators. After you confirm that the pilot deployment is effective, you need to ensure that you have the necessary tools and staff to expand the deployment to include additional OUs and sets of audit policy settings until production deployment is complete.
\ No newline at end of file
+After you successfully complete one or more limited deployments, you should confirm that the audit data that's collected is manageable with your management tools and administrators. After you confirm that the pilot deployment is effective, you need to ensure that you have the necessary tools and staff to expand the deployment to include more OUs and sets of audit policy settings until production deployment is complete.
\ No newline at end of file
diff --git a/windows/security/threat-protection/auditing/security-auditing-overview.md b/windows/security/threat-protection/auditing/security-auditing-overview.md
index 1c305a4439..7d7e21c1f3 100644
--- a/windows/security/threat-protection/auditing/security-auditing-overview.md
+++ b/windows/security/threat-protection/auditing/security-auditing-overview.md
@@ -25,14 +25,14 @@ Topics in this section are for IT professionals and describes the security audit
##
-Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you have determined to be valuable in your risk assessment.
+Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you've determined to be valuable in your risk assessment.
## In this section
| Topic | Description |
| - | - |
|[Basic security audit policies](basic-security-audit-policies.md) |Before you implement auditing, you must decide on an auditing policy. A basic audit policy specifies categories of security-related events that you want to audit. When this version of Windows is first installed, all auditing categories are disabled. By enabling various auditing event categories, you can implement an auditing policy that suits the security needs of your organization. |
-|[Advanced security audit policies](./advanced-security-auditing.md) |Advanced security audit policy settings are found in **Security Settings\Advanced Audit Policy Configuration\System Audit Policies** and appear to overlap with basic security audit policies, but they are recorded and applied differently. |
+|[Advanced security audit policies](./advanced-security-auditing.md) |Advanced security audit policy settings are found in **Security Settings\Advanced Audit Policy Configuration\System Audit Policies** and appear to overlap with basic security audit policies, but they're recorded and applied differently. |
diff --git a/windows/security/threat-protection/block-untrusted-fonts-in-enterprise.md b/windows/security/threat-protection/block-untrusted-fonts-in-enterprise.md
index 564c7cdfe4..95aa186d93 100644
--- a/windows/security/threat-protection/block-untrusted-fonts-in-enterprise.md
+++ b/windows/security/threat-protection/block-untrusted-fonts-in-enterprise.md
@@ -1,6 +1,6 @@
---
title: Block untrusted fonts in an enterprise (Windows 10)
-description: To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we've created the Blocking Untrusted Fonts feature.
+description: To help protect your company from attacks that may originate from untrusted or attacker controlled font files, we've created the Blocking Untrusted Fonts feature.
ms.reviewer:
manager: dansimp
ms.prod: m365-security
@@ -19,13 +19,13 @@ ms.technology: windows-sec
> Learn more about what features and functionality are supported in each Windows edition at [Compare Windows 10 Editions](https://www.microsoft.com/WindowsForBusiness/Compare).
-To help protect your company from attacks which may originate from untrusted or attacker-controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the `%windir%/Fonts` directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process.
+To help protect your company from attacks that may originate from untrusted or attacker-controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the `%windir%/Fonts` directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process.
## What does this mean for me?
-Blocking untrusted fonts helps improve your network and employee protection against font-processing-related attacks. By default, this feature is not turned on.
+Blocking untrusted fonts helps improve your network and employee protection against font-processing-related attacks. By default, this feature isn't turned on.
## How does this feature work?
-There are 3 ways to use this feature:
+There are three ways to use this feature:
- **On.** Helps stop any font processed using GDI from loading outside of the `%windir%/Fonts` directory. It also turns on event logging.
@@ -37,9 +37,9 @@ There are 3 ways to use this feature:
- **Exclude apps to load untrusted fonts.** You can exclude specific apps, allowing them to load untrusted fonts, even while this feature is turned on. For instructions, see [Fix apps having problems because of blocked fonts](#fix-apps-having-problems-because-of-blocked-fonts).
## Potential reductions in functionality
-After you turn this feature on, your employees might experience reduced functionality when:
+After you turn on this feature, your employees might experience reduced functionality when:
-- Sending a print job to a remote printer server that uses this feature and where the spooler process hasn’t been specifically excluded. In this situation, any fonts that aren’t already available in the server’s %windir%/Fonts folder won’t be used.
+- Sending a print job to a remote printer server that uses this feature and where the spooler process hasn’t been excluded. In this situation, any fonts that aren’t already available in the server’s %windir%/Fonts folder won’t be used.
- Printing using fonts provided by the installed printer’s graphics .dll file, outside of the %windir%/Fonts folder. For more information, see [Introduction to Printer Graphics DLLs](/windows-hardware/drivers/print/introduction-to-printer-graphics-dlls).
@@ -55,13 +55,13 @@ Use Group Policy or the registry to turn this feature on, off, or to use audit m
**To turn on and use the Blocking Untrusted Fonts feature through Group Policy**
1. Open the Group Policy editor (gpedit.msc) and go to `Computer Configuration\Administrative Templates\System\Mitigation Options\Untrusted Font Blocking`.
-2. Click **Enabled** to turn the feature on, and then click one of the following **Mitigation Options**:
+2. Click **Enabled** to turn on the feature, and then click one of the following **Mitigation Options**:
- - **Block untrusted fonts and log events.** Turns the feature on, blocking untrusted fonts and logging installation attempts to the event log.
+ - **Block untrusted fonts and log events.** Turns on the feature, blocking untrusted fonts and logging installation attempts to the event log.
- - **Do not block untrusted fonts.** Turns the feature on, but doesn't block untrusted fonts nor does it log installation attempts to the event log.
+ - **Do not block untrusted fonts.** Turns on the feature, but doesn't block untrusted fonts nor does it log installation attempts to the event log.
- - **Log events without blocking untrusted fonts**. Turns the feature on, logging installation attempts to the event log, but not blocking untrusted fonts.
+ - **Log events without blocking untrusted fonts**. Turns on the feature, logging installation attempts to the event log, but not blocking untrusted fonts.
3. Click **OK**.
@@ -90,7 +90,7 @@ To turn this feature on, off, or to use audit mode:
5. Restart your computer.
## View the event log
-After you turn this feature on, or start using Audit mode, you can look at your event logs for details.
+After you turn on this feature, or start using Audit mode, you can look at your event logs for details.
**To look at your event log**
@@ -128,7 +128,7 @@ After you turn this feature on, or start using Audit mode, you can look at your
## Fix apps having problems because of blocked fonts
Your company may still need apps that are having problems because of blocked fonts, so we suggest that you first run this feature in Audit mode to determine which fonts are causing the problems.
-After you figure out the problematic fonts, you can try to fix your apps in 2 ways: by directly installing the fonts into the %windir%/Fonts directory or by excluding the underlying processes and letting the fonts load. As the default solution, we highly recommend that you install the problematic font. Installing fonts is safer than excluding apps because excluded apps can load any font, trusted or untrusted.
+After you figure out the problematic fonts, you can try to fix your apps in two ways: by directly installing the fonts into the %windir%/Fonts directory or by excluding the underlying processes and letting the fonts load. As the default solution, we highly recommend that you install the problematic font. Installing fonts is safer than excluding apps because excluded apps can load any font, trusted or untrusted.
**To fix your apps by installing the problematic fonts (recommended)**
@@ -138,7 +138,7 @@ After you figure out the problematic fonts, you can try to fix your apps in 2 wa
1. On each computer with the app installed, open regedit.exe and go to `HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\`.
For example, if you want to exclude Microsoft Word processes, you’d use `HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\Winword.exe`.
-2. Add any additional processes that need to be excluded here, and then turn the Blocking untrusted fonts feature on, using the steps in [Turn on and use the Blocking Untrusted Fonts feature](#turn-on-and-use-the-blocking-untrusted-fonts-feature), earlier in this article.
+2. Add other processes that need to be excluded here, and then turn on the Blocking untrusted fonts feature, using the steps in [Turn on and use the Blocking Untrusted Fonts feature](#turn-on-and-use-the-blocking-untrusted-fonts-feature), earlier in this article.
## Related content
diff --git a/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity.md b/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity.md
index 4a0981cf1f..b51d3cbf0e 100644
--- a/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity.md
+++ b/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity.md
@@ -23,8 +23,8 @@ ms.technology: windows-sec
This topic covers different ways to enable Hypervisor-protected code integrity (HVCI) on Windows 10 and Windows 11.
Some applications, including device drivers, may be incompatible with HVCI.
-This can cause devices or software to malfunction and in rare cases may result in a blue screen. Such issues may occur after HVCI has been turned on or during the enablement process itself.
-If this happens, see [Troubleshooting](#troubleshooting) for remediation steps.
+This incompatibility can cause devices or software to malfunction and in rare cases may result in a blue screen. Such issues may occur after HVCI has been turned on or during the enablement process itself.
+If these issues occur, see [Troubleshooting](#troubleshooting) for remediation steps.
> [!NOTE]
> Because it makes use of *Mode Based Execution Control*, HVCI works better with Intel Kaby Lake or AMD Zen 2 CPUs and newer. Processors without MBEC will rely on an emulation of this feature, called *Restricted User Mode*, which has a bigger impact on performance.
@@ -60,7 +60,7 @@ Enabling in Intune requires using the Code Integrity node in the [AppLocker CSP]
3. Double-click **Turn on Virtualization Based Security**.
-4. Click **Enabled** and under **Virtualization Based Protection of Code Integrity**, select **Enabled with UEFI lock** to ensure HVCI cannot be disabled remotely or select **Enabled without UEFI lock**.
+4. Click **Enabled** and under **Virtualization Based Protection of Code Integrity**, select **Enabled with UEFI lock** to ensure HVCI can't be disabled remotely or select **Enabled without UEFI lock**.

@@ -70,7 +70,7 @@ To apply the new policy on a domain-joined computer, either restart or run `gpup
### Use registry keys to enable virtualization-based protection of code integrity
-Set the following registry keys to enable HVCI. This provides exactly the same set of configuration options provided by Group Policy.
+Set the following registry keys to enable HVCI. These keys provide exactly the same set of configuration options provided by Group Policy.
@@ -208,7 +208,7 @@ Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windo
> [!NOTE]
> Mode Based Execution Control property will only be listed as available starting with Windows 10 version 1803 and Windows 11 version 21H2.
-The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled.
+The output of this command provides details of the available hardware-based security features and those features that are currently enabled.
#### AvailableSecurityProperties
@@ -251,7 +251,7 @@ This field indicates whether the Windows Defender Credential Guard or HVCI servi
Value | Description
-|-
-**0.** | No services configured.
+**0.** | No services are configured.
**1.** | If present, Windows Defender Credential Guard is configured.
**2.** | If present, HVCI is configured.
**3.** | If present, System Guard Secure Launch is configured.
@@ -279,7 +279,7 @@ This field indicates whether VBS is enabled and running.
Value | Description
-|-
-**0.** | VBS is not enabled.
+**0.** | VBS isn't enabled.
**1.** | VBS is enabled but not running.
**2.** | VBS is enabled and running.
@@ -295,7 +295,7 @@ Another method to determine the available and enabled Windows Defender Device Gu
A. If a device driver fails to load or crashes at runtime, you may be able to update the driver using **Device Manager**.
-B. If you experience software or device malfunction after using the above procedure to turn on HVCI, but you are able to log in to Windows, you can turn off HVCI by renaming or deleting the SIPolicy.p7b file from `\Windows\System32\CodeIntegrity\` and then restart your device.
+B. If you experience software or device malfunction after using the above procedure to turn on HVCI, but you're able to sign in to Windows, you can turn off HVCI by renaming or deleting the SIPolicy.p7b file from `\Windows\System32\CodeIntegrity\` and then restart your device.
C. If you experience a critical error during boot or your system is unstable after using the above procedure to turn on HVCI, you can recover using the Windows Recovery Environment (Windows RE). To boot to Windows RE, see [Windows RE Technical Reference](/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference). After logging in to Windows RE, you can turn off HVCI by renaming or deleting the SIPolicy.p7b file from `\Windows\System32\CodeIntegrity\` and then restart your device.
@@ -315,7 +315,7 @@ C. If you experience a critical error during boot or your system is unstable aft
HVCI can protect a Hyper-V virtual machine, just as it would a physical machine. The steps to enable Windows Defender Application Control are the same from within the virtual machine.
-WDAC protects against malware running in the guest virtual machine. It does not provide additional protection from the host administrator. From the host, you can disable WDAC for a virtual machine:
+WDAC protects against malware running in the guest virtual machine. It doesn't provide extra protection from the host administrator. From the host, you can disable WDAC for a virtual machine:
```powershell
Set-VMSecurity -VMName -VirtualizationBasedSecurityOptOut $true
@@ -324,6 +324,6 @@ Set-VMSecurity -VMName -VirtualizationBasedSecurityOptOut $true
### Requirements for running HVCI in Hyper-V virtual machines
- The Hyper-V host must run at least Windows Server 2016 or Windows 10 version 1607.
- The Hyper-V virtual machine must be Generation 2, and running at least Windows Server 2016 or Windows 10.
-- HVCI and [nested virtualization](/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) can be enabled at the same time. To enable the HyperV role on the virtual machine, you must first install the HyperV role in a Windows nested virtualization environment.
-- Virtual Fibre Channel adapters are not compatible with HVCI. Before attaching a virtual Fibre Channel Adapter to a virtual machine, you must first opt out of virtualization-based security using `Set-VMSecurity`.
-- The AllowFullSCSICommandSet option for pass-through disks is not compatible with HVCI. Before configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based security using `Set-VMSecurity`.
+- HVCI and [nested virtualization](/virtualization/hyper-v-on-windows/user-guide/nested-virtualization) can be enabled at the same time. To enable the Hyper-V role on the virtual machine, you must first install the Hyper-V role in a Windows nested virtualization environment.
+- Virtual Fibre Channel adapters aren't compatible with HVCI. Before attaching a virtual Fibre Channel Adapter to a virtual machine, you must first opt out of virtualization-based security using `Set-VMSecurity`.
+- The AllowFullSCSICommandSet option for pass-through disks isn't compatible with HVCI. Before configuring a pass-through disk with AllowFullSCSICommandSet, you must first opt out of virtualization-based security using `Set-VMSecurity`.
diff --git a/windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md b/windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md
index bec34fe509..7a99baa345 100644
--- a/windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md
+++ b/windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md
@@ -1,6 +1,6 @@
---
title: Deployment guidelines for Windows Defender Device Guard (Windows 10)
-description: Plan your deployment of Hypervisor-Protected Code Integrity (aka Memory Integrity). Learn about hardware requirements, deployment approaches, code signing and code integrity policies.
+description: Plan your deployment of Hypervisor-Protected Code Integrity (also known as Memory Integrity). Learn about hardware requirements, deployment approaches, code signing and code integrity policies.
keywords: virtualization, security, malware
ms.prod: m365-security
ms.mktglfcycl: deploy
@@ -16,12 +16,12 @@ ms.author: dansimp
ms.technology: windows-sec
---
-# Baseline protections and additional qualifications for virtualization-based protection of code integrity
+# Baseline protections and other qualifications for virtualization-based protection of code integrity
**Applies to**
- Windows 10
-Computers must meet certain hardware, firmware, and software requirements in order to take advantage of Hypervisor-Protected Code Integrity (HVCI), a virtualization-based security (VBS) feature in Windows. HVCI is referred to as Memory Integrity under the Core Isolation section of the Windows security settings. Computers lacking these requirements can still be protected by Windows Defender Application Control (WDAC) policies—the difference is that those computers will not be as hardened against certain threats.
+Computers must meet certain hardware, firmware, and software requirements in order to take advantage of Hypervisor-Protected Code Integrity (HVCI), a virtualization-based security (VBS) feature in Windows. HVCI is referred to as Memory Integrity under the Core Isolation section of the Windows security settings. Computers lacking these requirements can still be protected by Windows Defender Application Control (WDAC) policies—the difference is that those computers won't be as hardened against certain threats.
For example, hardware that includes CPU virtualization extensions and SLAT will be hardened against malware that attempts to gain access to the kernel, but without protected BIOS options such as “Boot only from internal hard drive,” the computer could be booted (by a malicious person who has physical access) into an operating system on bootable media.
@@ -38,42 +38,42 @@ The following tables provide more information about the hardware, firmware, and
|Baseline Protections | Description | Security benefits |
|--------------------------------|----------------------------------------------------|-------------------|
| Hardware: **64-bit CPU** | A 64-bit computer is required for the Windows hypervisor to provide VBS. | |
-| Hardware: **CPU virtualization extensions**,
plus **extended page tables** | These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system cannot be exploited because of this isolation. |
-| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the System.Fundamentals.Firmware.UEFISecureBoot requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Systems download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies). | UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots. |
+| Hardware: **CPU virtualization extensions**,
plus **extended page tables** | These hardware features are required for VBS:
One of the following virtualization extensions:
• VT-x (Intel) or
• AMD-V
And:
• Extended page tables, also called Second Level Address Translation (SLAT). | VBS provides isolation of the secure kernel from the normal operating system. Vulnerabilities and zero-days in the normal operating system can't be exploited because of this isolation. |
+| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | See the System.Fundamentals.Firmware.UEFISecureBoot requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Systems download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies). | UEFI Secure Boot helps ensure that the device boots only authorized code. This guarantee can prevent boot kits and root kits from installing and persisting across reboots. |
| Firmware: **Secure firmware update process** | UEFI firmware must support secure firmware update found under the System.Fundamentals.Firmware.UEFISecureBoot requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Systems download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies). | UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. |
-| Software: **HVCI compatible drivers** | See the Filter.Driver.DeviceGuard.DriverCompatibility requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Filter driver download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies). | [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. |
+| Software: **HVCI compatible drivers** | See the Filter.Driver.DeviceGuard.DriverCompatibility requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Filter driver download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies). | [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware can't run in kernel. Only code verified through code integrity can run in kernel mode. |
| Software: Qualified **Windows operating system** | Windows 10 Enterprise, Windows 10 Pro, Windows 10 Education, Windows Server 2016, or Windows 10 IoT Enterprise
Important:
Windows Server 2016 running as a domain controller does not support Windows Defender Credential Guard. Only virtualization-based protection of code integrity is supported in this configuration.
| Support for VBS and for management features. |
> **Important** The following tables list additional qualifications for improved security. You can use WDAC and HVCI with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting these additional qualifications to significantly strengthen the level of security that WDAC and HVCI can provide.
-## Additional qualifications for improved security
+## Other qualifications for improved security
-The following tables describe additional hardware and firmware qualifications, and the improved security that is available when these qualifications are met.
+The following tables describe other hardware and firmware qualifications, and the improved security that is available when these qualifications are met.
-### Additional security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4
+### More security qualifications starting with Windows 10, version 1507, and Windows Server 2016, Technical Preview 4
| Protections for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|------|
-| Firmware: **Securing Boot Configuration and Management** | • BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | • BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
+| Firmware: **Securing Boot Configuration and Management** | • BIOS password or stronger authentication must be supported.
• In the BIOS configuration, BIOS authentication must be set.
• There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.
• In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings. | • BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This guarantee helps protect against a physically present user with BIOS access.
• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
-### Additional security qualifications starting with Windows 10, version 1607, and Windows Server 2016
+### More security qualifications starting with Windows 10, version 1607, and Windows Server 2016
| Protections for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|-----|
-| Firmware: **Hardware Rooted Trust Platform Secure Boot** | • Boot Integrity (Platform Secure Boot) must be supported. See the System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Systems download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies).
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](/windows-hardware/test/hlk/testref/hardware-security-testability-specification). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides additional security assurance for correctly secured silicon and platform. |
+| Firmware: **Hardware Rooted Trust Platform Secure Boot** | • Boot Integrity (Platform Secure Boot) must be supported. See the System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby requirement in the [Windows Hardware Compatibility Specifications for Windows 10, version 1809 and Windows Server 2019 - Systems download](https://go.microsoft.com/fwlink/?linkid=2027110). You can find previous versions of the Windows Hardware Compatibility Program Specifications and Policies [here](/windows-hardware/design/compatibility/whcp-specifications-policies).
• The Hardware Security Test Interface (HSTI) 1.1.a must be implemented. See [Hardware Security Testability Specification](/windows-hardware/test/hlk/testref/hardware-security-testability-specification). | • Boot Integrity (Platform Secure Boot) from Power-On provides protections against physically present attackers, and defense-in-depth against malware.
• HSTI 1.1.a provides extra security assurance for correctly secured silicon and platform. |
| Firmware: **Firmware Update through Windows Update** | Firmware must support field updates through Windows Update and UEFI encapsulation update. | Helps ensure that firmware updates are fast, secure, and reliable. |
-| Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should leverage ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
+| Firmware: **Securing Boot Configuration and Management** | • Required BIOS capabilities: Ability of OEM to add ISV, OEM, or Enterprise Certificate in Secure Boot DB at manufacturing time.
• Required configurations: Microsoft UEFI CA must be removed from Secure Boot DB. Support for 3rd-party UEFI modules is permitted but should use ISV-provided certificates or OEM certificate for the specific UEFI software.| • Enterprises can choose to allow proprietary EFI drivers/applications to run.
• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
-### Additional security qualifications starting with Windows 10, version 1703
+### More security qualifications starting with Windows 10, version 1703
| Protections for Improved Security | Description | Security benefits |
|---------------------------------------------|----------------------------------------------------|------|
-| Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.
• UEFI runtime service must meet these requirements:
• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
• PE sections need to be page-aligned in memory (not required for in non-volitile storage).
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
• No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writeable and non-executable.
Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.
Please also note the following:
• Do not use sections that are both writeable and executable
• Do not attempt to directly modify executable system memory
• Do not use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. |
-| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](https://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks additional security attacks against SMM. |
+| Firmware: **VBS enablement of NX protection for UEFI runtime services** | • VBS will enable No-Execute (NX) protection on UEFI runtime service code and data memory regions. UEFI runtime service code must support read-only page protections, and UEFI runtime service data must not be executable.
• UEFI runtime service must meet these requirements:
• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table.
• PE sections need to be page-aligned in memory (not required for in non-volitile storage).
• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:
• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both
• No entries may be left with neither of the above attributes, indicating memory that is both executable and writable. Memory must be either readable and executable or writeable and non-executable.
Notes:
• This only applies to UEFI runtime service memory, and not UEFI boot service memory.
• This protection is applied by VBS on OS page tables.
Also note the following guidelines:
• Don't use sections that are both writeable and executable
• Don't attempt to directly modify executable system memory
• Don't use dynamic code | • Vulnerabilities in UEFI runtime, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware. |
+| Firmware: **Firmware support for SMM protection** | The [Windows SMM Security Mitigations Table (WSMT) specification](https://download.microsoft.com/download/1/8/A/18A21244-EB67-4538-BAA2-1A54E0E490B6/WSMT.docx) contains details of an Advanced Configuration and Power Interface (ACPI) table that was created for use with Windows operating systems that support Windows virtualization-based security (VBS) features.| • Protects against potential vulnerabilities in UEFI runtime services, if any, will be blocked from compromising VBS (such as in functions like UpdateCapsule and SetVariable)
• Reduces the attack surface to VBS from system firmware.
• Blocks other security attacks against SMM. |
diff --git a/windows/security/threat-protection/get-support-for-security-baselines.md b/windows/security/threat-protection/get-support-for-security-baselines.md
index 2159488c70..deb5111821 100644
--- a/windows/security/threat-protection/get-support-for-security-baselines.md
+++ b/windows/security/threat-protection/get-support-for-security-baselines.md
@@ -17,7 +17,7 @@ ms.technology: windows-sec
**What is the Microsoft Security Compliance Manager (SCM)?**
-The Security Compliance Manager (SCM) is now retired and is no longer supported. The reason is that SCM was an incredibly complex and large program that needed to be updated for every Windows release. It has been replaced by the Security Compliance Toolkit (SCT). To provide a better service for our customers, we have moved to SCT with which we can publish baselines through the Microsoft Download Center in a lightweight .zip file that contains GPO backups, GPO reports, Excel spreadsheets, WMI filters, and scripts to apply the settings to local policy.
+The Security Compliance Manager (SCM) is now retired and is no longer supported. The reason is that SCM was an incredibly complex and large program that needed to be updated for every Windows release. It has been replaced by the Security Compliance Toolkit (SCT). To provide a better service for our customers, we've moved to SCT with which we can publish baselines through the Microsoft Download Center in a lightweight .zip file that contains GPO backups, GPO reports, Excel spreadsheets, WMI filters, and scripts to apply the settings to local policy.
More information about this change can be found on the [Microsoft Security Guidance blog](/archive/blogs/secguide/security-compliance-manager-scm-retired-new-tools-and-procedures).
@@ -32,11 +32,11 @@ Any version of Windows baseline before Windows 10 1703 can still be downloaded u
**What file formats are supported by the new SCT?**
-The toolkit supports formats created by the Windows GPO backup feature (.pol, .inf, and .csv). Policy Analyzer saves its data in XML files with a .PolicyRules file extension. LGPO also supports its own LGPO text file format as a text-based analog for the binary registry.pol file format. See the LGPO documentation for more information. Keep in mind that SCM’s .cab files are no longer supported.
+The toolkit supports formats created by the Windows GPO backup feature (.pol, .inf, and .csv). Policy Analyzer saves its data in XML files with a .PolicyRules file extension. LGPO also supports its own LGPO text file format as a text-based analog for the binary registry.pol file format. For more information, see the LGPO documentation. Keep in mind that SCMs' .cab files are no longer supported.
**Does SCT support Desired State Configuration (DSC) file format?**
-Not yet. PowerShell-based DSC is rapidly gaining popularity, and more DSC tools are coming online to convert GPOs and DSC and to validate system configuration. We are currently developing a tool to provide customers with these features.
+Not yet. PowerShell-based DSC is rapidly gaining popularity, and more DSC tools are coming online to convert GPOs and DSC and to validate system configuration. We're currently developing a tool to provide customers with these features.
**Does SCT support the creation of Microsoft Endpoint Manager DCM packs?**
@@ -44,7 +44,7 @@ No. A potential alternative is Desired State Configuration (DSC), a feature of t
**Does SCT support the creation of Security Content Automation Protocol (SCAP)-format policies?**
-No. SCM supported only SCAP 1.0, which was not updated as SCAP evolved. The new toolkit likewise does not include SCAP support.
+No. SCM supported only SCAP 1.0, which wasn't updated as SCAP evolved. The new toolkit likewise doesn't include SCAP support.
diff --git a/windows/security/threat-protection/mbsa-removal-and-guidance.md b/windows/security/threat-protection/mbsa-removal-and-guidance.md
index c8fafe64a7..b38ebe2069 100644
--- a/windows/security/threat-protection/mbsa-removal-and-guidance.md
+++ b/windows/security/threat-protection/mbsa-removal-and-guidance.md
@@ -12,9 +12,9 @@ ms.technology: windows-sec
# What is Microsoft Baseline Security Analyzer and its uses?
-Microsoft Baseline Security Analyzer (MBSA) is used to verify patch compliance. MBSA also performed several other security checks for Windows, IIS, and SQL Server. Unfortunately, the logic behind these additional checks had not been actively maintained since Windows XP and Windows Server 2003. Changes in the products since then rendered many of these security checks obsolete and some of their recommendations counterproductive.
+Microsoft Baseline Security Analyzer (MBSA) is used to verify patch compliance. MBSA also performed several other security checks for Windows, IIS, and SQL Server. Unfortunately, the logic behind these extra checks hadn't been actively maintained since Windows XP and Windows Server 2003. Changes in the products since then rendered many of these security checks obsolete and some of their recommendations counterproductive.
-MBSA was largely used in situations where neither Microsoft Update nor a local WSUS or Configuration Manager server was available, or as a compliance tool to ensure that all security updates were deployed to a managed environment. While MBSA version 2.3 introduced support for Windows Server 2012 R2 and Windows 8.1, it has since been deprecated and no longer developed. MBSA 2.3 is not updated to fully support Windows 10 and Windows Server 2016.
+MBSA was largely used in situations where Microsoft Update a local WSUS or Configuration Manager server wasn't available, or as a compliance tool to ensure that all security updates were deployed to a managed environment. While MBSA version 2.3 introduced support for Windows Server 2012 R2 and Windows 8.1, it has since been deprecated and no longer developed. MBSA 2.3 isn't updated to fully support Windows 10 and Windows Server 2016.
> [!NOTE]
> In accordance with our [SHA-1 deprecation initiative](https://aka.ms/sha1deprecation), the Wsusscn2.cab file is no longer dual-signed using both SHA-1 and the SHA-2 suite of hash algorithms (specifically SHA-256). This file is now signed using only SHA-256. Administrators who verify digital signatures on this file should now expect only single SHA-256 signatures. Starting with the August 2020 Wsusscn2.cab file, MBSA will return the following error "The catalog file is damaged or an invalid catalog." when attempting to scan using the offline scan file.
@@ -31,7 +31,7 @@ For example:
[](https://www.powershellgallery.com/packages/Scan-UpdatesOffline/1.0)
The preceding scripts use the [WSUS offline scan file](https://support.microsoft.com/help/927745/detailed-information-for-developers-who-use-the-windows-update-offline) (wsusscn2.cab) to perform a scan and get the same information on missing updates as MBSA supplied. MBSA also relied on the wsusscn2.cab to determine which updates were missing from a given system without connecting to any online service or server. The wsusscn2.cab file is still available and there are currently no plans to remove or replace it.
-The wsusscn2.cab file contains the metadata of only security updates, update rollups and service packs available from Microsoft Update; it does not contain any information on non-security updates, tools or drivers.
+The wsusscn2.cab file contains the metadata of only security updates, update rollups and service packs available from Microsoft Update; it doesn't contain any information on non-security updates, tools or drivers.
## More Information
diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md b/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
index 99819da4d5..6e85b47920 100644
--- a/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
+++ b/windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
@@ -11,7 +11,7 @@ ms.author: deniseb
ms.date: 03/10/2022
ms.reviewer:
manager: dansimp
-ms.custom: asr
+ms.custom: sasr
ms.technology: windows-sec
---
@@ -36,8 +36,8 @@ These settings, located at `Computer Configuration\Administrative Templates\Netw
|Policy name|Supported versions|Description|
|-----------|------------------|-----------|
|Private network ranges for apps | At least Windows Server 2012, Windows 8, or Windows RT| A comma-separated list of IP address ranges that are in your corporate network. Included endpoints or endpoints that are included within a specified IP address range, are rendered using Microsoft Edge and won't be accessible from the Application Guard environment.|
-|Enterprise resource domains hosted in the cloud| At least Windows Server 2012, Windows 8, or Windows RT|A pipe-separated (`|`) list of your domain cloud resources. Included endpoints are rendered using Microsoft Edge and won't be accessible from the Application Guard environment. Note that this list supports the wildcards detailed in the [Network isolation settings wildcards](#network-isolation-settings-wildcards) table.|
-|Domains categorized as both work and personal| At least Windows Server 2012, Windows 8, or Windows RT|A comma-separated list of domain names used as both work or personal resources. Included endpoints are rendered using Microsoft Edge and will be accessible from the Application Guard and regular Edge environment.
Note that this list supports the wildcards detailed in the [Network isolation settings wildcards](#network-isolation-settings-wildcards) table.|
+|Enterprise resource domains hosted in the cloud| At least Windows Server 2012, Windows 8, or Windows RT|A pipe-separated (`|`) list of your domain cloud resources. Included endpoints are rendered using Microsoft Edge and won't be accessible from the Application Guard environment.
This list supports the wildcards detailed in the [Network isolation settings wildcards](#network-isolation-settings-wildcards) table.|
+|Domains categorized as both work and personal| At least Windows Server 2012, Windows 8, or Windows RT|A comma-separated list of domain names used as both work or personal resources. Included endpoints are rendered using Microsoft Edge and will be accessible from the Application Guard and regular Edge environment.
This list supports the wildcards detailed in the [Network isolation settings wildcards](#network-isolation-settings-wildcards) table.|
## Network isolation settings wildcards
@@ -54,18 +54,18 @@ These settings, located at `Computer Configuration\Administrative Templates\Wind
|Name|Supported versions|Description|Options|
|-----------|------------------|-----------|-------|
|Configure Microsoft Defender Application Guard clipboard settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** Turns On the clipboard functionality and lets you choose whether to additionally:
- Disable the clipboard functionality completely when Virtualization Security is enabled.
- Enable copying of certain content from Application Guard into Microsoft Edge.
- Enable copying of certain content from Microsoft Edge into Application Guard. **Important:** Allowing copied content to go from Microsoft Edge into Application Guard can cause potential security risks and isn't recommended.
**Disabled or not configured.** Completely turns Off the clipboard functionality for Application Guard.|
-|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for additional printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
+|Configure Microsoft Defender Application Guard print settings|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:
- Enable Application Guard to print into the XPS format.
- Enable Application Guard to print into the PDF format.
- Enable Application Guard to print to locally attached printers.
- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.
**Disabled or not configured.** Completely turns Off the print functionality for Application Guard.|
|Prevent enterprise websites from loading non-enterprise content in Microsoft Edge and Internet Explorer|Windows 10 Enterprise, 1709 or higher
Windows 11|Determines whether to allow Internet access for apps not included on the **Allowed Apps** list.|**Enabled.** Prevents network traffic from both Internet Explorer and Microsoft Edge to non-enterprise sites that can't render in the Application Guard container.
**NOTE**: This action might also block assets cached by CDNs and references to analytics sites. Add them to the trusted enterprise resources to avoid broken pages.
**Disabled or not configured.** Prevents Microsoft Edge to render network traffic to non-enterprise sites that can't render in Application Guard. |
|Allow Persistence|Windows 10 Enterprise, 1709 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether data persists across different sessions in Microsoft Defender Application Guard.|**Enabled.** Application Guard saves user-downloaded files and other items (such as, cookies, Favorites, and so on) for use in future Application Guard sessions.
**Disabled or not configured.** All user data within Application Guard is reset between sessions.
**NOTE**: If you later decide to stop supporting data persistence for your employees, you can use our Windows-provided utility to reset the container and to discard any personal data.
**To reset the container:**
1. Open a command-line program and navigate to `Windows/System32`.
2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.
3. Type `wdagtool.exe cleanup RESET_PERSISTENCE_LAYER`. The container environment is reset, including discarding all employee-generated data.|
-|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1809 or higher
Windows 11|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering non-enterprise domains in the Application Guard container. Be aware that Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:
- Enable Microsoft Defender Application Guard only for Microsoft Edge
- Enable Microsoft Defender Application Guard only for Microsoft Office
- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office
**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office.|
-|Allow files to download to host operating system|Windows 10 Enterprise, 1803 or higher
Windows 11|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users are not able to save downloaded files from Application Guard to the host operating system.|
-|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Be aware that enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
-|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher
Windows 11|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Be aware that enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
-|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher
Windows 11|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates are not shared with Microsoft Defender Application Guard.|
+|Turn on Microsoft Defender Application Guard in Managed Mode|Windows 10 Enterprise, 1809 or higher
Windows 11|Determines whether to turn on Application Guard for Microsoft Edge and Microsoft Office.|**Enabled.** Turns on Application Guard for Microsoft Edge and/or Microsoft Office, honoring the network isolation settings, rendering non-enterprise domains in the Application Guard container. Application Guard won't actually be turned on unless the required prerequisites and network isolation settings are already set on the device. Available options:
- Enable Microsoft Defender Application Guard only for Microsoft Edge
- Enable Microsoft Defender Application Guard only for Microsoft Office
- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office
**Disabled.** Turns off Application Guard, allowing all apps to run in Microsoft Edge and Microsoft Office.|
+|Allow files to download to host operating system|Windows 10 Enterprise, 1803 or higher
Windows 11|Determines whether to save downloaded files to the host operating system from the Microsoft Defender Application Guard container.|**Enabled.** Allows users to save downloaded files from the Microsoft Defender Application Guard container to the host operating system. This action creates a share between the host and container that also allows for uploads from the host to the Application Guard container.
**Disabled or not configured.** Users aren't able to save downloaded files from Application Guard to the host operating system.|
+|Allow hardware-accelerated rendering for Microsoft Defender Application Guard|Windows 10 Enterprise, 1803 or higher
Windows 10 Pro, 1803 or higher
Windows 11|Determines whether Microsoft Defender Application Guard renders graphics using hardware or software acceleration.|**Enabled.** Microsoft Defender Application Guard uses Hyper-V to access supported, high-security rendering graphics hardware (GPUs). These GPUs improve rendering performance and battery life while using Microsoft Defender Application Guard, particularly for video playback and other graphics-intensive use cases. If this setting is enabled without connecting any high-security rendering graphics hardware, Microsoft Defender Application Guard will automatically revert to software-based (CPU) rendering. **Important:** Enabling this setting with potentially compromised graphics devices or drivers might pose a risk to the host device.
**Disabled or not configured.** Microsoft Defender Application Guard uses software-based (CPU) rendering and won’t load any third-party graphics drivers or interact with any connected graphics hardware.|
+|Allow camera and microphone access in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher
Windows 11|Determines whether to allow camera and microphone access inside Microsoft Defender Application Guard.|**Enabled.** Applications inside Microsoft Defender Application Guard are able to access the camera and microphone on the user's device. **Important:** Enabling this policy with a potentially compromised container could bypass camera and microphone permissions and access the camera and microphone without the user's knowledge.
**Disabled or not configured.** Applications inside Microsoft Defender Application Guard are unable to access the camera and microphone on the user's device.|
+|Allow Microsoft Defender Application Guard to use Root Certificate Authorities from a user's device|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher
Windows 11|Determines whether Root Certificates are shared with Microsoft Defender Application Guard.|**Enabled.** Certificates matching the specified thumbprint are transferred into the container. Use a comma to separate multiple certificates.
**Disabled or not configured.** Certificates aren't shared with Microsoft Defender Application Guard.|
|Allow auditing events in Microsoft Defender Application Guard|Windows 10 Enterprise, 1809 or higher
Windows 10 Pro, 1809 or higher
Windows 11|This policy setting allows you to decide whether auditing events can be collected from Microsoft Defender Application Guard.|**Enabled.** Application Guard inherits auditing policies from your device and logs system events from the Application Guard container to your host.
**Disabled or not configured.** event logs aren't collected from your Application Guard container.|
## Application Guard support dialog settings
-These settings are located at `Administrative Templates\Windows Components\Windows Security\Enterprise Customization`. If an error is encountered, you are presented with a dialog box. By default, this dialog box only contains the error information and a button for you to report it to Microsoft via the feedback hub. However, it is possible to provide additional information in the dialog box.
+These settings are located at `Administrative Templates\Windows Components\Windows Security\Enterprise Customization`. If an error is encountered, you're presented with a dialog box. By default, this dialog box only contains the error information and a button for you to report it to Microsoft via the feedback hub. However, it's possible to provide additional information in the dialog box.
[Use Group Policy to enable and customize contact information](/windows/security/threat-protection/windows-defender-security-center/wdsc-customize-contact-information#use-group-policy-to-enable-and-customize-contact-information).
diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml
index b641427ea4..a11ce82298 100644
--- a/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml
+++ b/windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml
@@ -41,16 +41,16 @@ sections:
answer: |
The manual or PAC server must be a hostname (not IP) that is neutral on the site-list. Additionally, if the PAC script returns a proxy, it must meet those same requirements.
- To make sure the FQDNs (Fully Qualified Domain Names) for the “PAC file” and the “proxy servers the PAC file redirects to” are added as Neutral Resources in the Network Isolation policies used by Application Guard, you can:
+ To ensure the FQDNs (Fully Qualified Domain Names) for the “PAC file” and the “proxy servers the PAC file redirects to” are added as Neutral Resources in the Network Isolation policies used by Application Guard, you can:
- - Verify this by going to edge://application-guard-internals/#utilities and entering the FQDN for the pac/proxy in the “check url trust” field and verifying that it says “Neutral”.
+ - Verify this addition by going to edge://application-guard-internals/#utilities and entering the FQDN for the pac/proxy in the “check url trust” field and verifying that it says “Neutral”.
- It must be an FQDN. A simple IP address won't work.
- Optionally, if possible, the IP addresses associated with the server hosting the above should be removed from the Enterprise IP Ranges in the Network Isolation policies used by Application Guard.
- question: |
How do I configure Microsoft Defender Application Guard to work with my network proxy (IP-Literal Addresses)?
answer: |
- Application Guard requires proxies to have a symbolic name, not just an IP address. IP-Literal proxy settings such as `192.168.1.4:81` can be annotated as `itproxy:81` or using a record such as `P19216810010` for a proxy with an IP address of `192.168.100.10`. This applies to Windows 10 Enterprise edition, version 1709 or higher. These would be for the proxy policies under Network Isolation in Group Policy or Intune.
+ Application Guard requires proxies to have a symbolic name, not just an IP address. IP-Literal proxy settings such as `192.168.1.4:81` can be annotated as `itproxy:81` or using a record such as `P19216810010` for a proxy with an IP address of `192.168.100.10`. This annotation applies to Windows 10 Enterprise edition, version 1709 or higher. These annotations would be for the proxy policies under Network Isolation in Group Policy or Intune.
- question: |
Which Input Method Editors (IME) in 19H1 aren't supported?
@@ -73,19 +73,19 @@ sections:
- question: |
I enabled the hardware acceleration policy on my Windows 10 Enterprise, version 1803 deployment. Why are my users still only getting CPU rendering?
answer: |
- This feature is currently experimental only and isn't functional without an additional registry key provided by Microsoft. If you would like to evaluate this feature on a deployment of Windows 10 Enterprise, version 1803, contact Microsoft and we’ll work with you to enable the feature.
+ This feature is currently experimental only and isn't functional without an extra registry key provided by Microsoft. If you would like to evaluate this feature on a deployment of Windows 10 Enterprise, version 1803, contact Microsoft and we’ll work with you to enable the feature.
- question: |
What is the WDAGUtilityAccount local account?
answer: |
- WDAGUtilityAccount is part of Application Guard, beginning with Windows 10, version 1709 (Fall Creators Update). It remains disabled by default, unless Application Guard is enabled on your device. WDAGUtilityAccount is used to sign in to the Application Guard container as a standard user with a random password. It is NOT a malicious account. It requires *Logon as a service* permissions to be able to function correctly. If this permission is denied, you might see the following error:
+ WDAGUtilityAccount is part of Application Guard, beginning with Windows 10, version 1709 (Fall Creators Update). It remains disabled by default, unless Application Guard is enabled on your device. WDAGUtilityAccount is used to sign in to the Application Guard container as a standard user with a random password. It's NOT a malicious account. It requires *Logon as a service* permissions to be able to function correctly. If this permission is denied, you might see the following error:
**Error: 0x80070569, Ext error: 0x00000001; RDP: Error: 0x00000000, Ext error: 0x00000000 Location: 0x00000000**
- question: |
How do I trust a subdomain in my site list?
answer: |
- To trust a subdomain, you must precede your domain with two dots (..). For example: `..contoso.com` ensures that `mail.contoso.com` or `news.contoso.com` are trusted. The first dot represents the strings for the subdomain name (mail or news), and the second dot recognizes the start of the domain name (`contoso.com`). This prevents sites such as `fakesitecontoso.com` from being trusted.
+ To trust a subdomain, you must precede your domain with two dots (..). For example: `..contoso.com` ensures that `mail.contoso.com` or `news.contoso.com` are trusted. The first dot represents the strings for the subdomain name (mail or news), and the second dot recognizes the start of the domain name (`contoso.com`). These two dots prevent sites such as `fakesitecontoso.com` from being trusted.
- question: |
Are there differences between using Application Guard on Windows Pro vs Windows Enterprise?
@@ -128,7 +128,7 @@ sections:
- question: |
Why am I getting the error message "ERR_NAME_NOT_RESOLVED" after not being able to reach the PAC file?
answer: |
- This is a known issue. To mitigate this you need to create two firewall rules. For information about creating a firewall rule by using Group Policy, see the following resources:
+ This issue is a known one. To mitigate this issue, you need to create two firewall rules. For information about creating a firewall rule by using Group Policy, see the following resources:
- [Create an inbound icmp rule](../windows-firewall/create-an-inbound-icmp-rule.md)
- [Open Group Policy management console for Microsoft Defender Firewall](../windows-firewall/open-the-group-policy-management-console-to-windows-firewall-with-advanced-security.md)
@@ -143,7 +143,7 @@ sections:
- Port 67
### Second rule (DHCP Client)
- This is the same as the first rule, but scoped to local port 68. In the Microsoft Defender Firewall user interface go through the following steps:
+ This rule is the same as the first rule, but scoped to local port 68. In the Microsoft Defender Firewall user interface go through the following steps:
1. Right-click on inbound rules, and then create a new rule.
@@ -171,17 +171,17 @@ sections:
- question: |
How can I disable portions of ICS without breaking Application Guard?
answer: |
- ICS is enabled by default in Windows, and ICS must be enabled in order for Application Guard to function correctly. We do not recommend disabling ICS; however, you can disable ICS in part by using a Group Policy and editing registry keys.
+ ICS is enabled by default in Windows, and ICS must be enabled in order for Application Guard to function correctly. We don't recommend disabling ICS; however, you can disable ICS in part by using a Group Policy and editing registry keys.
1. In the Group Policy setting, **Prohibit use of Internet Connection Sharing on your DNS domain network**, set it to **Disabled**.
2. Disable IpNat.sys from ICS load as follows:
`System\CurrentControlSet\Services\SharedAccess\Parameters\DisableIpNat = 1`
- 3. Configure ICS (SharedAccess) to enabled as follows:
+ 3. Configure ICS (SharedAccess) to be enabled as follows:
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Start = 3`
- 4. (This is optional) Disable IPNAT as follows:
+ 4. (This step is optional) Disable IPNAT as follows:
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPNat\Start = 4`
5. Reboot the device.
@@ -210,9 +210,9 @@ sections:
- `{71a27cdd-812a-11d0-bec7-08002be2092f}`
- question: |
- I'm encountering TCP fragmentation issues, and cannot enable my VPN connection. How do I fix this?
+ I'm encountering TCP fragmentation issues, and can't enable my VPN connection. How do I fix this issue?
answer: |
- WinNAT drops ICMP/UDP messages with packets greater than MTU when using Default Switch or Docker NAT network. Support for this has been added in [KB4571744](https://www.catalog.update.microsoft.com/Search.aspx?q=4571744). To fix the issue, install the update and enable the fix by following these steps:
+ WinNAT drops ICMP/UDP messages with packets greater than MTU when using Default Switch or Docker NAT network. Support for this solution has been added in [KB4571744](https://www.catalog.update.microsoft.com/Search.aspx?q=4571744). To fix the issue, install the update and enable the fix by following these steps:
1. Ensure that the FragmentAware DWORD is set to 1 in this registry setting: `\Registry\Machine\SYSTEM\CurrentControlSet\Services\Winnat`.
diff --git a/windows/security/threat-protection/microsoft-defender-application-guard/reqs-md-app-guard.md b/windows/security/threat-protection/microsoft-defender-application-guard/reqs-md-app-guard.md
index d91da6e81c..ddf7e13d0d 100644
--- a/windows/security/threat-protection/microsoft-defender-application-guard/reqs-md-app-guard.md
+++ b/windows/security/threat-protection/microsoft-defender-application-guard/reqs-md-app-guard.md
@@ -33,11 +33,11 @@ Your environment must have the following hardware to run Microsoft Defender Appl
| Hardware | Description |
|--------|-----------|
-| 64-bit CPU|A 64-bit computer with minimum 4 cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more info about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more info about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
+| 64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more info about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more info about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
| CPU virtualization extensions|Extended page tables, also called _Second Level Address Translation (SLAT)_
**AND**
One of the following virtualization extensions for VBS:
VT-x (Intel)
**OR**
AMD-V |
-| Hardware memory | Microsoft requires a minimum of 8GB RAM |
-| Hard disk | 5 GB free space, solid state disk (SSD) recommended |
-| Input/Output Memory Management Unit (IOMMU) support| Not required, but strongly recommended |
+| Hardware memory | Microsoft requires a minimum of 8-GB RAM |
+| Hard disk | 5-GB free space, solid state disk (SSD) recommended |
+| Input/Output Memory Management Unit (IOMMU) support| Not required, but recommended |
## Software requirements
@@ -45,6 +45,6 @@ Your environment must have the following hardware to run Microsoft Defender Appl
| Software | Description |
|--------|-----------|
-| Operating system | Windows 10 Enterprise edition, version 1809 or higher
Windows 10 Professional edition, version 1809 or higher
Windows 10 Professional for Workstations edition, version 1809 or higher
Windows 10 Professional Education edition, version 1809 or higher
Windows 10 Education edition, version 1809 or higher
Professional editions are only supported for non-managed devices; Intune or any other 3rd party mobile device management (MDM) solutions are not supported with MDAG for Professional editions.
Windows 11 |
+| Operating system | Windows 10 Enterprise edition, version 1809 or higher
Windows 10 Professional edition, version 1809 or higher
Windows 10 Professional for Workstations edition, version 1809 or higher
Windows 10 Professional Education edition, version 1809 or higher
Windows 10 Education edition, version 1809 or higher
Professional editions are only supported for non-managed devices; Intune or any other third-party mobile device management (MDM) solutions aren't supported with MDAG for Professional editions.
Windows 11 |
| Browser | Microsoft Edge |
| Management system
(only for managed devices)| [Microsoft Intune](/intune/)
**OR**
[Microsoft Endpoint Configuration Manager](/configmgr/)
**OR**
[Group Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753298(v=ws.11))
**OR**
Your current, company-wide, non-Microsoft mobile device management (MDM) solution. For info about non-Mirosoft MDM solutions, see the documentation that came with your product. |
diff --git a/windows/security/threat-protection/msft-security-dev-lifecycle.md b/windows/security/threat-protection/msft-security-dev-lifecycle.md
index 9be071fa44..e6403fafa5 100644
--- a/windows/security/threat-protection/msft-security-dev-lifecycle.md
+++ b/windows/security/threat-protection/msft-security-dev-lifecycle.md
@@ -1,6 +1,6 @@
---
title: Microsoft Security Development Lifecycle
-description: Download the Microsoft Security Development Lifecycle white paper which covers a security assurance process focused on software development.
+description: Download the Microsoft Security Development Lifecycle white paper that covers a security assurance process focused on software development.
ms.prod: m365-security
author: dansimp
ms.author: dansimp
@@ -18,7 +18,7 @@ The Security Development Lifecycle (SDL) is a security assurance process that is
[:::image type="content" source="images/simplified-sdl.png" alt-text="Simplified secure development lifecycle":::](https://www.microsoft.com/en-us/securityengineering/sdl)
-Combining a holistic and practical approach, the SDL aims to reduce the number and severity of vulnerabilities in software. The SDL introduces security and privacy throughout all phases of the development process.
+With the help of the combination of a holistic and practical approach, the SDL aims to reduce the number and severity of vulnerabilities in software. The SDL introduces security and privacy throughout all phases of the development process.
The Microsoft SDL is based on three core concepts:
- Education
diff --git a/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies.md b/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies.md
index 681a9ae413..c19f67e476 100644
--- a/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies.md
+++ b/windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies.md
@@ -22,14 +22,14 @@ Windows 10 includes Group Policy-configurable “Process Mitigation Options” t
> [!IMPORTANT]
> We recommend trying these mitigations in a test lab before deploying to your organization, to determine if they interfere with your organization’s required apps.
-The Group Policy settings in this topic are related to three types of process mitigations. In Windows 10, all three types are on by default for 64-bit applications, but by using the Group Policy settings described in this topic, you can configure additional protections. The types of process mitigations are:
+The Group Policy settings in this topic are related to three types of process mitigations. In Windows 10, all three types are on by default for 64-bit applications, but by using the Group Policy settings described in this topic, you can configure more protections. The types of process mitigations are:
- **Data Execution Prevention (DEP)** is a system-level memory protection feature that enables the operating system to mark one or more pages of memory as non-executable, preventing code from being run from that region of memory, to help prevent exploitation of buffer overruns. DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. For more information, see [Data Execution Prevention](overview-of-threat-mitigations-in-windows-10.md#data-execution-prevention).
-- **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they have been compiled with the latest improvements. For more information, see [Structured Exception Handling Overwrite Protection](overview-of-threat-mitigations-in-windows-10.md#structured-exception-handling-overwrite-protection).
+- **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they've been compiled with the latest improvements. For more information, see [Structured Exception Handling Overwrite Protection](overview-of-threat-mitigations-in-windows-10.md#structured-exception-handling-overwrite-protection).
- **Address Space Layout Randomization (ASLR)** loads DLLs into random memory addresses at boot time to mitigate against malware that’s designed to attack specific memory locations, where specific DLLs are expected to be loaded. For more information, see [Address Space Layout Randomization](overview-of-threat-mitigations-in-windows-10.md#address-space-layout-randomization).
- To find additional ASLR protections in the table below, look for `IMAGES` or `ASLR`.
+ To find more ASLR protections in the table below, look for `IMAGES` or `ASLR`.
The following procedure describes how to use Group Policy to override individual **Process Mitigation Options** settings.
diff --git a/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md b/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md
index 436d94ab00..804ade53d1 100644
--- a/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md
+++ b/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md
@@ -21,7 +21,7 @@ This topic provides an overview of some of the software and firmware threats fac
|--------------|-------------------------|
| [The security threat landscape](#threat-landscape) | Describes the current nature of the security threat landscape, and outlines how Windows 10 is designed to mitigate software exploits and similar threats. |
| [Windows 10 mitigations that you can configure](#windows-10-mitigations-that-you-can-configure) | Provides tables of configurable threat mitigations with links to more information. Product features such as Device Guard appear in [Table 1](#windows-10-mitigations-that-you-can-configure), and memory protection options such as Data Execution Prevention appear in [Table 2](#table-2). |
-| [Mitigations that are built in to Windows 10](#mitigations-that-are-built-in-to-windows-10) | Provides descriptions of Windows 10 mitigations that require no configuration—they are built into the operating system. For example, heap protections and kernel pool protections are built into Windows 10. |
+| [Mitigations that are built in to Windows 10](#mitigations-that-are-built-in-to-windows-10) | Provides descriptions of Windows 10 mitigations that require no configuration—they're built into the operating system. For example, heap protections and kernel pool protections are built into Windows 10. |
| [Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit](#understanding-windows-10-in-relation-to-the-enhanced-mitigation-experience-toolkit) | Describes how mitigations in the [Enhanced Mitigation Experience Toolkit (EMET)](https://www.microsoft.com/download/details.aspx?id=48240) correspond to features built into Windows 10 and how to convert EMET settings into mitigation policies for Windows 10. |
This topic focuses on pre-breach mitigations aimed at device protection and threat resistance. These protections work with other security defenses in Windows 10, as shown in the following illustration:
@@ -60,7 +60,7 @@ Windows 10 mitigations that you can configure are listed in the following two ta
| **Device Guard**
helps keep a device
from running malware or
other untrusted apps | Device Guard includes a Code Integrity policy that you create; an allowlist of trusted apps—the only apps allowed to run in your organization. Device Guard also includes a powerful system mitigation called hypervisor-protected code integrity (HVCI), which uses virtualization-based security (VBS) to protect Windows' kernel-mode code integrity validation process. HVCI has specific hardware requirements, and works with Code Integrity policies to help stop attacks even if they gain access to the kernel.
Device Guard is included in Windows 10 Enterprise and Windows Server 2016.
**More information**: [Introduction to Device Guard](/windows/device-security/device-guard/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies) |
| **Microsoft Defender Antivirus**,
which helps keep devices
free of viruses and other
malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox anti-malware solution. Microsoft Defender Antivirus has been improved to a considerable extent since it was introduced in Windows 8.
**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Blocking of untrusted fonts**
helps prevent fonts
from being used in
elevation-of-privilege attacks | Block Untrusted Fonts is a setting that allows you to prevent users from loading fonts that are "untrusted" onto your network, which can mitigate elevation-of-privilege attacks associated with the parsing of font files. However, as of Windows 10, version 1703, this mitigation is less important, because font parsing is isolated in an [AppContainer sandbox](/windows/win32/secauthz/appcontainer-isolation) (for a list describing this and other kernel pool protections, see [Kernel pool protections](#kernel-pool-protections), later in this topic).
**More information**: [Block untrusted fonts in an enterprise](/windows/threat-protection/block-untrusted-fonts-in-enterprise) |
-| **Memory protections**
help prevent malware
from using memory manipulation
techniques such as buffer
overruns | These mitigations, listed in [Table 2](#table-2), help to protect against memory-based attacks, where malware or other code manipulates memory to gain control of a system (for example, malware that attempts to use buffer overruns to inject malicious executable code into memory. Note:
A subset of apps will not be able to run if some of these mitigations are set to their most restrictive settings. Testing can help you maximize protection while still allowing these apps to run.
**More information**: [Table 2](#table-2), later in this topic |
+| **Memory protections**
help prevent malware
from using memory manipulation
techniques such as buffer
overruns | These mitigations, listed in [Table 2](#table-2), help to protect against memory-based attacks, where malware or other code manipulates memory to gain control of a system (for example, malware that attempts to use buffer overruns to inject malicious executable code into memory. Note:
A subset of apps won't be able to run if some of these mitigations are set to their most restrictive settings. Testing can help you maximize protection while still allowing these apps to run.
**More information**: [Table 2](#table-2), later in this topic |
| **UEFI Secure Boot**
helps protect
the platform from
boot kits and rootkits | Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard for firmware built in to PCs by manufacturers beginning with Windows 8. It helps to protect the boot process and firmware against tampering, such as from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup.
**More information**: [UEFI and Secure Boot](/windows/device-security/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot) |
| **Early Launch Antimalware (ELAM)**
helps protect
the platform from
rootkits disguised as drivers | Early Launch Antimalware (ELAM) is designed to enable the anti-malware solution to start before all non-Microsoft drivers and apps. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits.
**More information**: [Early Launch Antimalware](/windows/device-security/bitlocker/bitlocker-countermeasures#protection-during-startup) |
| **Device Health Attestation**
helps prevent
compromised devices from
accessing an organization's
assets | Device Health Attestation (DHA) provides a way to confirm that devices attempting to connect to an organization's network are in a healthy state, not compromised with malware. When DHA has been configured, a device's actual boot data measurements can be checked against the expected "healthy" boot data. If the check indicates a device is unhealthy, the device can be prevented from accessing the network.
**More information**: [Control the health of Windows 10-based devices](/windows/device-security/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices) and [Device Health Attestation](/windows-server/security/device-health-attestation) |
@@ -73,8 +73,8 @@ As an IT professional, you can ask application developers and software vendors t
| Mitigation and corresponding threat | Description |
|---|---|
-| **Data Execution Prevention (DEP)**
helps prevent
exploitation of buffer overruns | **Data Execution Prevention (DEP)** is a system-level memory protection feature available in Windows operating systems. DEP enables the operating system to mark one or more pages of memory as non-executable, which prevents code from being run from that region of memory, to help prevent exploitation of buffer overruns.
DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. Although some applications have compatibility problems with DEP, most applications do not.
**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.
**Group Policy settings**: DEP is on by default for 64-bit applications, but you can configure more DEP protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
-| **SEHOP**
helps prevent
overwrites of the
Structured Exception Handler | **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to help block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they have been compiled with the latest improvements. A few applications have compatibility problems with SEHOP, so be sure to test for your environment.
**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.
**Group Policy setting**: SEHOP is on by default for 64-bit applications, but you can configure more SEHOP protections by using the Group Policy setting described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
+| **Data Execution Prevention (DEP)**
helps prevent
exploitation of buffer overruns | **Data Execution Prevention (DEP)** is a system-level memory protection feature available in Windows operating systems. DEP enables the operating system to mark one or more pages of memory as non-executable, which prevents code from being run from that region of memory, to help prevent exploitation of buffer overruns.
DEP helps prevent code from being run from data pages such as the default heap, stacks, and memory pools. Although some applications have compatibility problems with DEP, most applications don't.
**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.
**Group Policy settings**: DEP is on by default for 64-bit applications, but you can configure more DEP protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
+| **SEHOP**
helps prevent
overwrites of the
Structured Exception Handler | **Structured Exception Handling Overwrite Protection (SEHOP)** is designed to help block exploits that use the Structured Exception Handler (SEH) overwrite technique. Because this protection mechanism is provided at run-time, it helps to protect apps regardless of whether they've been compiled with the latest improvements. A few applications have compatibility problems with SEHOP, so be sure to test for your environment.
**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.
**Group Policy setting**: SEHOP is on by default for 64-bit applications, but you can configure more SEHOP protections by using the Group Policy setting described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
| **ASLR**
helps mitigate malware
attacks based on
expected memory locations | **Address Space Layout Randomization (ASLR)** loads DLLs into random memory addresses at boot time. This loading - of specific DLLs -helps mitigate malware that's designed to attack specific memory locations.
**More information**: [Address Space Layout Randomization](#address-space-layout-randomization), later in this topic.
**Group Policy settings**: ASLR is on by default for 64-bit applications, but you can configure more ASLR protections by using the Group Policy settings described in [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md). |
### Windows Defender SmartScreen
@@ -147,7 +147,7 @@ You can use Control Panel to view or change DEP settings.
- **Turn on DEP for essential Windows programs and services only**
- - **Turn on DEP for all programs and services except those I select**. If you choose this option, use the **Add** and **Remove** buttons to create the list of exceptions for which DEP will not be turned on.
+ - **Turn on DEP for all programs and services except those I select**. If you choose this option, use the **Add** and **Remove** buttons to create the list of exceptions for which DEP won't be turned on.
#### To use Group Policy to control DEP settings
@@ -155,7 +155,7 @@ You can use the Group Policy setting called **Process Mitigation Options** to co
### Structured Exception Handling Overwrite Protection
-Structured Exception Handling Overwrite Protection (SEHOP) helps prevent attackers from being able to use malicious code to exploit the [Structured Exception Handling](/windows/win32/debug/structured-exception-handling) (SEH), which is integral to the system and allows (non-malicious) apps to handle exceptions appropriately. Because this protection mechanism is provided at run-time, it helps to protect applications regardless of whether they have been compiled with the latest improvements.
+Structured Exception Handling Overwrite Protection (SEHOP) helps prevent attackers from being able to use malicious code to exploit the [Structured Exception Handling](/windows/win32/debug/structured-exception-handling) (SEH), which is integral to the system and allows (non-malicious) apps to handle exceptions appropriately. Because this protection mechanism is provided at run-time, it helps to protect applications regardless of whether they've been compiled with the latest improvements.
You can use the Group Policy setting called **Process Mitigation Options** to control the SEHOP setting. A few applications have compatibility problems with SEHOP, so be sure to test for your environment. To use the Group Policy setting, see [Override Process Mitigation Options to help enforce app-related security policies](override-mitigation-options-for-app-related-security-policies.md).
@@ -163,7 +163,7 @@ You can use the Group Policy setting called **Process Mitigation Options** to co
One of the most common techniques used to gain access to a system is to find a vulnerability in a privileged process that is already running, guess or find a location in memory where important system code and data have been placed, and then overwrite that information with a malicious payload. Any malware that could write directly to the system memory could overwrite it in well-known and predictable locations.
-Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it is more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts.
+Address Space Layout Randomization (ASLR) makes that type of attack much more difficult because it randomizes how and where important data is stored in memory. With ASLR, it's more difficult for malware to find the specific location it needs to attack. Figure 3 illustrates how ASLR works by showing how the locations of different critical Windows components can change in memory between restarts.
:::image type="content" alt-text="ASLR at work." source="images/security-fig4-aslr.png" lightbox="images/security-fig4-aslr.png":::
@@ -175,9 +175,9 @@ You can use the Group Policy setting called **Process Mitigation Options** to co
## Mitigations that are built in to Windows 10
-Windows 10 provides many threat mitigations to protect against exploits that are built into the operating system and need no configuration within the operating system. The table that follows describes some of these mitigations.
+Windows 10 provides many threat mitigations to protect against exploits that are built into the operating system and need no configuration within the operating system. The subsequent table describes some of these mitigations.
-Control Flow Guard (CFG) is a mitigation that does not need configuration within the operating system, but does require an application developer to configure the mitigation into the application when it's compiled. CFG is built into Microsoft Edge, IE11, and other areas in Windows 10, and can be built into many other applications when they are compiled.
+Control Flow Guard (CFG) is a mitigation that doesn't need configuration within the operating system, but does require an application developer to configure the mitigation into the application when it's compiled. CFG is built into Microsoft Edge, IE11, and other areas in Windows 10, and can be built into many other applications when they're compiled.
### Table 3 Windows 10 mitigations to protect against memory exploits – no configuration needed
@@ -188,7 +188,7 @@ Control Flow Guard (CFG) is a mitigation that does not need configuration within
| **Universal Windows apps protections**
screen downloadable
apps and run them in
an AppContainer sandbox | Universal Windows apps are carefully screened before being made available, and they run in an AppContainer sandbox with limited privileges and capabilities.
**More information**: [Universal Windows apps protections](#universal-windows-apps-protections), later in this topic. |
| **Heap protections**
help prevent
exploitation of the heap | Windows 10 includes protections for the heap, such as the use of internal data structures that help protect against corruption of memory used by the heap.
**More information**: [Windows heap protections](#windows-heap-protections), later in this topic. |
| **Kernel pool protections**
help prevent
exploitation of pool memory
used by the kernel | Windows 10 includes protections for the pool of memory used by the kernel. For example, safe unlinking protects against pool overruns that are combined with unlinking operations that can be used to create an attack.
**More information**: [Kernel pool protections](#kernel-pool-protections), later in this topic. |
-| **Control Flow Guard**
helps mitigate exploits
based on
flow between code locations
in memory | Control Flow Guard (CFG) is a mitigation that requires no configuration within the operating system, but instead is built into software when it's compiled. It is built into Microsoft Edge, IE11, and other areas in Windows 10. CFG can be built into applications written in C or C++, or applications compiled using Visual Studio 2015.
For such an application, CFG can detect an attacker's attempt to change the intended flow of code. If this attempt occurs, CFG terminates the application. You can request software vendors to deliver Windows applications compiled with CFG enabled.
**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
+| **Control Flow Guard**
helps mitigate exploits
based on
flow between code locations
in memory | Control Flow Guard (CFG) is a mitigation that requires no configuration within the operating system, but instead is built into software when it's compiled. It's built into Microsoft Edge, IE11, and other areas in Windows 10. CFG can be built into applications written in C or C++, or applications compiled using Visual Studio 2015.
For such an application, CFG can detect an attacker's attempt to change the intended flow of code. If this attempt occurs, CFG terminates the application. You can request software vendors to deliver Windows applications compiled with CFG enabled.
**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
| **Protections built into Microsoft Edge** (the browser)
helps mitigate multiple
threats | Windows 10 includes an entirely new browser, Microsoft Edge, designed with multiple security improvements.
**More information**: [Microsoft Edge and Internet Explorer 11](#microsoft-edge-and-internet-explorer11), later in this topic. |
### SMB hardening improvements for SYSVOL and NETLOGON shares
@@ -206,7 +206,7 @@ With Protected Processes, Windows 10 prevents untrusted processes from interacti
### Universal Windows apps protections
-When users download Universal Windows apps from the Microsoft Store, it's unlikely that they will encounter malware because all apps go through a careful screening process before being made available in the store. Apps that organizations build and distribute through sideloading processes will need to be reviewed internally to ensure that they meet organizational security requirements.
+When users download Universal Windows apps from the Microsoft Store, it's unlikely that they'll encounter malware because all apps go through a careful screening process before being made available in the store. Apps that organizations build and distribute through sideloading processes will need to be reviewed internally to ensure that they meet organizational security requirements.
Regardless of how users acquire Universal Windows apps, they can use them with increased confidence. Universal Windows apps run in an AppContainer sandbox with limited privileges and capabilities. For example, Universal Windows apps have no system-level access, have tightly controlled interactions with other apps, and have no access to data unless the user explicitly grants the application permission.
@@ -226,7 +226,7 @@ Windows 10 has several important improvements to the security of the heap:
### Kernel pool protections
-The operating system kernel in Windows sets aside two pools of memory, one which remains in physical memory ("nonpaged pool") and one that can be paged in and out of physical memory ("paged pool"). There are many mitigations that have been added over time, such as process quota pointer encoding; lookaside, delay free, and pool page cookies; and PoolIndex bounds checks. Windows 10 adds multiple "pool hardening" protections, such as integrity checks, that help protect the kernel pool against more advanced attacks.
+The operating system kernel in Windows sets aside two pools of memory, one that remains in physical memory ("nonpaged pool") and one that can be paged in and out of physical memory ("paged pool"). There are many mitigations that have been added over time, such as process quota pointer encoding; lookaside, delay free, and pool page cookies; and PoolIndex bounds checks. Windows 10 adds multiple "pool hardening" protections, such as integrity checks, that help protect the kernel pool against more advanced attacks.
In addition to pool hardening, Windows 10 includes other kernel hardening features:
@@ -240,23 +240,23 @@ In addition to pool hardening, Windows 10 includes other kernel hardening featur
- **Safe unlinking:** Helps protect against pool overruns that are combined with unlinking operations to create an attack. Windows 10 includes global safe unlinking, which extends heap and kernel pool safe unlinking to all usage of LIST\_ENTRY and includes the "FastFail" mechanism to enable rapid and safe process termination.
-- **Memory reservations**: The lowest 64 KB of process memory is reserved for the system. Apps are not allowed to allocate that portion of the memory. This allocation for the system makes it more difficult for malware to use techniques such as "NULL dereference" to overwrite critical system data structures in memory.
+- **Memory reservations**: The lowest 64 KB of process memory is reserved for the system. Apps aren't allowed to allocate that portion of the memory. This allocation for the system makes it more difficult for malware to use techniques such as "NULL dereference" to overwrite critical system data structures in memory.
### Control Flow Guard
-When applications are loaded into memory, they are allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls the other code located in other memory addresses. The relationships between the code locations are well known—they are written in the code itself—but previous to Windows 10, the flow between these locations was not enforced, which gave attackers the opportunity to change the flow to meet their needs.
+When applications are loaded into memory, they're allocated space based on the size of the code, requested memory, and other factors. When an application begins to execute code, it calls the other code located in other memory addresses. The relationships between the code locations are well known—they're written in the code itself—but previous to Windows 10, the flow between these locations wasn't enforced, which gave attackers the opportunity to change the flow to meet their needs.
-This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location is not trusted, the application is immediately terminated as a potential security risk.
+This kind of threat is mitigated in Windows 10 through the Control Flow Guard (CFG) feature. When a trusted application that was compiled to use CFG calls code, CFG verifies that the code location called is trusted for execution. If the location isn't trusted, the application is immediately terminated as a potential security risk.
-An administrator cannot configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. For example, it can be enabled for applications written in C or C++, or applications compiled using Visual Studio 2015. For information about enabling CFG for a Visual Studio 2015 project, see [Control Flow Guard](/windows/win32/secbp/control-flow-guard).
+An administrator can't configure CFG; rather, an application developer can take advantage of CFG by configuring it when the application is compiled. Consider asking application developers and software vendors to deliver trustworthy Windows applications compiled with CFG enabled. For example, it can be enabled for applications written in C or C++, or applications compiled using Visual Studio 2015. For information about enabling CFG for a Visual Studio 2015 project, see [Control Flow Guard](/windows/win32/secbp/control-flow-guard).
Browsers are a key entry point for attacks, so Microsoft Edge, IE, and other Windows features take full advantage of CFG.
### Microsoft Edge and Internet Explorer 11
-Browser security is a critical component of any security strategy, and for good reason: the browser is the user's interface to the Internet, an environment with many malicious sites and content waiting to attack. Most users cannot perform at least part of their job without a browser, and many users are reliant on one. This reality has made the browser the common pathway from which malicious hackers initiate their attacks.
+Browser security is a critical component of any security strategy, and for good reason: the browser is the user's interface to the Internet, an environment with many malicious sites and content waiting to attack. Most users can't perform at least part of their job without a browser, and many users are reliant on one. This reality has made the browser the common pathway from which malicious hackers initiate their attacks.
-All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples are Flash and Java extensions that enable their respective applications to run inside a browser. Keeping Windows 10 secure for web browsing and applications, especially for these two content types, is a priority.
+All browsers enable some amount of extensibility to do things beyond the original scope of the browser. Two common examples are Flash and Java extensions that enable their respective applications to run inside a browser. The security of Windows 10 for the purposes of web browsing and applications, especially for these two content types, is a priority.
Windows 10 includes an entirely new browser, Microsoft Edge. Microsoft Edge is more secure in multiple ways, especially:
@@ -270,13 +270,13 @@ Windows 10 includes an entirely new browser, Microsoft Edge. Microsoft Edge is m
- **Simplifies security configuration tasks.** Because Microsoft Edge uses a simplified application structure and a single sandbox configuration, there are fewer required security settings. In addition, Microsoft Edge default settings align with security best practices, making it more secure by default.
-In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10, primarily for backwards-compatibility with websites and with binary extensions that do not work with Microsoft Edge. You cannot configure it as the primary browser but rather as an optional or automatic switchover. We recommend using Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security.
+In addition to Microsoft Edge, Microsoft includes IE11 in Windows 10, primarily for backwards-compatibility with websites and with binary extensions that don't work with Microsoft Edge. You can't configure it as the primary browser but rather as an optional or automatic switchover. We recommend using Microsoft Edge as the primary web browser because it provides compatibility with the modern web and the best possible security.
For sites that require IE11 compatibility, including those sites that require binary extensions and plug-ins, enable Enterprise mode and use the Enterprise Mode Site List to define which sites have the dependency. With this configuration, when Microsoft Edge identifies a site that requires IE11, users will automatically be switched to IE11.
### Functions that software vendors can use to build mitigations into apps
-Some of the protections available in Windows 10 are provided through functions that can be called from apps or other software. Such software is less likely to provide openings for exploits. If you are working with a software vendor, you can request that they include these security-oriented functions in the application. The following table lists some types of mitigations and the corresponding security-oriented functions that can be used in apps.
+Some of the protections available in Windows 10 are provided through functions that can be called from apps or other software. Such software is less likely to provide openings for exploits. If you're working with a software vendor, you can request that they include these security-oriented functions in the application. The following table lists some types of mitigations and the corresponding security-oriented functions that can be used in apps.
> [!NOTE]
> Control Flow Guard (CFG) is also an important mitigation that a developer can include in software when it is compiled. For more information, see [Control Flow Guard](#control-flow-guard), earlier in this topic.
@@ -297,7 +297,7 @@ Some of the protections available in Windows 10 are provided through functions t
## Understanding Windows 10 in relation to the Enhanced Mitigation Experience Toolkit
-You might already be familiar with the [Enhanced Mitigation Experience Toolkit (EMET)](https://support.microsoft.com/topic/emet-mitigations-guidelines-b529d543-2a81-7b5a-d529-84b30e1ecee0), which has since 2009 offered various exploit mitigations, and an interface for configuring those mitigations. You can use this section to understand how EMET mitigations relate to those mitigations in Windows 10. Many of EMET's mitigations have been built into Windows 10, some with extra improvements. However, some EMET mitigations carry high-performance cost, or appear to be relatively ineffective against modern threats, and therefore have not been brought into Windows 10.
+You might already be familiar with the [Enhanced Mitigation Experience Toolkit (EMET)](https://support.microsoft.com/topic/emet-mitigations-guidelines-b529d543-2a81-7b5a-d529-84b30e1ecee0), which has since 2009 offered various exploit mitigations, and an interface for configuring those mitigations. You can use this section to understand how EMET mitigations relate to those mitigations in Windows 10. Many of EMET's mitigations have been built into Windows 10, some with extra improvements. However, some EMET mitigations carry high-performance cost, or appear to be relatively ineffective against modern threats, and therefore haven't been brought into Windows 10.
Because many of EMET's mitigations and security mechanisms already exist in Windows 10 and have been improved, particularly the ones assessed to have high effectiveness at mitigating known bypasses, version 5.5*x* has been announced as the final major version release for EMET (see [Enhanced Mitigation Experience Toolkit](https://web.archive.org/web/20170928073955/https://technet.microsoft.com/en-US/security/jj653751)).
@@ -310,7 +310,7 @@ The following table lists EMET features in relation to Windows 10 features.
|
DEPSEHOPASLR (Force ASLR, Bottom-up ASLR)|DEP, SEHOP, and ASLR are included in Windows 10 as configurable features. See [Table 2](#table-2), earlier in this topic.You can install the ProcessMitigations PowerShell module to convert your EMET settings for these features into policies that you can apply to Windows 10.|
|Load Library Check (LoadLib)Memory Protection Check (MemProt)|LoadLib and MemProt are supported in Windows 10, for all applications that are written to use these functions. See [Table 4](#functions-that-software-vendors-can-use-to-build-mitigations-into-apps), earlier in this topic.|
|Null Page|Mitigations for this threat are built into Windows 10, as described in the "Memory reservations" item in [Kernel pool protections](#kernel-pool-protections), earlier in this topic.|
-|Heap SprayEAFEAF+|Windows 10 does not include mitigations that map specifically to these EMET features because they have low impact in the current threat landscape, and do not significantly increase the difficulty of exploiting vulnerabilities. Microsoft remains committed to monitoring the security environment as new exploits appear and taking steps to harden the operating system against them.|
+|Heap SprayEAFEAF+|Windows 10 doesn't include mitigations that map specifically to these EMET features because they have low impact in the current threat landscape, and don't significantly increase the difficulty of exploiting vulnerabilities. Microsoft remains committed to monitoring the security environment as new exploits appear and taking steps to harden the operating system against them.|
|Caller CheckSimulate Execution FlowStack PivotDeep Hooks (an ROP "Advanced Mitigation")Anti Detours (an ROP "Advanced Mitigation")Banned Functions (an ROP "Advanced Mitigation")|Mitigated in Windows 10 with applications compiled with Control Flow Guard, as described in [Control Flow Guard](#control-flow-guard), earlier in this topic.|
### Converting an EMET XML settings file into Windows 10 mitigation policies
diff --git a/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md b/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
index ed70e30816..36714ba7df 100644
--- a/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
+++ b/windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
@@ -35,7 +35,7 @@ Windows 10 is an important component of an end-to-end security solution that foc
## Description of a robust end-to-end security solution
-Today’s computing threat landscape is increasing at a speed never encountered before. The sophistication of criminal attacks is growing, and there is no doubt that malware now targets both consumers and professionals in all industries.
+Today’s computing threat landscape is increasing at a speed never encountered before. The sophistication of criminal attacks is growing, and there's no doubt that malware now targets both consumers and professionals in all industries.
During recent years, one particular category of threat has become prevalent: advanced persistent threats (APTs). The term APT is commonly used to describe any attack that seems to target individual organizations on an on-going basis. In fact, this type of attack typically involves determined adversaries who may use any methods or techniques necessary.
@@ -61,7 +61,7 @@ The following figure shows a solution built to assess device health from the clo
Windows devices can be protected from low-level rootkits and bootkits by using low-level hardware technologies such as Unified Extensible Firmware Interface (UEFI) Secure Boot.
-Secure Boot is a firmware validation process that helps prevent rootkit attacks; it is part of the UEFI specification. The intent of UEFI is to define a standard way for the operating system to communicate with modern hardware, which can perform faster and with more efficient input/output (I/O) functions than older, software interrupt-driven BIOS systems.
+Secure Boot is a firmware validation process that helps prevent rootkit attacks; it's part of the UEFI specification. The intent of UEFI is to define a standard way for the operating system to communicate with modern hardware, which can perform faster and with more efficient input/output (I/O) functions than older, software interrupt-driven BIOS systems.
A device health attestation module can communicate measured boot data that is protected by a Trusted Platform Module (TPM) to a remote service. After the device successfully boots, boot process measurement data is sent to a trusted cloud service (Health Attestation Service) using a more secure and tamper-resistant communication channel.
@@ -118,7 +118,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
Windows 10 uses security characteristics of a TPM for measuring boot integrity sequence (and based on that, unlocking automatically BitLocker protected drives), for protecting credentials or for health attestation.
- A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that are not compatible with each other:
+ A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). At the time of this writing, there are two versions of TPM specification produced by TCG that aren't compatible with each other:
- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard.
- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015.
@@ -149,15 +149,15 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
The most basic protection is the Secure Boot feature, which is a standard part of the UEFI 2.2+ architecture. On a PC with conventional BIOS, anyone who can take control of the boot process can boot by using an alternative OS loader, and potentially gain access to system resources. When Secure Boot is enabled, you can boot using only an OS loader that’s signed using a certificate stored in the UEFI Secure Boot DB. Naturally, the Microsoft certificate used to digitally sign the Windows 10 OS loaders are in that store, which allows UEFI to validate the certificate as part of its security policy. Secure Boot must be enabled by default on all computers that are certified for Windows 10 under the Windows Hardware Compatibility Program.
Secure Boot is a UEFI firmware-based feature, which allows for the signing and verification of critical boot files and drivers at boot time. Secure Boot checks signature values of the Windows Boot Manager, BCD store, Windows OS loader file, and other boot critical DLLs at boot time before the system is allowed to fully boot into a usable operating system by using policies that are defined by the OEM at build time. Secure Boot prevents many types of boot-based rootkit, malware, and other security-related attacks against the Windows platform. Secure Boot protects the operating system boot process whether booting from local hard disk, USB, PXE, or DVD, or into full Windows or Windows Recovery Environment (RE).
- Secure Boot protects the boot environment of a Windows 10 installation by verifying the signatures of the critical boot components to confirm malicious activity did not compromise them. Secure Boot protection ends after the Windows kernel file (ntoskrnl.exe) has been loaded.
+ Secure Boot protects the boot environment of a Windows 10 installation by verifying the signatures of the critical boot components to confirm malicious activity didn't compromise them. Secure Boot protection ends after the Windows kernel file (ntoskrnl.exe) has been loaded.
> [!NOTE]
> Secure Boot protects the platform until the Windows kernel is loaded. Then protections like ELAM take over.
- **Secure Boot configuration policy.** Extends Secure Boot functionality to critical Windows 10 configuration.
- Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) cannot be enabled. This protective action ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
- Secure Boot configuration policy does this with UEFI policy. These signatures for these policies are signed in the same way that operating system binaries are signed for use with Secure Boot.
+ Examples of protected configuration information include protecting Disable Execute bit (NX option) or ensuring that the test signing policy (code integrity) can't be enabled. This protective action ensures that the binaries and configuration of the computer can be trusted after the boot process has completed.
+ Secure Boot configuration policy does this protective action with UEFI policy. These signatures for these policies are signed in the same way that operating system binaries are signed for use with Secure Boot.
The Secure Boot configuration policy must be signed by a private key that corresponds to one of the public keys stored in the Key Exchange Key (KEK) list. The Microsoft Certificate Authority (CA) will be present in the KEK list of all Windows certified Secure Boot systems. By default, a policy signed by the Microsoft KEK shall be work on all Secure Boot systems. BootMgr must verify the signature against the KEK list before applying a signed policy. With Windows 10, the default Secure Boot configuration policy is embedded in bootmgr.
@@ -165,7 +165,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
- **Early Launch Antimalware (ELAM).** ELAM tests all drivers before they load and prevents unapproved drivers from loading.
- Traditional antimalware apps don’t start until after the boot drivers have been loaded, which gives a rootkit that is disguised as a driver the opportunity to work. ELAM is a Windows mechanism introduced in a previous version of Windows that allows antimalware software to run very early in the boot sequence. Thus, the antimalware component is the first third-party component to run and control the initialization of other boot drivers until the Windows operating system is operational. When the system is started with a complete runtime environment (network access, storage, and so on), then a full-featured antimalware is loaded.
+ Traditional antimalware apps don’t start until after the boot drivers have been loaded, which gives a rootkit that is disguised as a driver the opportunity to work. ELAM is a Windows mechanism introduced in a previous version of Windows that allows antimalware software to run early in the boot sequence. Thus, the antimalware component is the first third-party component to run and control the initialization of other boot drivers until the Windows operating system is operational. When the system is started with a complete runtime environment (network access, storage, and so on), then a full-featured antimalware is loaded.
ELAM can load a Microsoft or non-Microsoft antimalware driver before all non-Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible, ELAM has a simple task: Examine every boot driver and determine whether it is on the list of trusted drivers. If it’s not trusted, Windows won’t load it.
@@ -174,8 +174,8 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
The ELAM signed driver is loaded before any other third-party drivers or applications, which allows the antimalware software to detect and block any attempts to tamper with the boot process by trying to load unsigned or untrusted code.
- The ELAM driver is a small driver with a small policy database that has a very narrow scope, focused on drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be signed by Microsoft and the associated certificate must contain the complementary EKU (1.3.6.1.4.1.311.61.4.1).
-- **Virtualization-based security (Hyper-V + Secure Kernel).** Virtualization-based security is a completely new enforced security boundary that allows you to protect critical parts of Windows 10.
+ The ELAM driver is a small driver with a small policy database that has a narrow scope, focused on drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be signed by Microsoft and the associated certificate must contain the complementary EKU (1.3.6.1.4.1.311.61.4.1).
+- **Virtualization-based security (Hyper-V + Secure Kernel).** Virtualization-based security is a new enforced security boundary that allows you to protect critical parts of Windows 10.
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate domain credentials from the rest of the Windows operating system. For more information, see [Virtualization-based security](#virtual) section.
@@ -183,7 +183,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
When enabled and configured, Windows 10 can start the Hyper-V virtualization-based security services. HVCI helps protect the system core (kernel), privileged drivers, and system defenses, like antimalware solutions, by preventing malware from running early in the boot process, or after startup.
- HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This dependency on verification means that kernel memory pages can never be Writable and Executable (W+X) and executable code cannot be directly modified.
+ HVCI uses virtualization-based security to isolate Code Integrity, the only way kernel memory can become executable is through a Code Integrity verification. This dependency on verification means that kernel memory pages can never be Writable and Executable (W+X) and executable code can't be directly modified.
> [!NOTE]
> Device Guard devices that run Kernel Mode Code Integrity with virtualization-based security must have compatible drivers. For additional information, please read the [Driver compatibility with Device Guard in Windows 10](https://go.microsoft.com/fwlink/p/?LinkId=691612) blog post.
@@ -199,7 +199,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
- **Health attestation.** The device’s firmware logs the boot process, and Windows 10 can send it to a trusted server that can check and assess the device’s health.
- Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware components are made as they load during the boot process. Additionally, they are taken and measured sequentially, not all at once. When these measurements are complete, their values are digitally signed and stored securely in the TPM and cannot be changed unless the system is reset.
+ Windows 10 takes measurements of the UEFI firmware and each of the Windows and antimalware components are made as they load during the boot process. Additionally, they're taken and measured sequentially, not all at once. When these measurements are complete, their values are digitally signed and stored securely in the TPM and can't be changed unless the system is reset.
For more information, see [Secured Boot and Measured Boot: Hardening Early Boot Components Against Malware](/previous-versions/windows/hardware/design/dn653311(v=vs.85)).
@@ -217,7 +217,7 @@ The following Windows 10 services are protected with virtualization-based securi
- **Credential Guard** (LSA Credential Isolation): prevents pass-the-hash attacks and enterprise credential theft that happens by reading and dumping the content of lsass memory
- **Device Guard** (Hyper-V Code Integrity): Device Guard uses the new virtualization-based security in Windows 10 to isolate the Code Integrity service from the Windows kernel itself, which lets the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
-- **Other isolated services**: for example, on Windows Server 2016, there is the vTPM feature that allows you to have encrypted virtual machines (VMs) on servers.
+- **Other isolated services**: for example, on Windows Server 2016, there's the vTPM feature that allows you to have encrypted virtual machines (VMs) on servers.
> [!NOTE]
> Virtualization-based security is only available with Windows 10 Enterprise. Virtualization-based security requires devices with UEFI (2.3.1 or higher) with Secure Boot enabled, x64 processor with Virtualization Extensions and SLAT enabled. IOMMU, TPM 2.0. and support for Secure Memory overwritten are optional, but recommended.
@@ -234,18 +234,18 @@ remote machines, which mitigates many PtH-style attacks.
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
-- **The per-boot key** is used for any in-memory credentials that do not require persistence. An example of such a credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution Center (KDC) every time authentication occurs and is protected with a per-boot key.
+- **The per-boot key** is used for any in-memory credentials that don't require persistence. An example of such a credential would be a ticket-granting ticket (TGT) session key. This key is negotiated with a Key Distribution Center (KDC) every time authentication occurs and is protected with a per-boot key.
- **The persistent key**, or some derivative, is used to help protect items that are stored and reloaded after a reboot. Such protection is intended for long-term storage, and must be protected with a consistent key.
Credential Guard is activated by a registry key and then enabled by using a UEFI variable. This activation is done to protect against remote modifications of the configuration. The use of a UEFI variable implies that physical access is required to change the configuration. When lsass.exe detects that
credential isolation is enabled, it then spawns LsaIso.exe as an isolated process, which ensures that it runs within isolated user mode. The startup of LsaIso.exe is performed before initialization of a security support provider, which ensures that the secure mode support routines are ready before any authentication begins.
### Device Guard
-Device Guard is a new feature of Windows 10 Enterprise that allows organizations to lock down a device to help protect it from running untrusted software. In this configuration, the only applications allowed to run are those that are trusted by the organization.
+Device Guard is a new feature of Windows 10 Enterprise that allows organizations to lock down a device to help protect it from running untrusted software. In this configuration, the only applications allowed to run are those applications that are trusted by the organization.
The trust decision to execute code is performed by using Hyper-V Code Integrity, which runs in virtualization-based security, a Hyper-V protected container that runs alongside regular Windows.
-Hyper-V Code Integrity is a feature that validates the integrity of a driver or system file each time it is loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with Administrator privileges. On x64-based versions of Windows 10 kernel-mode drivers must be digitally signed.
+Hyper-V Code Integrity is a feature that validates the integrity of a driver or system file each time it's loaded into memory. Code integrity detects whether an unsigned driver or system file is being loaded into the kernel, or whether a system file has been modified by malicious software that is being run by a user account with Administrator privileges. On x64-based versions of Windows 10, kernel-mode drivers must be digitally signed.
> [!NOTE]
> Independently of activation of Device Guard Policy, [Windows 10 by default raises the bar for what runs in the kernel](https://go.microsoft.com/fwlink/p/?LinkId=691613). Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
@@ -264,7 +264,7 @@ Device Guard needs to be planned and configured to be truly effective. It isn't
There are three different parts that make up the Device Guard solution in Windows 10:
- The first part is a base **set of hardware security features** introduced with the previous version of Windows. TPM for hardware cryptographic operations and UEFI with modern firmware, along with Secure Boot, allows you to control what the device is running when the systems start.
-- After the hardware security feature, there is the code integrity engine. In Windows 10, **Code Integrity is now fully configurable** and now resides in Isolated user mode, a part of the memory that is protected by virtualization-based security.
+- After the hardware security feature, there's the code integrity engine. In Windows 10, **Code Integrity is now fully configurable** and now resides in Isolated user mode, a part of the memory that is protected by virtualization-based security.
- The last part of Device Guard is **manageability**. Code Integrity configuration is exposed through specific Group Policy Objects, PowerShell cmdlets, and MDM configuration service providers (CSPs).
For more information on how to deploy Device Guard in an enterprise, see the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
@@ -280,9 +280,9 @@ SAWs are computers that are built to help significantly reduce the risk of compr
To protect high-value assets, SAWs are used to make secure connections to those assets.
-Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool like Microsoft Endpoint Configuration Manager, Intune, or any third-party device management, then Device Guard is applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
+Similarly, on corporate fully managed workstations, where applications are installed by using a distribution tool like Microsoft Endpoint Configuration Manager, Intune, or any third-party device management, then Device Guard is applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
-It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
+It could be challenging to use Device Guard on corporate, lightly managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
Before you can benefit from the protection included in Device Guard, Code Integrity policy must be created by using tools provided by Microsoft, but the policy can be deployed with common management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10, along with restrictions on Windows 10 script hosts. Device Guard Code Integrity policy restricts what code can run on a device.
@@ -291,7 +291,7 @@ Before you can benefit from the protection included in Device Guard, Code Integr
Signed Device Guard policy offers stronger protection against a malicious local administrator trying to defeat Device Guard.
-When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable which offers tampering protection. The only way to update the Device Guard policy subsequently is to provide a new version of the policy signed by the same signer or from a signer specified as part of the
+When the policy is signed, the GUID of the policy is stored in a UEFI pre-OS secure variable that offers tampering protection. The only way to update the Device Guard policy later is to provide a new version of the policy signed by the same signer or from a signer specified as part of the
Device Guard policy into the UpdateSigner section.
### The importance of signing applications
@@ -301,13 +301,13 @@ On computers with Device Guard, Microsoft proposes to move from a world where un
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Microsoft Store infrastructure. More specifically, LOB apps will be available in a private store within the public Microsoft Store. Microsoft Store signs and distributes Universal
Windows apps and Classic Windows apps. All apps downloaded from the Microsoft Store are signed.
-In organizations today, many LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
+In organizations today, many LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for various reasons, like the lack of code signing expertise. Even if code signing is a best practice, many internal applications aren't signed.
-Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them through a process to create additional signatures that can be distributed along with existing applications.
+Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them through a process to create more signatures that can be distributed along with existing applications.
### Why are antimalware and device management solutions still necessary?
-Although allow-list mechanisms are efficient at ensuring that only trusted applications can be run, they cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
+Although allowlist mechanisms are efficient at ensuring that only trusted applications can be run, they can't prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
Vulnerabilities are weaknesses in software that could allow an attacker to compromise the integrity, availability, or confidentiality of the device. Some of the worst vulnerabilities allow attackers to exploit the compromised device by causing it to run malicious code without the user’s knowledge.
@@ -321,7 +321,7 @@ MDM solutions are becoming prevalent as a light-weight device management technol
### Device health attestation
-Device health attestation leverages the TPM to provide cryptographically strong and verifiable measurements of the chain of software used to boot the device.
+Device health attestation uses the TPM to provide cryptographically strong and verifiable measurements of the chain of software used to boot the device.
For Windows 10-based devices, Microsoft introduces a new public API that will allow MDM software to access a remote attestation service called Windows Health Attestation Service. A health attestation result, in addition with other elements, can be used to allow or deny access to networks, apps, or services, based on whether devices prove to be healthy.
@@ -335,21 +335,21 @@ The following table details the hardware requirements for both virtualization-ba
|--- |--- |
|UEFI 2.3.1 or later firmware with Secure Boot enabled|Required to support UEFI Secure Boot.UEFI Secure Boot ensures that the device boots only authorized code.
Additionally, Boot Integrity (Platform Secure Boot) must be supported following the requirements in Hardware Compatibility Specification for Systems for Windows 10 under the subsection: “System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby”|
|Virtualization extensions, such as Intel VT-x, AMD-V, and SLAT must be enabled|Required to support virtualization-based security.
**Note:** Device Guard can be enabled without using virtualization-based security.
|
-|X64 processor|Required to support virtualization-based security that uses Windows Hypervisor. Hyper-V is supported only on x64 processor (and not on x86).Direct Memory Access (DMA) protection can be enabled to provide additional memory protection but requires processors to include DMA protection technologies.|
+|X64 processor|Required to support virtualization-based security that uses Windows Hypervisor. Hyper-V is supported only on x64 processor (and not on x86).
Direct Memory Access (DMA) protection can be enabled to provide extra memory protection but requires processors to include DMA protection technologies.|
|IOMMU, such as Intel VT-d, AMD-Vi|Support for the IOMMU in Windows 10 enhances system resiliency against DMA attacks.|
-|Trusted Platform Module (TPM)|Required to support health attestation and necessary for additional key protections for virtualization-based security. TPM 2.0 is supported. Support for TPM 1.2 was added beginning in Windows 10, version 1607 (RS1)|
+|Trusted Platform Module (TPM)|Required to support health attestation and necessary for other key protections for virtualization-based security. TPM 2.0 is supported. Support for TPM 1.2 was added beginning in Windows 10, version 1607 (RS1)|
-This section presented information about several closely related controls in Windows 10. The multi-layer defenses and in-depth approach helps to eradicate low-level malware during boot sequence. Virtualization-based security is a fundamental operating system architecture change that adds a new security boundary. Device Guard and Credential Guard respectively help to block untrusted code and protect corporate domain credentials from theft and reuse. This section also briefly discussed the importance of managing devices and patching vulnerabilities. All these technologies can be used to harden and lock down devices while limiting the risk of attackers compromising them.
+This section presented information about several closely related controls in Windows 10. The multi-layer defenses and in-depth approach help to eradicate low-level malware during boot sequence. Virtualization-based security is a fundamental operating system architecture change that adds a new security boundary. Device Guard and Credential Guard respectively help to block untrusted code and protect corporate domain credentials from theft and reuse. This section also briefly discussed the importance of managing devices and patching vulnerabilities. All these technologies can be used to harden and lock down devices while limiting the risk of attackers compromising them.
## Detect an unhealthy Windows 10-based device
-As of today, many organizations only consider devices to be compliant with company policy after they’ve passed a variety of checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting isn't entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
+As of today, many organizations only consider devices to be compliant with company policy after they’ve passed various checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting isn't entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
The biggest challenge with rootkits is that they can be undetectable to the client. Because they start before antimalware, and they have system-level privileges, they can completely disguise themselves while continuing to access system resources. As a result, traditional computers infected with rootkits appear to be healthy, even with antimalware running.
-As previously discussed, the health attestation feature of Windows 10 uses the TPM hardware component to securely record a measurement of every boot-related component, including firmware, Windows 10 kernel, and even early boot drivers. Because, health attestation leverages the hardware-based security capabilities of TPM, the log of all boot measured components remains out of the reach of any malware.
+As previously discussed, the health attestation feature of Windows 10 uses the TPM hardware component to securely record a measurement of every boot-related component, including firmware, Windows 10 kernel, and even early boot drivers. Because health attestation uses the hardware-based security capabilities of TPM, the log of all boot measured components remains out of the reach of any malware.
-By attesting a trusted boot state, devices can prove that they are not running low-level malware that could spoof later compliance checks. TPM-based health attestation provides a reliable anchor of trust for assets that contain high-value data.
+After the devices attest a trusted boot state, they can prove that they aren't running low-level malware that could spoof later compliance checks. TPM-based health attestation provides a reliable anchor of trust for assets that contain high-value data.
### What is the concept of device health?
@@ -359,7 +359,7 @@ However, the use of traditional malware prevention technologies like antimalware
The definition of device compliance will vary based on an organization’s installed antimalware, device configuration settings, patch management baseline, and other security requirements. But health of the device is part of the overall device compliance policy.
-The health of the device isn't binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by leveraging trustworthy hardware TPM.
+The health of the device isn't binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by using trustworthy hardware TPM.
But health attestation only provides information, which is why an MDM solution is needed to take and enforce a decision.
@@ -367,7 +367,7 @@ But health attestation only provides information, which is why an MDM solution i
In Windows 10, health attestation refers to a feature where Measured Boot data generated during the boot process is sent to a remote device health attestation service operated by Microsoft.
-This is the most secure approach available for Windows 10-based devices to detect when security defenses are down. During the boot process, the TCG log and PCRs values are sent to a remote Microsoft cloud service. Logs are then checked by the Health Attestation Service to determine what changes have occurred on the device.
+This approach is the most secure one available for Windows 10-based devices to detect when security defenses are down. During the boot process, the TCG log and PCRs' values are sent to a remote Microsoft cloud service. Logs are then checked by the Health Attestation Service to determine what changes have occurred on the device.
A relying party like an MDM can inspect the report generated by the remote health attestation service.
@@ -378,7 +378,7 @@ Windows 10 supports health attestation scenarios by allowing applications access
Remote device health attestation combined with an MDM provides a hardware-rooted method for reporting the current security status and detecting any changes, without having to trust the software running on the system.
-In the case where malicious code is running on the device, the use of a remote server is required. If a rootkit is present on the device, the antimalware is no longer reliable, and its behavior can be hijacked by a malicious code running early in the startup sequence. That's why it's important to use Secure Boot and Device Guard, to control which code is loaded during the boot sequence.
+In the case where malicious code is running on the device, the use of a remote server is required. If a rootkit is present on the device, the antimalware is no longer reliable, and its behavior can be hijacked by a malicious code running early in the startup sequence. This reason is what makes it important to use Secure Boot and Device Guard, to control which code is loaded during the boot sequence.
The antimalware software can search to determine whether the boot sequence contains any signs of malware, such as a rootkit. It can also send the TCG log and the PCRs to a remote health attestation server to provide a separation between the measurement component and the verification component.
@@ -386,7 +386,7 @@ Health attestation logs the measurements in various TPM Platform Configuration R
:::image type="content" alt-text="figure 6." source="images/hva-fig6-logs.png":::
-When starting a device equipped with TPM, a measurement of different components is performed. This includes firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. The raw measurements are stored in the TPM PCR registers while the details of all events (executable path, authority certification, and so on) are available in the TCG log.
+When you start a device equipped with TPM, a measurement of different components is performed. These components include firmware, UEFI drivers, CPU microcode, and also all the Windows 10 drivers whose type is Boot Start. The raw measurements are stored in the TPM PCR registers while the details of all events (executable path, authority certification, and so on) are available in the TCG log.
:::image type="content" alt-text="figure 7." source="images/hva-fig7-measurement.png":::
@@ -398,7 +398,7 @@ The health attestation process works as follows:
4. Windows kernel is measured.
5. Antivirus software is started as the first kernel mode driver.
6. Boot start drivers are measured.
-7. MDM server through the MDM agent issues a health check command by leveraging the Health Attestation CSP.
+7. MDM server through the MDM agent issues a health check command by using the Health Attestation CSP.
8. Boot measurements are validated by the Health Attestation Service
> [!NOTE]
@@ -432,7 +432,7 @@ In a simplified manner, the TPM is a passive component with limited resources. I
A TPM incorporates in a single component:
-- A RSA 2048-bit key generator
+- An RSA 2048-bit key generator
- A random number generator
- Nonvolatile memory for storing EK, SRK, and AIK keys
- A cryptographic engine to encrypt, decrypt, and sign
@@ -442,7 +442,7 @@ A TPM incorporates in a single component:
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
-The endorsement key public key is generally used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
+The endorsement key public key is used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs.
The endorsement key acts as an identity card for the TPM. For more information, see [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11)).
@@ -467,16 +467,16 @@ Because the endorsement certificate is unique for each device and doesn't change
The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations.
-Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft
+Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it's communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft
Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10-based device.
-Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this isn't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
+Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates aren't issued by Microsoft Cloud CA. These certificates aren't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
-In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that isn't backed by an endorsement certificate.
+In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be used by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that isn't backed by an endorsement certificate.
### Storage root key
-The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048 bits length). The SRK has a major role and is used to protect TPM keys, so that these keys cannot be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
+The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048-bits length). The SRK has a major role and is used to protect TPM keys, so that these keys can't be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### Platform Configuration Registers
@@ -484,19 +484,19 @@ The TPM contains a set of registers that are designed to provide a cryptographic
The measurement of the boot sequence is based on the PCR and TCG log. To establish a static root of trust, when the device is starting, the device must be able to measure the firmware code before execution. In this case, the Core Root of Trust for Measurement (CRTM) is executed from the boot, calculates the hash of the firmware, then stores it by expanding the register PCR\[0\] and transfers execution to the firmware.
-PCRs are set to zero when the platform is booted, and it is the job of the firmware that boots the platform to measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components take the hash of the next component that is to be run and record the measurements in the PCRs. The initial component that starts the measurement chain is implicitly trusted. This is the CRTM. Platform manufacturers are required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative hash of the components that have been measured.
+PCRs are set to zero when the platform is booted, and it's the job of the firmware that boots the platform to measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components take the hash of the next component that is to be run and record the measurements in the PCRs. The initial component that starts the measurement chain is implicitly trusted. This component is the CRTM. Platform manufacturers are required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative hash of the components that have been measured.
-The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log hasn't been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
+The value of a PCR on its own is hard to interpret (it's just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log hasn't been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
### TPM provisioning
-For the TPM of a Windows 10-based device to be usable, it must first be provisioned. The process of provisioning differs somewhat based on TPM versions, but, when successful, it results in the TPM being usable and the owner authorization data (ownerAuth) for the TPM being stored locally on the registry.
+For the TPM of a Windows 10-based device to be usable, it must first be provisioned. The process of provisioning differs based on TPM versions, but, when successful, it results in the TPM being usable and the owner authorization data (ownerAuth) for the TPM being stored locally on the registry.
When the TPM is provisioned, Windows 10 will first attempt to determine the EK and locally stored **ownerAuth** values by looking in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Endorsement**
During the provisioning process, the device may need to be restarted.
-Note that the **Get-TpmEndorsementKeyInfo PowerShell** cmdlet can be used with administrative privilege to get information about the endorsement key and certificates of the TPM.
+The **Get-TpmEndorsementKeyInfo PowerShell** cmdlet can be used with administrative privilege to get information about the endorsement key and certificates of the TPM.
If the TPM ownership isn't known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location:
**HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Admin\\SRKPub**
@@ -510,16 +510,16 @@ As part of the provisioning process, Windows 10 will create an AIK with the TPM.
Windows 10 contains a configuration service provider (CSP) specialized for interacting with the health attestation feature. A CSP is a component that plugs into the Windows MDM client and provides a published protocol for how MDM servers can configure settings and manage Windows-based devices. The management protocol is represented as a tree structure that can be specified as URIs with functions to perform on the URIs such as “get”, “set”, “delete”, and so on.
-The following is a list of functions performed by the Windows 10 Health Attestation CSP:
+The following list is that of the functions performed by the Windows 10 Health Attestation CSP:
- Collects data that is used to verify a device’s health status
- Forwards the data to the Health Attestation Service
- Provisions the Health Attestation Certificate that it receives from the Health Attestation Service
- Upon request, forwards the Health Attestation Certificate (received from the Health Attestation Service) and related runtime information to the MDM server for verification
-During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs values that are measured during the boot, by using a secure communication channel to the Health Attestation Service.
+During a health attestation session, the Health Attestation CSP forwards the TCG logs and PCRs' values that are measured during the boot, by using a secure communication channel to the Health Attestation Service.
-When an MDM server validates that a device has attested to the Health Attestation Service, it will be given a set of statements and claims about how that device booted, with the assurance that the device did not reboot between the time that it attested its health and the time that the MDM server validated it.
+When an MDM server validates that a device has attested to the Health Attestation Service, it will be given a set of statements and claims about how that device booted, with the assurance that the device didn't reboot between the time that it attested its health and the time that the MDM server validated it.
### Windows Health Attestation Service
@@ -530,8 +530,8 @@ The role of Windows Health Attestation Service is essentially to evaluate a set
Checking that a TPM attestation and the associated log are valid takes several steps:
-1. First, the server must check that the reports are signed by **trustworthy AIKs**. This might be done by checking that the public part of the AIK is listed in a database of assets, or perhaps that a certificate has been checked.
-2. After the key has been checked, the signed attestation (a quote structure) should be checked to see whether it is a **valid signature over PCR values**.
+1. First, the server must check that the reports are signed by **trustworthy AIKs**. This verification might be done by checking that the public part of the AIK is listed in a database of assets, or perhaps that a certificate has been checked.
+2. After the key has been checked, the signed attestation (a quote structure) should be checked to see whether it's a **valid signature over PCR values**.
3. Next the logs should be checked to ensure that they match the PCR values reported.
4. Finally, the logs themselves should be examined by an MDM solution to see whether they represent **known or valid security configurations**. For example, a simple check might be to see whether the measured early OS components are known to be good, that the ELAM driver is as expected, and that the ELAM driver policy file is up to date. If all of these checks succeed, an attestation statement can be issued that later can be used to determine whether or not the client should be granted access to a resource.
@@ -554,15 +554,15 @@ The following table presents some key items that can be reported back to MDM dep
|--- |--- |
|Windows 10 for desktop editions|
PCR0 measurementSecure Boot EnabledSecure Boot db matches ExpectedSecure Boot dbx is up to dateSecure Boot policy GUID matches ExpectedBitLocker enabledVirtualization-based security enabledELAM was loadedCode Integrity version is up to dateCode Integrity policy hash matches Expected|
-### Leverage MDM and the Health Attestation Service
+### Use MDM and the Health Attestation Service
To make device health relevant, the MDM solution evaluates the device health report and is configured to the organization’s device health requirements.
-A solution that leverages MDM and the Health Attestation Service consists of three main parts:
+A solution that uses MDM and the Health Attestation Service consists of three main parts:
-1. A device with health attestation enabled. This will usually be done as a part of enrollment with an MDM provider (health attestation will be disabled by default).
-2. After this is enabled, and every boot thereafter, the device will send health measurements to the Health Attestation Service hosted by Microsoft, and it will receive a health attestation blob in return.
-3. At any point after this, an MDM server can request the health attestation blob from the device and ask Health Attestation Service to decrypt the content and validate that it’s been attested.
+1. A device with health attestation enabled. This enablement will be done as a part of enrollment with an MDM provider (health attestation will be disabled by default).
+2. After this service is enabled, and every boot thereafter, the device will send health measurements to the Health Attestation Service hosted by Microsoft, and it will receive a health attestation blob in return.
+3. At any point after this cycle, an MDM server can request the health attestation blob from the device and ask Health Attestation Service to decrypt the content and validate that it’s been attested.
:::image type="content" alt-text="figure 9." source="images/hva-fig8-evaldevicehealth8.png":::
@@ -587,14 +587,14 @@ Interaction between a Windows 10-based device, the Health Attestation Service, a
> [!NOTE]
> The MDM server (relying party) never performs the quote or boot counter validation itself. It gets the quoted data and the health blob (which is encrypted) and sends the data to the Health Attestation Service for validation. This way, the AIK is never visible to the MDM, which thereby addresses privacy concerns.
-Setting the requirements for device compliance is the first step to ensure that registered devices that do not meet health and compliance requirements are detected, tracked, and have actions enforced by the MDM solution.
+Setting the requirements for device compliance is the first step to ensure that registered devices that don't meet health and compliance requirements are detected, tracked, and have actions enforced by the MDM solution.
Devices that attempt to connect to resources must have their health evaluated so that unhealthy and noncompliant devices can be detected and reported. To be fully efficient, an end-to-end security solution must impose a consequence for unhealthy devices like refusing access to high-value assets.
-That is the purpose of conditional access control, which is detailed in the next section.
+That consequence for an unhealthy device is the purpose of conditional access control, which is detailed in the next section.
## Control the security of a Windows 10-based device before access is granted
-Today’s access control technology, in most cases, focuses on ensuring that the right people get access to the right resources. If users can authenticate, they get access to resources using a device that the organization’s IT staff and systems know very little about. Perhaps there is some check such as ensuring that a device is encrypted before giving access to email, but what if the device is infected with malware?
+Today’s access control technology, in most cases, focuses on ensuring that the right people get access to the right resources. If users can authenticate, they get access to resources using a device that the organization’s IT staff and systems know little about. Perhaps there's some check such as ensuring that a device is encrypted before giving access to email, but what if the device is infected with malware?
The remote device health attestation process uses measured boot data to verify the health status of the device. The health of the device is then available for an MDM solution like Intune.
@@ -605,18 +605,18 @@ The figure below shows how the Health Attestation Service is expected to work wi
:::image type="content" alt-text="figure 10." source="images/hva-fig9-intune.png":::
-An MDM solution can then leverage health state statements and take them to the next level by coupling with client policies that will enable conditional access to be granted based on the device’s ability to prove that it’s malware free, its antimalware system is functional and up to date, the
+An MDM solution can then use health state statements and take them to the next level by coupling with client policies that will enable conditional access to be granted based on the device’s ability to prove that it’s malware free, its antimalware system is functional and up to date, the
firewall is running, and the devices patch state is compliant.
Finally, resources can be protected by denying access to endpoints that are unable to prove they’re healthy. This feature is much needed for BYOD devices that need to access organizational resources.
### Built-in support of MDM in Windows 10
-Windows 10 has an MDM client that ships as part of the operating system. This enables MDM servers to manage Windows 10-based devices without requiring a separate agent.
+Windows 10 has an MDM client that ships as part of the operating system. This MDM client enables MDM servers to manage Windows 10-based devices without requiring a separate agent.
### Third-party MDM server support
-Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For additional information, see [Azure Active Directory integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm).
+Third-party MDM servers can manage Windows 10 by using the MDM protocol. The built-in management client is able to communicate with a compatible server that supports the OMA-DM protocol to perform enterprise management tasks. For more information, see [Azure Active Directory integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm).
> [!NOTE]
> MDM servers do not need to create or download a client to manage Windows 10. For more information, see [Mobile device management](/windows/client-management/mdm/).
@@ -625,7 +625,7 @@ The third-party MDM server will have the same consistent first-party user experi
### Management of Windows Defender by third-party MDM
-This management infrastructure makes it possible for IT pros to use MDM-capable products like Intune, to manage health attestation, Device Guard, or Windows Defender on Windows 10-based devices, including BYODs that aren’t domain joined. IT pros will be able to manage and configure all of the actions and settings they are familiar with customizing by using Intune with Intune Endpoint Protection on down-level operating systems. Admins that currently only manage domain joined devices through Group Policy will find it easy to transition to managing Windows 10-based devices by using MDM because many of the settings and actions are shared across both mechanisms.
+This management infrastructure makes it possible for IT pros to use MDM-capable products like Intune, to manage health attestation, Device Guard, or Windows Defender on Windows 10-based devices, including BYODs that aren’t domain joined. IT pros will be able to manage and configure all of the actions and settings they're familiar with customizing by using Intune with Intune Endpoint Protection on down-level operating systems. Admins that currently only manage domain joined devices through Group Policy will find it easy to transition to managing Windows 10-based devices by using MDM because many of the settings and actions are shared across both mechanisms.
For more information on how to manage Windows 10 security and system settings with an MDM solution, see [Custom URI settings for Windows 10 devices](/mem/intune/configuration/custom-settings-windows-10).
@@ -641,10 +641,10 @@ If the device isn't registered, the user will get a message with instructions on
### Office 365 conditional access control
-Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company’s device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include additional
+Azure AD enforces conditional access policies to secure access to Office 365 services. A tenant admin can create a conditional access policy that blocks a user on a non-compliant device from accessing an Office 365 service. The user must conform to the company’s device policies before access can be granted to the service. Alternately, the admin can also create a policy that requires users to just enroll their devices to gain access to an Office 365 service. Policies may be applied to all users of an organization, or limited to a few target groups and enhanced over time to include more
target groups.
-When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that do not have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
+When a user requests access to an Office 365 service from a supported device platform, Azure AD authenticates the user and device from which the user launches the request; and grants access to the service only when the user conforms to the policy set for the service. Users that don't have their device enrolled are given remediation instructions on how to enroll and become compliant to access corporate Office 365 services.
When a user enrolls, the device is registered with Azure AD, and enrolled with a compatible MDM solution like Intune.
@@ -676,9 +676,9 @@ To get to a compliant state, the Windows 10-based device needs to:
### Cloud and on-premises apps conditional access control
-Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's logon to make real-time decisions about which applications they should be allowed to access.
+Conditional access control is a powerful policy evaluation engine built into Azure AD. It gives IT pros an easy way to create access rules beyond Office 365 that evaluate the context of a user's sign in to make real-time decisions about which applications they should be allowed to access.
-IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even on-premises applications. Access rules in Azure AD leverage the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
+IT pros can configure conditional access control policies for cloud SaaS applications secured by Azure AD and even on-premises applications. Access rules in Azure AD use the conditional access engine to check device health and compliance state reported by a compatible MDM solution like Intune in order to determine whether to allow access.
For more information about conditional access, see [Azure Conditional Access Preview for SaaS Apps.](/azure/active-directory/authentication/tutorial-enable-azure-mfa)
@@ -694,14 +694,14 @@ For on-premises applications there are two options to enable conditional access
The following process describes how Azure AD conditional access works:
-1. User has already enrolled with MDM through Workplace Access/Azure AD join which registers device with Azure AD.
+1. User has already enrolled with MDM through Workplace Access/Azure AD join, which registers device with Azure AD.
2. When the device boots or resumes from hibernate, a task “Tpm-HASCertRetr” is triggered to request in background a health attestation blob. Device sends TPM boot measurements to the Health Attestation Service.
3. Health Attestation Service validates device state and issues an encrypted blob to the device based on the health state with details on failed checks (if any).
4. User logs on and the MDM agent contacts the Intune/MDM server.
5. MDM server pushes down new policies if available and queries health blob state and other inventory state.
6. Device sends a health attestation blob previously acquired and also the value of the other state inventory requested by the Intune/MDM server.
7. Intune/MDM server sends the health attestation blob to Health Attestation Service to be validated.
-8. Health Attestation Service validates that the device which sent the health attestation blob is healthy, and returns this result to Intune/MDM server.
+8. Health Attestation Service validates that the device that sent the health attestation blob is healthy, and returns this result to Intune/MDM server.
9. Intune/MDM server evaluates compliance based on the compliance and the queried inventory/health attestation state from device.
10. Intune/MDM server updates compliance state against device object in Azure AD.
11. User opens app, attempts to access a corporate managed asset.
@@ -711,11 +711,11 @@ The following process describes how Azure AD conditional access works:
For more information about Azure AD join, see [Azure AD & Windows 10: Better Together for Work or School](https://go.microsoft.com/fwlink/p/?LinkId=691619), a white paper.
-Conditional access control is a topic that many organizations and IT pros may not know and they should. The different attributes that describe a user, a device, compliance, and context of access are very powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
+Conditional access control is a topic that many organizations and IT pros may not know and they should. The different attributes that describe a user, a device, compliance, and context of access are powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
## Takeaways and summary
-The following list contains high-level key take-aways to improve the security posture of any organization. However, the few take-aways presented in this section should not be interpreted as an exhaustive list of security best practices.
+The following list contains high-level key takeaways to improve the security posture of any organization. However, the few takeaways presented in this section shouldn't be interpreted as an exhaustive list of security best practices.
- **Understand that no solution is 100 percent secure**
@@ -735,7 +735,7 @@ The following list contains high-level key take-aways to improve the security po
- **Sign Device Guard policy**
- Signed Device Guard policy helps protect against a user with administrator privileges trying to defeat the current policy. When a policy is signed, the only way to modify Device Guard subsequently is to provide a new version of the policy signed by the same signer or from a signer specify as part of the Device Guard policy.
+ Signed Device Guard policy helps protect against a user with administrator privileges trying to defeat the current policy. When a policy is signed, the only way to modify Device Guard later is to provide a new version of the policy signed by the same signer or from a signer specify as part of the Device Guard policy.
- **Use virtualization-based security**
@@ -751,11 +751,11 @@ The following list contains high-level key take-aways to improve the security po
- **Use AppLocker when it makes sense**
- Although AppLocker isn't considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user or a group of users.
+ Although AppLocker isn't considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows application for a specific user or a group of users.
- **Lock down firmware and configuration**
- After Windows 10 is installed, lock down firmware boot options access. This prevents a user with physical access from modifying UEFI settings, disabling Secure Boot, or booting other operating systems. Also, in order to protect against an administrator trying to disable Device Guard, add a rule in the current Device Guard policy that will deny and block execution of the **C:\\Windows\\System32\\SecConfig.efi** tool.
+ After Windows 10 is installed, lock down firmware boot options access. This lockdown prevents a user with physical access from modifying UEFI settings, disabling Secure Boot, or booting other operating systems. Also, in order to protect against an administrator trying to disable Device Guard, add a rule in the current Device Guard policy that will deny and block execution of the **C:\\Windows\\System32\\SecConfig.efi** tool.
Health attestation is a key feature of Windows 10 that includes client and cloud components to control access to high-value assets based on a user and their device’s identity and compliance with corporate governance policy. Organizations can choose to detect and report unhealthy devices, or to configure health enforcement rules based on their needs. Health attestation provides an end-to-end security model and integration points, which vendors and software developers can use to build and integrate a customized solution.
diff --git a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
index da17209420..1948922041 100644
--- a/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
+++ b/windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
@@ -30,7 +30,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
-The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by a number of network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
+The **Access this computer from the network** policy setting determines which users can connect to the device from the network. This capability is required by many network protocols, including Server Message Block (SMB)-based protocols, NetBIOS, Common Internet File System (CIFS), and Component Object Model Plus (COM+).
Users, devices, and service accounts gain or lose the **Access this computer from network** user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a built-in security group, or it may be implicitly added by Windows to a computed security group such as Domain Users, Authenticated Users, or Enterprise Domain Controllers.
By default, user accounts and machine accounts are granted the **Access this computer from network** user right when computed groups such as Authenticated Users, and for domain controllers, the Enterprise Domain Controllers group, are defined in the default domain controllers Group Policy Object (GPO).
@@ -47,7 +47,7 @@ Constant: SeNetworkLogonRight
- On desktop devices or member servers, grant this right only to users and administrators.
- On domain controllers, grant this right only to authenticated users, enterprise domain controllers, and administrators.
- On failover clusters, make sure this right is granted to authenticated users.
-- This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you have verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead.
+- This setting includes the **Everyone** group to ensure backward compatibility. Upon Windows upgrade, after you've verified that all users and groups are correctly migrated, you should remove the **Everyone** group and use the **Authenticated Users** group instead.
### Location
@@ -68,13 +68,13 @@ The following table lists the actual and effective default policy values for the
## Policy management
-When modifying this user right, the following actions might cause users and services to experience network access issues:
+When you modify this user right, the following actions might cause users and services to experience network access issues:
- Removing the Enterprise Domain Controllers security group
- Removing the Authenticated Users group or an explicit group that allows users, computers, and service accounts the user right to connect to computers over the network
- Removing all user and machine accounts
-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,20 +95,20 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the **Access this computer from the network** user right is required for users to connect to shared printers and folders. If this user right is assigned to the **Everyone** group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 do not include the **Everyone** group. However, if a device is upgraded and the original device includes the **Everyone** group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device.
+Users who can connect from their device to the network can access resources on target devices for which they have permission. For example, the **Access this computer from the network** user right is required for users to connect to shared printers and folders. If this user right is assigned to the **Everyone** group, anyone in the group can read the files in those shared folders. This situation is unlikely because the groups created by a default installation of at least Windows Server 2008 R2 or Windows 7 don't include the **Everyone** group. However, if a device is upgraded and the original device includes the **Everyone** group as part of its defined users and groups, that group is transitioned as part of the upgrade process and is present on the device.
### Countermeasure
-Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who log on to the domain can access resources that are shared
+Restrict the **Access this computer from the network** user right to only those users and groups who require access to the computer. For example, if you configure this policy setting to the **Administrators** and **Users** groups, users who sign in to the domain can access resources that are shared
from servers in the domain if members of the **Domain Users** group are included in the local **Users** group.
> **Note** If you are using IPsec to help secure network communications in your organization, ensure that a group that includes machine accounts is given this right. This right is required for successful computer authentication. Assigning this right to **Authenticated Users** or **Domain Computers** meets this requirement.
### Potential impact
-If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can log on to the domain or use network resources. If you remove this user right on member servers, users cannot connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to additional accounts that are required by those components. It is important to verify that authorized users are assigned this user right for the devices that they need to access the network.
+If you remove the **Access this computer from the network** user right on domain controllers for all users, no one can sign in to the domain or use network resources. If you remove this user right on member servers, users can't connect to those servers through the network. If you have installed optional components such as ASP.NET or Internet Information Services (IIS), you may need to assign this user right to other accounts that are required by those components. It's important to verify that authorized users are assigned this user right for the devices that they need to access the network.
-If running Windows Server or Azure Stack HCI Failover Clustering, do not remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR is not a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service will not have sufficient rights to function or start properly.
+If running Windows Server or Azure Stack HCI Failover Clustering, don't remove Authenticated Users from the Access this computer from the network policy setting. Doing so may induce an unexpected production outage. This outage is due to the local user account CLIUSR that is used to run the cluster service. CLIUSR isn't a member of the local Administrators group and if the Authenticated Users group is removed, the cluster service won't have sufficient rights to function or start properly.
## Related topics
[User Rights Assignment](user-rights-assignment.md)
diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md b/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md
index 5111f06fe9..3aff3ac62f 100644
--- a/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md
+++ b/windows/security/threat-protection/security-policy-settings/account-lockout-duration.md
@@ -37,7 +37,7 @@ This policy setting is dependent on the **Account lockout threshold** policy set
If [Account lockout threshold](account-lockout-threshold.md) is configured, after the specified number of failed attempts, the account will be locked out. If the **Account lockout duration** is set to 0, the account will remain locked until an administrator unlocks it manually.
-It is advisable to set **Account lockout duration** to approximately 15 minutes. To specify that the account will never be locked out, set the **Account lockout threshold** value to 0.
+It's advisable to set **Account lockout duration** to approximately 15 minutes. To specify that the account will never be locked out, set the **Account lockout threshold** value to 0.
### Location
@@ -58,11 +58,11 @@ The following table lists the actual and effective default policy values. Defaul
## Security considerations
-More than a few unsuccessful password submissions during an attempt to log on to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track logon attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached.
+More than a few unsuccessful password submissions during an attempt to sign in to a computer might represent an attacker's attempts to determine an account password by trial and error. The Windows and Windows Server operating systems can track sign-in attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached.
### Vulnerability
-A denial-of-service (DoS) condition can be created if an attacker abuses the [Account lockout threshold](account-lockout-threshold.md) policy setting and repeatedly attempts to log on with a specific account. After you configure the Account lockout threshold policy setting, the account will be locked out after the specified number of failed attempts. If you configure the **Account lockout duration** policy setting to 0, the account remains locked until you unlock it manually.
+A denial-of-service (DoS) condition can be created if an attacker abuses the [Account lockout threshold](account-lockout-threshold.md) policy setting and repeatedly attempts to sign in with a specific account. After you configure the Account lockout threshold policy setting, the account will be locked out after the specified number of failed attempts. If you configure the **Account lockout duration** policy setting to 0, the account remains locked until you unlock it manually.
### Countermeasure
@@ -70,7 +70,7 @@ Configure the **Account lockout duration** policy setting to an appropriate valu
### Potential impact
-Configuring the **Account lockout duration** policy setting to 0 so that accounts cannot be automatically unlocked can increase the number of requests that your organization's Help Desk receives to unlock accounts that were locked by mistake.
+Configuring the **Account lockout duration** policy setting to 0 so that accounts can't be automatically unlocked can increase the number of requests that your organization's Help Desk receives to unlock accounts that were locked by mistake.
## Related topics
diff --git a/windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10.md b/windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10.md
index f1ca17ad61..1a2434ffeb 100644
--- a/windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10.md
+++ b/windows/security/threat-protection/windows-security-configuration-framework/security-compliance-toolkit-10.md
@@ -54,7 +54,7 @@ The Security Compliance Toolkit consists of:
- GPO to Policy Rules
-You can [download the tools](https://www.microsoft.com/download/details.aspx?id=55319) along with the baselines for the relevant Windows versions. For more details about security baseline recommendations, see the [Microsoft Security Guidance blog](/archive/blogs/secguide/).
+You can [download the tools](https://www.microsoft.com/download/details.aspx?id=55319) along with the baselines for the relevant Windows versions. For more information about security baseline recommendations, see the [Microsoft Security Guidance blog](/archive/blogs/secguide/).
## What is the Policy Analyzer tool?
@@ -64,7 +64,7 @@ The Policy Analyzer is a utility for analyzing and comparing sets of Group Polic
- Compare GPOs against current local policy and local registry settings
- Export results to a Microsoft Excel spreadsheet
-Policy Analyzer lets you treat a set of GPOs as a single unit. This makes it easy to determine whether particular settings are duplicated across the GPOs or are set to conflicting values. Policy Analyzer also lets you capture a baseline and then compare it to a snapshot taken at a later time to identify changes anywhere across the set.
+Policy Analyzer lets you treat a set of GPOs as a single unit. This treatment makes it easy to determine whether particular settings are duplicated across the GPOs or are set to conflicting values. Policy Analyzer also lets you capture a baseline and then compare it to a snapshot taken at a later time to identify changes anywhere across the set.
More information on the Policy Analyzer tool can be found on the [Microsoft Security Guidance blog](/archive/blogs/secguide/new-tool-policy-analyzer) or by [downloading the tool](https://www.microsoft.com/download/details.aspx?id=55319).
@@ -72,7 +72,7 @@ More information on the Policy Analyzer tool can be found on the [Microsoft Secu
LGPO.exe is a command-line utility that is designed to help automate management of Local Group Policy.
Using local policy gives administrators a simple way to verify the effects of Group Policy settings, and is also useful for managing non-domain-joined systems.
-LGPO.exe can import and apply settings from Registry Policy (Registry.pol) files, security templates, Advanced Auditing backup files, as well as from formatted “LGPO text” files.
+LGPO.exe can import and apply settings from Registry Policy (Registry.pol) files, security templates, Advanced Auditing backup files, and from formatted “LGPO text” files.
It can export local policy to a GPO backup.
It can export the contents of a Registry Policy file to the “LGPO text” format that can then be edited, and can build a Registry Policy file from an LGPO text file.
From b58faec4dd9f663a57168b7be26263ec34be6bfc Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Wed, 22 Jun 2022 18:41:54 +0530
Subject: [PATCH 010/299] Acrolinx Enhancement Effort
---
.../account-lockout-threshold.md | 26 +++++++++----------
.../account-policies.md | 2 +-
.../accounts-administrator-account-status.md | 22 ++++++++--------
.../accounts-block-microsoft-accounts.md | 22 ++++++++--------
.../accounts-guest-account-status.md | 10 +++----
...f-blank-passwords-to-console-logon-only.md | 18 ++++++-------
.../accounts-rename-administrator-account.md | 10 +++----
.../accounts-rename-guest-account.md | 6 ++---
.../act-as-part-of-the-operating-system.md | 12 ++++-----
.../add-workstations-to-domain.md | 16 ++++++------
10 files changed, 72 insertions(+), 72 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md
index fdbdef8e1e..7140cd3752 100644
--- a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md
+++ b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md
@@ -27,26 +27,26 @@ Describes the best practices, location, values, and security considerations for
## Reference
-The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
+The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account can't be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md).
Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks.
-However, it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account.
+However, it's important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account.
Failed attempts to unlock a workstation can cause account lockout even if the [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) security option is disabled. Windows doesn’t need to contact a domain controller for an unlock if you enter the same password that you logged on with, but if you enter a different password, Windows has to contact a domain controller in case you had changed your password from another machine.
### Possible values
-It is possible to configure the following values for the **Account lockout threshold** policy setting:
+It's possible to configure the following values for the **Account lockout threshold** policy setting:
- A user-defined number from 0 through 999
- Not defined
-Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this article.
+Because vulnerabilities can exist when this value is configured and when it's not, organizations should weigh their identified threats and the risks that they're trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this article.
### Best practices
The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, [Windows security baselines](../windows-security-baselines.md) recommend a value of 10 could be an acceptable starting point for your organization.
-As with other account lockout settings, this value is more of a guideline than a rule or best practice because there is no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout).
+As with other account lockout settings, this value is more of a guideline than a rule or best practice because there's no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout).
Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this article.
@@ -73,7 +73,7 @@ This section describes features and tools that are available to help you manage
### Restart requirements
-None. Changes to this policy setting become effective without a computer restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy setting become effective without a computer restart when they're saved locally or distributed through Group Policy.
### Implementation considerations
@@ -81,7 +81,7 @@ Implementation of this policy setting depends on your operational environment. C
- The likelihood of an account theft or a DoS attack is based on the security design for your systems and environment. Set the account lockout threshold in consideration of the known and perceived risk of those threats.
-- When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases.
+- When there's a negotiation of encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases.
- Not all apps that are used in your environment effectively manage how many times a user can attempt to sign in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold.
@@ -105,24 +105,24 @@ However, a DoS attack could be performed on a domain that has an account lockout
### Countermeasure
-Because vulnerabilities can exist when this value is configured and when it is not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are:
+Because vulnerabilities can exist when this value is configured and when it's not configured, two distinct countermeasures are defined. Organizations should weigh the choice between the two, based on their identified threats and the risks that they want to mitigate. The two countermeasure options are:
-- Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts will not be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:
+- Configure the **Account lockout threshold** setting to 0. This configuration ensures that accounts won't be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users can't accidentally lock themselves out of their accounts. Because it doesn't prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:
- The password policy setting requires all users to have complex passwords of eight or more characters.
- A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occurs in the environment.
- Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account.
- [Windows security baselines](../windows-security-baselines.md) recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack.
+ [Windows security baselines](../windows-security-baselines.md) recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but doesn't prevent a DoS attack.
- Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems.
+ Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it's needed to help mitigate massive lockouts caused by an attack on your systems.
### Potential impact
-If this policy setting is enabled, a locked account is not usable until it is reset by an administrator or until the account lockout duration expires. Enabling this setting will likely generate a number of additional Help Desk calls.
+If this policy setting is enabled, a locked account isn't usable until it's reset by an administrator or until the account lockout duration expires. Enabling this setting will likely generate many more Help Desk calls.
-If you configure the **Account lockout threshold** policy setting to 0, there is a possibility that a malicious user's attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.
+If you configure the **Account lockout threshold** policy setting to 0, there's a possibility that a malicious user's attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism isn't in place.
If you configure this policy setting to a number greater than 0, an attacker can easily lock any accounts for which the account name is known. This situation is especially dangerous considering that no credentials other than access to the network are necessary to lock the accounts.
diff --git a/windows/security/threat-protection/security-policy-settings/account-policies.md b/windows/security/threat-protection/security-policy-settings/account-policies.md
index d3f03a9e97..6fe7c4fe77 100644
--- a/windows/security/threat-protection/security-policy-settings/account-policies.md
+++ b/windows/security/threat-protection/security-policy-settings/account-policies.md
@@ -29,7 +29,7 @@ All account policies settings applied by using Group Policy are applied at the d
> [!NOTE]
> Each domain can have only one account policy. The account policy must be defined in the default domain policy or in a new policy that is linked to the root of the domain and given precedence over the default domain policy, which is enforced by the domain controllers in the domain. These domain-wide account policy settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain; therefore, domain controllers always retrieve the values of these account policy settings from the default domain policy Group Policy Object (GPO).
-The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users log on to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where neither an OU account policy nor a domain policy applies.
+The only exception is when another account policy is defined for an organizational unit (OU). The account policy settings for the OU affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level account policy, the OU policy will be applied and enforced only when users sign in to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where both an OU account policy and a domain policy don't apply.
## In this section
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md b/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md
index 132ecaa9be..09a0d041d9 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md
@@ -37,7 +37,7 @@ The following conditions prevent disabling the Administrator account, even if th
1. Disabled
2. Listed in the [Deny log on locally](deny-log-on-locally.md) User Rights Assignment
-If the Administrator account is disabled, you cannot enable it if the password does not meet requirements. In this case, another member of the Administrators group must reset the password.
+If the Administrator account is disabled, you can't enable it if the password doesn't meet requirements. In this case, another member of the Administrators group must reset the password.
### Possible values
- Enabled
@@ -48,7 +48,7 @@ By default, this setting is **Not defined** on domain controllers and **Enabled*
### Best practices
-- Disabling the administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there is no other local administrator account, you must restart the computer in safe mode to fix the problem that broke your connection status.
+- Disabling the administrator account can become a maintenance issue under certain circumstances. For example, in a domain environment, if the secure channel that constitutes your connection fails for any reason, and there's no other local administrator account, you must restart the computer in safe mode to fix the problem that broke your connection status.
### Location
@@ -73,16 +73,16 @@ The following table lists the actual and effective default values for this polic
Disabling the administrator account can become a maintenance issue under certain circumstances. Reasons that an organization might consider disabling the built-in administrator account include:
- For some organizations, periodically changing the passwords for local accounts can be a daunting management challenge.
-- By default, the administrator account cannot be locked—no matter how many failed attempts to sign in a user accrues. This makes it a prime target for brute-force, password-guessing attacks.
-- This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID.
+- By default, the administrator account can't be locked—no matter how many failed attempts to sign in a user accrue. This open state of the account makes it a prime target for brute-force, password-guessing attacks.
+- This account has a well-known security identifier (SID). Some non-Microsoft tools allow you to authenticate over the network by specifying the SID rather than the account name. This authentication approach means that even if you rename the administrator account, a malicious user could start a brute-force attack by using the SID.
### 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.
### Safe mode considerations
-When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. In this case, you can access the computer by using safe mode with the current administrative credentials. If the computer is joined to a domain, the disabled administrator account is not enabled.
+When you start a device in safe mode, the disabled administrator account is enabled only if the computer is non-domain joined and there are no other active local administrator accounts. In this case, you can access the computer by using safe mode with the current administrative credentials. If the computer is joined to a domain, the disabled administrator account isn't enabled.
### How to access a disabled Administrator account
@@ -96,17 +96,17 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The built-in administrator account cannot be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum.
+The built-in administrator account can't be locked out no matter how many failed logons it accrues, which makes it a prime target for brute-force attacks that attempt to guess passwords. Also, this account has a well-known security identifier (SID), and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to sign in. All other accounts that are members of the Administrator's group have the safeguard of locking out the account if the number of failed logons exceeds its configured maximum.
### Countermeasure
-Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account cannot be used in a normal system startup.
-If it is very difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack.
+Disable the **Accounts: Administrator account status** setting so that the built-in Administrator account can't be used in a normal system startup.
+If it's difficult to maintain a regular schedule for periodic password changes for local accounts, you can disable the built-in administrator account instead of relying on regular password changes to protect it from attack.
### Potential impact
-Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there is no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail.
-If the current administrator password does not meet the password requirements, you cannot enable the administrator account after it is disabled. If this situation occurs, another member of the administrators group must set the password on the administrator account.
+Maintenance issues can arise under certain circumstances if you disable the administrator account. For example, if the secure channel between a member computer and the domain controller fails in a domain environment for any reason and there's no other local administrator account, you must restart in safe mode to fix the problem that caused the secure channel to fail.
+If the current administrator password doesn't meet the password requirements, you can't enable the administrator account after it's disabled. If this situation occurs, another member of the administrators' group must set the password on the administrator account.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md b/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md
index d390220428..0712c6d50d 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md
@@ -27,27 +27,27 @@ Describes the best practices, location, values, management, and security conside
## Reference
-This setting prevents using the **Settings** app to add a Microsoft account for single sign-on (SSO) authentication for Microsoft services and some background services, or using a Microsoft account for single sign-on to other applications or services. For more details, see [Microsoft Accounts](../../identity-protection/access-control/microsoft-accounts.md).
+This setting prevents using the **Settings** app to add a Microsoft account for single sign-on (SSO) authentication for Microsoft services and some background services, or using a Microsoft account for single sign-on to other applications or services. For more information, see [Microsoft Accounts](../../identity-protection/access-control/microsoft-accounts.md).
There are two options if this setting is enabled:
-- **Users can’t add Microsoft accounts** means that existing connected accounts can still sign in to the device (and appear on the Sign in screen). However, users cannot use the **Settings** app to add new connected accounts (or connect local accounts to Microsoft accounts).
+- **Users can’t add Microsoft accounts** means that existing connected accounts can still sign in to the device (and appear on the sign-in screen). However, users can't use the **Settings** app to add new connected accounts (or connect local accounts to Microsoft accounts).
-- **Users can’t add or log on with Microsoft accounts** means that users cannot add new connected accounts (or connect local accounts to Microsoft accounts) or use existing connected accounts through **Settings**.
+- **Users can’t add or log on with Microsoft accounts** means that users can't add new connected accounts (or connect local accounts to Microsoft accounts) or use existing connected accounts through **Settings**.
-If you disable or do not configure this policy (recommended), users will be able to use Microsoft accounts with Windows.
+If you disable or don't configure this policy (recommended), users will be able to use Microsoft accounts with Windows.
### Possible values
- This policy is disabled
- Users can’t add Microsoft accounts
-- Users can’t add or log on with Microsoft accounts
+- Users can’t add or sign in with Microsoft accounts
-By default, this setting is not defined on domain controllers and disabled on stand-alone servers.
+By default, this setting isn't defined on domain controllers and disabled on stand-alone servers.
### Best practices
-- By disabling or not configuring this policy setting on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This provides a convenient option for your users.
-- If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users will not be able to use the **Settings** app to add new connected accounts.
+- If this policy setting is disabled or isn't configured on the client computer, users will be able to use their Microsoft account, local account, or domain account for their sign-in session to Windows. It also enables the user to connect a local or domain account to a Microsoft account. This ability to connect provides a convenient option for your users.
+- If you need to limit the use of Microsoft accounts in your organization, click the **Users can’t add Microsoft accounts** setting option so that users won't be able to use the **Settings** app to add new connected accounts.
### Location
@@ -72,7 +72,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
@@ -80,11 +80,11 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of the enterprise. Additionally, if the owner of a Microsoft account is not easily distinguishable, auditing and forensics become more difficult.
+Although Microsoft accounts are password-protected, they also have the potential of greater exposure outside of the enterprise. Additionally, if the owner of a Microsoft account isn't easily distinguishable, auditing and forensics become more difficult.
### Countermeasure
-Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the **Users can’t add Microsoft accounts** setting option so that users will not be able to create new Microsoft accounts on a device, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
+Require only domain accounts in your enterprise by limiting the use of Microsoft accounts. Click the **Users can’t add Microsoft accounts** setting option so that users won't be able to create new Microsoft accounts on a device, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md b/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md
index 6f785de269..a08a78b36e 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md
@@ -28,7 +28,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
The **Accounts: Guest account status** policy setting determines whether the Guest account is enabled or disabled.
-This account allows unauthenticated network users to gain access to the system by logging on as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This can lead to the exposure or corruption of data.
+This account allows unauthenticated network users to gain access to the system by signing in as a Guest with no password. Unauthorized users can access any resources that are accessible to the Guest account over the network. This privilege means that any network shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group will be accessible over the network. This accessibility can lead to the exposure or corruption of data.
### Possible values
@@ -38,7 +38,7 @@ This account allows unauthenticated network users to gain access to the system b
### Best practices
-Set **Accounts: Guest account status** to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md) is set to **Guest only**, network logons—such as those performed by the SMB Service—will fail.
+Set **Accounts: Guest account status** to Disabled so that the built-in Guest account is no longer usable. All network users will have to authenticate before they can access shared resources on the system. If the Guest account is disabled and [Network access: Sharing and security model for local accounts](network-access-sharing-and-security-model-for-local-accounts.md) is set to **Guest only**, network logons—such as those logons performed by the SMB Service—will fail.
### Location
@@ -63,15 +63,15 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The default Guest account allows unauthenticated network users to log on as a Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data.
+The default Guest account allows unauthenticated network users to sign in as a Guest with no password. These unauthorized users could access any resources that are accessible to the Guest account over the network. This capability means that any shared folders with permissions that allow access to the Guest account, the Guests group, or the Everyone group are accessible over the network, which could lead to the exposure or corruption of data.
### Countermeasure
-Disable the **Accounts: Guest account status** setting so that the built-in Guest account cannot be used.
+Disable the **Accounts: Guest account status** setting so that the built-in Guest account can't be used.
### Potential impact
-All network users must be authenticated before they can access shared resources. If you disable the Guest account and the **Network Access: Sharing and Security Model** option is set to **Guest Only**, network logons, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it is the default setting starting with Windows Vista and Windows Server 2003.
+All network users must be authenticated before they can access shared resources. If you disable the Guest account and the **Network Access: Sharing and Security Model** option is set to **Guest Only**, network logons, such as those performed by the Microsoft Network Server (SMB Service), fail. This policy setting should have little impact on most organizations because it's the default setting starting with Windows Vista and Windows Server 2003.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md b/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
index b630cc0ce5..cde8f45d22 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
@@ -29,12 +29,12 @@ Describes the best practices, location, values, and security considerations for
The **Accounts: Limit local account use of blank passwords to console logon only** policy setting determines whether remote interactive logons by network services such as Remote Desktop Services, Telnet, and File Transfer Protocol (FTP) are allowed for local accounts that have blank passwords. If this policy setting is enabled, a local account must have a nonblank password to be used to perform an interactive or network logon from a remote client.
-This policy setting does not affect interactive logons that are performed physically at the console or logons that use domain accounts. It is possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.
-Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to log on to systems.
+This policy setting doesn't affect interactive logons that are performed physically at the console or logons that use domain accounts. It's possible for non-Microsoft applications that use remote interactive logons to bypass this policy setting.
+Blank passwords are a serious threat to computer security and they should be forbidden through both corporate policy and suitable technical measures. Nevertheless, if a user with the ability to create new accounts creates one that has bypassed your domain-based password policy settings, that account might have a blank password. For example, a user could build a stand-alone system, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the account name can then use accounts with blank passwords to sign in to systems.
-Devices that are not in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can log on by using a user account that does not have a password. This is especially important for portable devices.
+Devices that aren't in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the device can sign in by using a user account that doesn't have a password. This policy is especially important for portable devices.
-If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop Services.
+If you apply this security policy to the Everyone group, no one will be able to sign in through Remote Desktop Services.
### Possible values
@@ -44,7 +44,7 @@ If you apply this security policy to the Everyone group, no one will be able to
### Best practices
-- It is advisable to set **Accounts: Limit local account use of blank passwords to console logon only** to Enabled.
+- It's advisable to set **Accounts: Limit local account use of blank passwords to console logon only** to Enabled.
### 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.
### Policy conflict considerations
@@ -77,7 +77,7 @@ The policy as distributed through the GPO takes precedence over the locally conf
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
@@ -85,7 +85,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Blank passwords are a serious threat to computer security, and they should be forbidden through organizational policy and suitable technical measures. Starting with Windows Server 2003, the default settings for Active Directory domains require complex passwords of at least seven characters, and eight characters starting with Windows Server 2008. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to log on.
+Blank passwords are a serious threat to computer security, and they should be forbidden through organizational policy and suitable technical measures. From Windows Server 2003, the default settings for Active Directory domains require complex passwords of at least seven characters, and eight characters starting with Windows Server 2008. However, if users with the ability to create new accounts bypass your domain-based password policies, they could create accounts with blank passwords. For example, a user could build a stand-alone computer, create one or more accounts with blank passwords, and then join the computer to the domain. The local accounts with blank passwords would still function. Anyone who knows the name of one of these unprotected accounts could then use it to sign in.
### Countermeasure
@@ -93,7 +93,7 @@ Enable the **Accounts: Limit local account use of blank passwords to console log
### Potential impact
-None. This is the default configuration.
+None. This non-impact behavior is the default configuration.
## Related topics
[Security Options](security-options.md)
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md b/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
index d865644cf8..4c849e7de5 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
@@ -62,7 +62,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.
### Policy conflict considerations
@@ -70,7 +70,7 @@ None.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
@@ -78,9 +78,9 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer so this countermeasure is applied by default on new installations. If a device is upgraded from a previous version of Windows, the account with the name administrator is retained with all the rights and privileges that were defined for the account in the previous installation.
+The Administrator account exists on all versions Windows 10 for desktop editions. If you rename this account, it's slightly more difficult for unauthorized persons to guess this privileged user name and password combination. Beginning with Windows Vista, the person who installs the operating system specifies an account that is the first member of the Administrator group and has full rights to configure the computer so this countermeasure is applied by default on new installations. If a device is upgraded from a previous version of Windows, the account with the name administrator is retained with all the rights and privileges that were defined for the account in the previous installation.
-The built-in administrator account cannot be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to log on.
+The built-in administrator account can't be locked out, regardless of how many times an attacker might use a bad password. This capability makes the administrator account a popular target for brute-force attacks that attempt to guess passwords. The value of this countermeasure is lessened because this account has a well-known SID, and there are non-Microsoft tools that allow authentication by using the SID rather than the account name. Therefore, even if you rename the Administrator account, an attacker could launch a brute-force attack by using the SID to sign in.
### Countermeasure
@@ -88,7 +88,7 @@ Specify a new name in the **Accounts: Rename administrator account** setting to
### Potential impact
-You must provide users who are authorized to use this account with the new account name. (The guidance for this setting assumes that the Administrator account was not disabled.)
+You must provide users who are authorized to use this account with the new account name. (The guidance for this setting assumes that the Administrator account wasn't disabled.)
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md b/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md
index 7ce4a682bc..1162ff5210 100644
--- a/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md
+++ b/windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md
@@ -62,7 +62,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.
### Policy conflict considerations
@@ -70,7 +70,7 @@ None.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local device by using the Local Security Policy snap-in.
## Security considerations
@@ -83,7 +83,7 @@ or install software that could be used for a later attack on your system.
### Countermeasure
-Specify a new name in the **Accounts: Rename guest account** setting to rename the Guest account. If you rename this account, it is slightly more difficult for unauthorized persons to guess this privileged user name and password combination.
+Specify a new name in the **Accounts: Rename guest account** setting to rename the Guest account. If you rename this account, it's slightly more difficult for unauthorized persons to guess this privileged user name and password combination.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md
index 4c794419c1..5850036933 100644
--- a/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md
+++ b/windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
-The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access is not limited to what is associated with the user by default. The calling process may request that arbitrary additional privileges be added to the access token. The calling process may also build an access token that does not provide a primary identity for auditing in the system event logs.
+The **Act as part of the operating system** policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low-level authentication services require this user right. Potential access isn't limited to what is associated with the user by default. The calling process may request that arbitrary extra privileges be added to the access token. The calling process may also build an access token that doesn't provide a primary identity for auditing in the system event logs.
Constant: SeTcbPrivilege
### Possible values
@@ -35,8 +35,8 @@ Constant: SeTcbPrivilege
- Not defined
### Best practices
-- Do not assign this right to any user accounts. Only assign this user right to trusted users.
-- If a service requires this user right, configure the service to log on by using the local System account, which inherently includes this user right. Do not create a separate account and assign this user right to it.
+- Don't assign this right to any user accounts. Only assign this user right to trusted users.
+- If a service requires this user right, configure the service to sign in by using the local System account, which inherently includes this user right. Don't create a separate account and assign this user right to it.
### Location
@@ -57,7 +57,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.
@@ -77,11 +77,11 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The **Act as part of the operating system** user right is extremely powerful. Users with this user right can take complete control of the device and erase evidence of their activities.
+The **Act as part of the operating system** user right is powerful. Users with this user right can take complete control of the device and erase evidence of their activities.
### Countermeasure
-Restrict the **Act as part of the operating system** user right to as few accounts as possible—it should not even be assigned to the Administrators group under typical circumstances. When a service requires this user right, configure the service to log on with the Local System account, which inherently includes this privilege. Do not create a separate account and assign this user right to it.
+Restrict the **Act as part of the operating system** user right to as few accounts as possible—it shouldn't even be assigned to the Administrators group under typical circumstances. When a service requires this user right, configure the service to sign in with the Local System account, which inherently includes this privilege. Don't create a separate account and assign this user right to it.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md b/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md
index 8e6a02b8ef..471d8a40ba 100644
--- a/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md
+++ b/windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management and security c
## Reference
-This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to ten workstations to the domain.
+This policy setting determines which users can add a device to a specific domain. For it to take effect, it must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to 10 workstations to the domain.
Adding a machine account to the domain allows the device to participate in Active Directory-based networking.
Constant: SeMachineAccountPrivilege
@@ -47,7 +47,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\User Rights Assignm
### Default values
-By default, this setting allows access for Authenticated Users on domain controllers, and it is not defined on stand-alone servers.
+By default, this setting allows access for Authenticated Users on domain controllers, and it isn't defined on stand-alone servers.
The following table lists the actual and effective default policy values for the most recent supported versions of Windows. Default values are also listed on the policy’s property page.
@@ -62,11 +62,11 @@ The following table lists the actual and effective default policy values for the
## Policy management
-Users can also join a computer to a domain if they have the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of devices to the domain regardless of whether they have the **Add workstations to domain** user right.
+Users can also join a computer to a domain if they've the Create Computer Objects permission for an organizational unit (OU) or for the Computers container in the directory. Users who are assigned this permission can add an unlimited number of devices to the domain regardless of whether they've the **Add workstations to domain** user right.
-Furthermore, machine accounts that are created by means of the **Add workstations to domain** user right have Domain Administrators as the owner of the machine account. Machine accounts that are created by means of permissions on the computer’s container use the creator as the owner of the machine account. If a user has permissions on the container and also has the **Add workstation to domain** user right, the device is added based on the computer container permissions rather than the user right.
+Furthermore, machine accounts that are created through the **Add workstations to domain** user right have Domain Administrators as the owner of the machine account. Machine accounts that are created through permissions on the computer’s container use the creator as the owner of the machine account. If a user has permissions on the container and also has the **Add workstation to domain** user right, the device is added based on the computer container permissions rather than the user right.
-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.
@@ -87,8 +87,8 @@ This policy has the following security considerations:
### Vulnerability
-The **Add workstations to domain** user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization does not want its users to have administrative
-privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could log on with that account, and then add a personal domain account to the local Administrators group.
+The **Add workstations to domain** user right presents a moderate vulnerability. Users with this right could add a device to the domain that is configured in a way that violates organizational security policies. For example, if your organization doesn't want its users to have administrative
+privileges on their devices, users could install Windows on their computers and then add the computers to the domain. The user would know the password for the local administrator account, could sign in with that account, and then add a personal domain account to the local Administrators group.
### Countermeasure
@@ -96,7 +96,7 @@ Configure this setting so that only authorized members of the IT team are allowe
### Potential impact
-For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those that have allowed some or all users to configure their own devices, this countermeasure forces the organization to establish a formal process for these procedures going forward. It does not affect existing computers unless they are removed from and then added to the domain.
+For organizations that have never allowed users to set up their own computers and add them to the domain, this countermeasure has no impact. For those organizations that have allowed some or all users to configure their own devices, this countermeasure forces the organization to establish a formal process for these procedures going forward. It doesn't affect existing computers unless they're removed from and then added to the domain.
## Related topics
- [User Rights Assignment](user-rights-assignment.md)
From d7e7827aeecb3c94faa309055ce61f61f73b36a9 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Thu, 23 Jun 2022 12:23:39 +0530
Subject: [PATCH 011/299] Acrolinx Enhancement Effort
---
.../administer-security-policy-settings.md | 73 +++++++++----------
...-log-on-through-remote-desktop-services.md | 20 ++---
...the-use-of-backup-and-restore-privilege.md | 4 +-
...policy-subcategory-settings-to-override.md | 8 +-
...iately-if-unable-to-log-security-audits.md | 12 +--
.../bypass-traverse-checking.md | 12 +--
.../change-the-system-time.md | 10 +--
.../create-a-pagefile.md | 6 +-
.../create-a-token-object.md | 12 +--
.../create-global-objects.md | 10 +--
.../create-symbolic-links.md | 10 +--
...criptor-definition-language-sddl-syntax.md | 18 ++---
...criptor-definition-language-sddl-syntax.md | 18 ++---
...ccess-to-this-computer-from-the-network.md | 10 +--
.../deny-log-on-as-a-batch-job.md | 3 +-
15 files changed, 112 insertions(+), 114 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md b/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md
index 297de36841..f60583b08c 100644
--- a/windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md
+++ b/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.
## 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
### 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.
### 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.
### 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.
### 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
### 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.
### 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.
### 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.
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.
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.
### 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.
### Automating security configuration tasks
diff --git a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md
index 1ad9f2883f..6a4eff29c5 100644
--- a/windows/security/threat-protection/security-policy-settings/allow-log-on-through-remote-desktop-services.md
+++ b/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.
+title: Allow a sign in through Remote Desktop Services (Windows 10)
+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
@@ -18,7 +18,7 @@ ms.date: 04/19/2017
ms.technology: windows-sec
---
-# Allow log on through Remote Desktop Services
+# Allow sign in through Remote Desktop Services
**Applies to**
- Windows 10
@@ -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
diff --git a/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md b/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md
index 39535992d7..6b5311ba25 100644
--- a/windows/security/threat-protection/security-policy-settings/audit-audit-the-use-of-backup-and-restore-privilege.md
+++ b/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.
diff --git a/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md b/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md
index cc93c278b5..d4f0fd8113 100644
--- a/windows/security/threat-protection/security-policy-settings/audit-force-audit-policy-subcategory-settings-to-override.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md b/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
index 7cc7a09a81..867e169424 100644
--- a/windows/security/threat-protection/security-policy-settings/audit-shut-down-system-immediately-if-unable-to-log-security-audits.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md b/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md
index 239a32f7b1..f41f877de5 100644
--- a/windows/security/threat-protection/security-policy-settings/bypass-traverse-checking.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md b/windows/security/threat-protection/security-policy-settings/change-the-system-time.md
index c3d5940ecc..bd9df622f1 100644
--- a/windows/security/threat-protection/security-policy-settings/change-the-system-time.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md b/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md
index c5a8a0a8e1..a5669229ef 100644
--- a/windows/security/threat-protection/security-policy-settings/create-a-pagefile.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md b/windows/security/threat-protection/security-policy-settings/create-a-token-object.md
index b506e0c131..718a99a7bd 100644
--- a/windows/security/threat-protection/security-policy-settings/create-a-token-object.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/create-global-objects.md b/windows/security/threat-protection/security-policy-settings/create-global-objects.md
index fd0acee762..b4f0048aa0 100644
--- a/windows/security/threat-protection/security-policy-settings/create-global-objects.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md b/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md
index d5d9820efd..3302b6c613 100644
--- a/windows/security/threat-protection/security-policy-settings/create-symbolic-links.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
index cfed5fd439..22eda320a1 100644
--- a/windows/security/threat-protection/security-policy-settings/dcom-machine-access-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md b/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
index 7142b1773f..e5bb3b3aec 100644
--- a/windows/security/threat-protection/security-policy-settings/dcom-machine-launch-restrictions-in-security-descriptor-definition-language-sddl-syntax.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md b/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md
index 269c9d78ab..4b02ab14cd 100644
--- a/windows/security/threat-protection/security-policy-settings/deny-access-to-this-computer-from-the-network.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md
index 3065d91365..a1f85a8494 100644
--- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-batch-job.md
+++ b/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
From 7039123165ba6db3a91c8a22db876506d36144f1 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Fri, 24 Jun 2022 16:38:59 +0530
Subject: [PATCH 012/299] Acrolinx Enhancement Effort
---
.../deny-log-on-as-a-service.md | 4 ++--
.../deny-log-on-locally.md | 10 ++++-----
...-log-on-through-remote-desktop-services.md | 12 +++++-----
...s-allow-undock-without-having-to-log-on.md | 16 +++++++-------
...wed-to-format-and-eject-removable-media.md | 4 ++--
...t-users-from-installing-printer-drivers.md | 8 +++----
...m-access-to-locally-logged-on-user-only.md | 10 ++++-----
...y-access-to-locally-logged-on-user-only.md | 10 ++++-----
...llow-server-operators-to-schedule-tasks.md | 10 ++++-----
...roller-ldap-server-signing-requirements.md | 14 ++++++------
...refuse-machine-account-password-changes.md | 10 ++++-----
...rypt-or-sign-secure-channel-data-always.md | 21 +++++++++---------
...crypt-secure-channel-data-when-possible.md | 22 +++++++++----------
...-sign-secure-channel-data-when-possible.md | 22 +++++++++----------
...isable-machine-account-password-changes.md | 14 ++++++------
15 files changed, 93 insertions(+), 94 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md
index 3b48755935..6085f264bd 100644
--- a/windows/security/threat-protection/security-policy-settings/deny-log-on-as-a-service.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md
index e3663ffda4..7363da3bbc 100644
--- a/windows/security/threat-protection/security-policy-settings/deny-log-on-locally.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md b/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md
index ea9ba0f63a..288922a996 100644
--- a/windows/security/threat-protection/security-policy-settings/deny-log-on-through-remote-desktop-services.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md b/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md
index 6f6a4ddb5f..fd60b876a5 100644
--- a/windows/security/threat-protection/security-policy-settings/devices-allow-undock-without-having-to-log-on.md
+++ b/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.
+title: Devices Allow undock without having to sign in (Windows 10)
+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
@@ -18,7 +18,7 @@ ms.date: 04/19/2017
ms.technology: windows-sec
---
-# Devices: Allow undock without having to log on
+# Devices: Allow undock without having to sign in
**Applies to**
- Windows 10
@@ -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
@@ -81,7 +81,7 @@ If this policy setting is enabled, anyone with physical access to portable compu
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
diff --git a/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md b/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md
index fccacdc413..3acbde1af2 100644
--- a/windows/security/threat-protection/security-policy-settings/devices-allowed-to-format-and-eject-removable-media.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md b/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md
index 5b2bfdf5aa..baf3de195a 100644
--- a/windows/security/threat-protection/security-policy-settings/devices-prevent-users-from-installing-printer-drivers.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md b/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
index 1bc52f9b73..18e750e462 100644
--- a/windows/security/threat-protection/security-policy-settings/devices-restrict-cd-rom-access-to-locally-logged-on-user-only.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md b/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
index 2591b45b42..cd1c68ffef 100644
--- a/windows/security/threat-protection/security-policy-settings/devices-restrict-floppy-access-to-locally-logged-on-user-only.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md b/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md
index ad7e4030e3..27a5767000 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md
+++ b/windows/security/threat-protection/security-policy-settings/domain-controller-allow-server-operators-to-schedule-tasks.md
@@ -27,13 +27,13 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This policy setting determines whether server operators can use the**at** command to submit jobs. If you enable this policy setting, jobs that are created by server operators by means of the **at** command run in the context of the account that runs the Task Scheduler service. By default, that is the Local System account.
+This policy setting determines whether server operators can use the**at** command to submit jobs. If you enable this policy setting, jobs that are created by server operators through the **at** command run in the context of the account that runs the Task Scheduler service. By default, that is the Local System account.
>**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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md
index 3c4bd32092..d9e51b120c 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-controller-ldap-server-signing-requirements.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md b/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md
index d0b2f91db5..4b6f851944 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-controller-refuse-machine-account-password-changes.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
index c48680bf77..f5fe43b200 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-or-sign-secure-channel-data-always.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
index f07984917f..920aba71a4 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-encrypt-secure-channel-data-when-possible.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md b/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md
index b75a8767d9..2083e899a8 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-digitally-sign-secure-channel-data-when-possible.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md b/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md
index 8c85b1ecee..6127a9b87f 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-disable-machine-account-password-changes.md
+++ b/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
From 1be5f7b0e96e9d0111ed8afe7ab8ecbc41eb07a8 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Fri, 24 Jun 2022 18:11:03 +0530
Subject: [PATCH 013/299] Acrolinx Enhancement Effort
---
...er-maximum-machine-account-password-age.md | 8 ++---
...trong-windows-2000-or-later-session-key.md | 12 +++----
...r-accounts-to-be-trusted-for-delegation.md | 8 ++---
.../enforce-password-history.md | 14 ++++----
.../enforce-user-logon-restrictions.md | 8 ++---
.../increase-a-process-working-set.md | 4 +--
...-information-when-the-session-is-locked.md | 36 +++++++++----------
...ive-logon-do-not-display-last-user-name.md | 18 +++++-----
...ctive-logon-do-not-require-ctrl-alt-del.md | 20 +++++------
...-logon-dont-display-username-at-sign-in.md | 10 +++---
...logon-machine-account-lockout-threshold.md | 12 +++----
...eractive-logon-machine-inactivity-limit.md | 2 +-
...age-text-for-users-attempting-to-log-on.md | 20 +++++------
...ge-title-for-users-attempting-to-log-on.md | 14 ++++----
...case-domain-controller-is-not-available.md | 30 ++++++++--------
...er-authentication-to-unlock-workstation.md | 16 ++++-----
.../kerberos-policy.md | 2 +-
.../load-and-unload-device-drivers.md | 12 +++----
.../lock-pages-in-memory.md | 6 ++--
.../log-on-as-a-batch-job.md | 4 +--
.../manage-auditing-and-security-log.md | 9 +++--
.../maximum-lifetime-for-service-ticket.md | 14 ++++----
...aximum-lifetime-for-user-ticket-renewal.md | 8 ++---
.../maximum-lifetime-for-user-ticket.md | 8 ++---
.../maximum-password-age.md | 10 +++---
25 files changed, 152 insertions(+), 153 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md b/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md
index 7a5f2b3e94..7eb431cb17 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md
+++ b/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age.md
@@ -43,7 +43,7 @@ For more information, see [Machine Account Password Process](https://techcommuni
### Best practices
-We recommend that you set **Domain member: Maximum machine account password age** to about 30 days. Setting the value to fewer days can increase replication and affect domain controllers. For example, in Windows NT domains, machine passwords were changed every 7 days. The additional replication churn would affect domain controllers in large organizations that have many computers or slow links between sites.
+We recommend that you set **Domain member: Maximum machine account password age** to about 30 days. Setting the value to fewer days can increase replication and affect domain controllers. For example, in Windows NT domains, machine passwords were changed every 7 days. The extra replication churn would affect domain controllers in large organizations that have many computers or slow links between sites.
### Location
@@ -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 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
@@ -76,7 +76,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-By default, the domain members submit a password change every 30 days. If you increase this interval significantly so that the computers no longer submit a password change, an attacker has more time to undertake a brute-force attack to guess the password of one or more computer accounts.
+By default, the domain members submit a password change every 30 days. If you increase this interval so that the computers no longer submit a password change, an attacker has more time to undertake a brute-force attack to guess the password of one or more computer accounts.
### Countermeasure
@@ -84,7 +84,7 @@ Configure the **Domain member: Maximum machine account password age** setting to
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
- [Security Options](security-options.md)
diff --git a/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md b/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md
index 24cdd01bd2..1d7f2049d2 100644
--- a/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md
+++ b/windows/security/threat-protection/security-policy-settings/domain-member-require-strong-windows-2000-or-later-session-key.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
-The **Domain member: Require strong (Windows 2000 or later) session key** policy setting determines whether a secure channel can be established with a domain controller that is not capable of encrypting secure channel traffic with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any domain controller that cannot encrypt secure channel data with a strong key. Disabling this policy setting allows 64-bit session keys.
+The **Domain member: Require strong (Windows 2000 or later) session key** policy setting determines whether a secure channel can be established with a domain controller that isn't capable of encrypting secure channel traffic with a strong, 128-bit session key. Enabling this policy setting prevents establishing a secure channel with any domain controller that can't encrypt secure channel data with a strong key. Disabling this policy setting allows 64-bit session keys.
Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and session-hijacking network attacks. Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the name of the sender, or it can be redirected.
@@ -35,7 +35,7 @@ Whenever possible, you should take advantage of these stronger session keys to h
- Enabled
- When enabled on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This means that all such domain controllers must be running at least Windows 2000 Server.
+ When enabled on a member workstation or server, all domain controllers in the domain that the member belongs to must be capable of encrypting secure channel data with a strong, 128-bit key. This capability means that all such domain controllers must be running at least Windows 2000 Server.
- Disabled
@@ -45,7 +45,7 @@ Whenever possible, you should take advantage of these stronger session keys to h
### Best practices
-- It is advisable to set **Domain member: Require strong (Windows 2000 or later) session key** to Enabled. Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong encryption key. Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain controllers in all trusted domains support strong keys. By default, this value is disabled.
+- It's advisable to set **Domain member: Require strong (Windows 2000 or later) session key** to Enabled. Enabling this policy setting ensures that all outgoing secure channel traffic will require a strong encryption key. Disabling this policy setting requires that key strength be negotiated. Only enable this option if the domain controllers in all trusted domains support strong keys. By default, this value is disabled.
### Location
@@ -73,13 +73,13 @@ 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
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
-You will you be able to join devices that do not support this policy setting to domains where the domain controllers have this policy setting enabled.
+You'll you be able to join devices that don't support this policy setting to domains where the domain controllers have this policy setting enabled.
## Security considerations
@@ -99,7 +99,7 @@ If you enable this policy setting, all outgoing secure channel traffic requires
### Potential impact
-Devices that do not support this policy setting cannot join domains in which the domain controllers have this policy setting enabled.
+Devices that don't support this policy setting can't join domains in which the domain controllers have this policy setting enabled.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md b/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
index d60d7b9568..464033d694 100644
--- a/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
+++ b/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation.md
@@ -28,7 +28,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
This policy setting determines which users can set the **Trusted for Delegation** setting on a user or computer object.
-Security account delegation provides the ability to connect to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation.
+Security account delegation enables connection to multiple servers, and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public-facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation.
Only administrators who have the **Enable computer and user accounts to be trusted for delegation** credential can set up delegation. Domain admins and Enterprise admins have this credential. The procedure to allow a user to be trusted for delegation depends on the functionality level of the domain.
@@ -43,7 +43,7 @@ Constant: SeEnableDelegationPrivilege
### Best practices
-- There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone devices.
+- There's no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It's only relevant on domain controllers and stand-alone devices.
### Location
@@ -68,7 +68,7 @@ This section describes features, tools and guidance to help you manage this poli
Modifying this setting might affect compatibility with clients, services, and applications.
-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.
@@ -99,7 +99,7 @@ after a security incident.
### Countermeasure
-The **Enable computer and user accounts to be trusted for delegation** user right should be assigned only if there is a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default.
+The **Enable computer and user accounts to be trusted for delegation** user right should be assigned only if there's a clear need for its functionality. When you assign this right, you should investigate the use of constrained delegation to control what the delegated accounts can do. On domain controllers, this right is assigned to the Administrators group by default.
>**Note:** There is no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It is only relevant on domain controllers and stand-alone computers.
diff --git a/windows/security/threat-protection/security-policy-settings/enforce-password-history.md b/windows/security/threat-protection/security-policy-settings/enforce-password-history.md
index e32f558d6c..97d3791815 100644
--- a/windows/security/threat-protection/security-policy-settings/enforce-password-history.md
+++ b/windows/security/threat-protection/security-policy-settings/enforce-password-history.md
@@ -30,7 +30,7 @@ Describes the best practices, location, values, policy management, and security
The **Enforce password history** policy setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused.
Password reuse is an important concern in any organization. Many users want to reuse the same password for their account over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but they can reuse an old password, the effectiveness of a good password policy is greatly reduced.
-Specifying a low number for **Enforce password history** allows users to continually use the same small number of passwords repeatedly. If you do not also set [Minimum password age](minimum-password-age.md), users can change their password as many times in a row as necessary to reuse their original password.
+Specifying a low number for **Enforce password history** allows users to continually use the same small number of passwords repeatedly. If you don't also set [Minimum password age](minimum-password-age.md), users can change their password as many times in a row as necessary to reuse their original password.
### Possible values
@@ -39,9 +39,9 @@ Specifying a low number for **Enforce password history** allows users to continu
### Best practices
-- Set **Enforce password history** to 24. This will help mitigate vulnerabilities that are caused by password reuse.
+- Set **Enforce password history** to 24. This setting will help mitigate vulnerabilities that are caused by password reuse.
- Set [Maximum password age](maximum-password-age.md) to expire passwords between 60 and 90 days. Try to expire the passwords between major business cycles to prevent work loss.
-- Configure [Minimum password age](minimum-password-age.md) so that you do not allow passwords to be changed immediately.
+- Configure [Minimum password age](minimum-password-age.md) so that you don't allow passwords to be changed immediately.
### Location
@@ -66,7 +66,7 @@ This section describes features, tools, and guidance to help you manage this pol
### 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,9 +74,9 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
+The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse isn't prevented, or if users continually reuse a few passwords, the effectiveness of a good password policy is greatly reduced.
-If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If you do not also configure the [Minimum password age](minimum-password-age.md) policy setting, users might repeatedly change their passwords until they can reuse their original password.
+If you specify a low number for this policy setting, users can use the same small number of passwords repeatedly. If you don't also configure the [Minimum password age](minimum-password-age.md) policy setting, users might repeatedly change their passwords until they can reuse their original password.
>**Note:** After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised.
@@ -88,7 +88,7 @@ For this policy setting to be effective, you should also configure effective val
### Potential impact
-The major impact of configuring the **Enforce password history** setting to 24 is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization, but this makes them easier for an attacker to guess. Also, an excessively low value for the [Maximum password age](maximum-password-age.md) policy setting is likely to increase administrative overhead because users who forget their passwords might ask the Help Desk to reset them frequently.
+The major impact of configuring the **Enforce password history** setting to 24 is that users must create a new password every time they're required to change their old one. If users are required to change their passwords to new unique values, there's an increased risk of users who write their passwords somewhere so that they don't forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization, but these passwords make it easier for an attacker to guess. Also, an excessively low value for the [Maximum password age](maximum-password-age.md) policy setting is likely to increase administrative overhead because users who forget their passwords might ask the Help Desk to reset them frequently.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md b/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md
index c1b6e0c09e..5198399434 100644
--- a/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md
+++ b/windows/security/threat-protection/security-policy-settings/enforce-user-logon-restrictions.md
@@ -37,9 +37,9 @@ The possible values for this Group Policy setting are:
### Best practices
-- If this policy setting is disabled, users might be granted session tickets for services that they do not have the right to use.
+- If this policy setting is disabled, users might be granted session tickets for services that they don't have the right to use.
- We recommend to set **Enforce user logon restrictions** to Enabled.
+ We recommend setting **Enforce user logon restrictions** to Enabled.
### 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.
### Group Policy
@@ -91,7 +91,7 @@ Enable the **Enforce user logon restrictions** setting.
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md b/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md
index f6eda6e23e..c9c6d11852 100644
--- a/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md
+++ b/windows/security/threat-protection/security-policy-settings/increase-a-process-working-set.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
-This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they are available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
+This policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident, and they're available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process.
Constant: SeIncreaseWorkingSetPrivilege
@@ -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 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.
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md
index 7c5ca6c4a7..a54c5e93d9 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-display-user-information-when-the-session-is-locked.md
@@ -44,9 +44,9 @@ This setting has these possible values:
- **User display name, domain and user names**
- For a local logon, the user's full name is displayed.
+ For a local sign in, the user's full name is displayed.
If the user signed in using a Microsoft account, the user's email address is displayed.
- For a domain logon, the domain\username is displayed.
+ For a domain sign in, the domain\username is displayed.
This setting has the same effect as turning on the **Privacy** setting.
- **User display name only**
@@ -57,30 +57,30 @@ This setting has these possible values:
- **Do not display user information**
No names are displayed.
- Beginning with Windows 10 version 1607, this option is not supported.
+ Beginning with Windows 10 version 1607, this option isn't supported.
If this option is chosen, the full name of the user who locked the session is displayed instead.
This change makes this setting consistent with the functionality of the new **Privacy** setting.
To display no user information, enable the Group Policy setting **Interactive logon: Don't display last signed-in**.
- **Domain and user names only**
- For a domain logon only, the domain\username is displayed.
+ For a domain sign in only, the domain\username is displayed.
The **Privacy** setting is automatically on and grayed out.
- **Blank**
Default setting.
This setting translates to “Not defined,” but it will display the user's full name in the same manner as the option **User display name only**.
- When an option is set, you cannot reset this policy to blank, or not defined.
+ When an option is set, you can't reset this policy to blank, or not defined.
### Hotfix for Windows 10 version 1607
-Clients that run Windows 10 version 1607 will not show details on the sign-in screen even if the **User display name, domain and user names** option is chosen because the **Privacy** setting is off.
+Clients that run Windows 10 version 1607 won't show details on the sign-in screen even if the **User display name, domain and user names** option is chosen because the **Privacy** setting is off.
If the **Privacy** setting is turned on, details will show.
-The **Privacy** setting cannot be changed for clients in bulk.
+The **Privacy** setting can't be changed for clients in bulk.
Instead, apply [KB 4013429](https://www.catalog.update.microsoft.com/Search.aspx?q=KB4013429) to clients that run Windows 10 version 1607 so they behave similarly to previous versions of Windows.
-Clients that run later versions of Windows 10 do not require a hotfix.
+Clients that run later versions of Windows 10 don't require a hotfix.
There are related Group Policy settings:
@@ -93,19 +93,19 @@ There are related Group Policy settings:
For all versions of Windows 10, only the user display name is shown by default.
If **Block user from showing account details on sign-in** is enabled, then only the user display name is shown regardless of any other Group Policy settings.
-Users will not be able to show details.
+Users won't be able to show details.
-If **Block user from showing account details on sign-in** is not enabled, then you can set **Interactive logon: Display user information when the session is locked** to **User display name, domain and user names** or **Domain and user names only** to show additional details such as domain\username.
+If **Block user from showing account details on sign-in** isn't enabled, then you can set **Interactive logon: Display user information when the session is locked** to **User display name, domain and user names** or **Domain and user names only** to show other details such as domain\username.
In this case, clients that run Windows 10 version 1607 need [KB 4013429](https://www.catalog.update.microsoft.com/Search.aspx?q=KB4013429) applied.
-Users will not be able to hide additional details.
+Users won't be able to hide other details.
-If **Block user from showing account details on sign-in** is not enabled and **Don’t display last signed-in** is enabled, the username will not be shown.
+If **Block user from showing account details on sign-in** isn't enabled and **Don’t display last signed-in** is enabled, the username won't be shown.
### Best practices
-Your implementation of this policy depends on your security requirements for displayed logon information. If you run computers that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
+Your implementation of this policy depends on your security requirements for displayed sign-in information. If you run computers that store sensitive data, with monitors displayed in unsecured locations, or if you have computers with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
-Depending on your security policy, you might also want to enable the [Interactive logon: Do not display last user name](interactive-logon-do-not-display-last-user-name.md) policy.
+Depending on your security policy, you might also want to enable the [Interactive logon: Don't display last user name](interactive-logon-do-not-display-last-user-name.md) policy.
### Location
@@ -128,7 +128,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.
### Policy conflict considerations
@@ -136,7 +136,7 @@ None
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -148,9 +148,9 @@ When a computer displays the Secure Desktop in an unsecured area, certain user i
### Countermeasure
-Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the logon tiles are displayed for each logged on user.
+Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the sign-in tiles are displayed for each signed-in user.
-You might also want to enable the [Interactive logon: Do not display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to log on.
+You might also want to enable the [Interactive logon: Don't display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the sign-in name and sign-in tile of the last user to sign in.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md
index 9994a60f7e..47bac4e4cc 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-display-last-user-name.md
@@ -1,6 +1,6 @@
---
title: Interactive logon Don't display last signed-in (Windows 10)
-description: Describes the best practices, location, values, and security considerations for the Interactive logon Do not display last user name security policy setting.
+description: Describes the best practices, location, values, and security considerations for the Interactive logon Don't display last user name security policy setting.
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
@@ -26,11 +26,11 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This security policy setting determines whether the name of the last user to log on to the device is displayed on the Secure Desktop.
+This security policy setting determines whether the name of the last user to sign in to the device is displayed on the Secure Desktop.
-If this policy is enabled, the full name of the last user to successfully log on is not displayed on the Secure Desktop, nor is the user’s logon tile displayed. Additionally, if the **Switch user** feature is used, the full name and logon tile are not displayed. The logon screen requests a qualified domain account name (or local user name) and password.
+If this policy is enabled, the full name of the last user to successfully sign in isn't displayed on the Secure Desktop, nor is the user’s sign-in tile displayed. Additionally, if the **Switch user** feature is used, the full name and sign-in tile aren't displayed. The sign-in screen requests a qualified domain account name (or local user name) and password.
-If this policy is disabled, the full name of the last user to log on is displayed, and the user’s logon tile is displayed. This behavior is the same when the **Switch user** feature is used.
+If this policy is disabled, the full name of the last user to sign in is displayed, and the user’s sign-in tile is displayed. This behavior is the same when the **Switch user** feature is used.
### Possible values
@@ -40,7 +40,7 @@ If this policy is disabled, the full name of the last user to log on is displaye
### Best practices
-Your implementation of this policy depends on your security requirements for displayed logon information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security policy.
+Your implementation of this policy depends on your security requirements for displayed sign-in information. If you have devices that store sensitive data, with monitors displayed in unsecured locations, or if you have devices with sensitive data that are remotely accessed, revealing logged on user’s full names or domain account names might contradict your overall security 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.
### Policy conflict considerations
@@ -71,7 +71,7 @@ None.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -79,7 +79,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to log on.
+An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to sign in.
### Countermeasure
@@ -87,7 +87,7 @@ Enable the **Interactive logon: Do not display last user name** setting.
### Potential impact
-Users must always type their user names and passwords when they log on locally or to the domain. The logon tiles of all logged on users are not displayed.
+Users must always type their user names and passwords when they sign in locally or to the domain. The sign-in tiles of all logged on users aren't displayed.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md
index 4131998946..3594cd303d 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-do-not-require-ctrl-alt-del.md
@@ -26,15 +26,15 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.
+This security setting determines whether pressing CTRL+ALT+DEL is required before a user can sign in.
-If this policy setting is enabled on a device, a user is not required to press CTRL+ALT+DEL to log on.
+If this policy setting is enabled on a device, a user isn't required to press CTRL+ALT+DEL to sign in.
-If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to the Windows operating system (unless they are using a smart card for logon).
+If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to the Windows operating system (unless they're using a smart card for signing in).
-Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to device running the Windows operating system; however, not having to press the CTRL+ALT+DELETE key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DELETE before users log on ensures that users are communicating by means of a trusted path when entering their passwords.
+Microsoft developed this feature to make it easier for users with certain types of physical impairments to sign in to a device running the Windows operating system; however, not having to press the CTRL+ALT+DELETE key combination leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DELETE before users sign in ensures that users are communicating through a trusted path when entering their passwords.
-A malicious user might install malware that looks like the standard logon dialog box for the Windows operating system, and capture a user's password. The attacker can then log on to the compromised account with whatever level of user rights that user has.
+A malicious user might install malware that looks like the standard sign-in dialog box for the Windows operating system, and capture a user's password. The attacker can then sign in to the compromised account with whatever level of user rights that user has.
### Possible values
@@ -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.
### Policy conflict considerations
@@ -77,7 +77,7 @@ Beginning with Windows Server 2008 and Windows Vista, the CTRL+ALT+DELETE key
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -85,9 +85,9 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-This setting makes it easier for users with certain types of physical impairments to log on to devices that run the Windows operating system. However, if users are not required to press CTRL+ALT+DEL, they are susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before logon, user passwords are communicated by means of a trusted path.
+This setting makes it easier for users with certain types of physical impairments to sign in to devices that run the Windows operating system. However, if users aren't required to press CTRL+ALT+DEL, they're susceptible to attacks that attempt to intercept their passwords. If CTRL+ALT+DEL is required before signing in, user passwords are communicated through a trusted path.
-If this setting is enabled, an attacker could install malware that looks like the standard logon dialog box in the Windows operating system, and capture the user's password. The attacker would then be able to log on to the compromised account with whatever level of privilege that user has.
+If this setting is enabled, an attacker could install malware that looks like the standard sign-in dialog box in the Windows operating system, and capture the user's password. The attacker would then be able to sign in to the compromised account with whatever level of privilege that user has.
### Countermeasure
@@ -95,7 +95,7 @@ Disable the **Interactive logon: Do not require CTRL+ALT+DEL** setting.
### Potential impact
-Unless they use a smart card to log on, users must simultaneously press the three keys before the logon dialog box is displayed.
+Unless they use a smart card to sign in, users must simultaneously press the three keys before the sign-in dialog box is displayed.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md
index e0431252ef..2fd2510de4 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-dont-display-username-at-sign-in.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, and security considerations for
A new policy setting has been introduced in Windows 10 starting with Windows 10 version 1703. This security policy setting determines whether the username is displayed during sign in. This setting only affects the **Other user** tile.
-If the policy is enabled and a user signs in as **Other user**, the full name of the user is not displayed during sign-in. In the same context, if users type their email address and password at the sign in screen and press **Enter**, the displayed text “Other user” remains unchanged, and is no longer replaced by the user’s first and last name, as in previous versions of Windows 10. Additionally,if users enter their domain user name and password and click **Submit**, their full name is not shown until the Start screen displays.
+If the policy is enabled and a user signs in as **Other user**, the full name of the user isn't displayed during sign-in. In the same context, if users type their email address and password at the sign-in screen and press **Enter**, the displayed text “Other user” remains unchanged, and is no longer replaced by the user’s first and last name, as in previous versions of Windows 10. Additionally,if users enter their domain user name and password and click **Submit**, their full name isn't shown until the Start screen displays.
If the policy is disabled and a user signs in as **Other user**, the “Other user” text is replaced by the user’s first and last name during sign-in.
@@ -64,7 +64,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.
### Policy conflict considerations
@@ -72,7 +72,7 @@ None.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -80,7 +80,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to log on.
+An attacker with access to the console (for example, someone with physical access or someone who can connect to the device through Remote Desktop Session Host) could view the name of the last user who logged on. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try to sign in.
### Countermeasure
@@ -88,7 +88,7 @@ Enable the **Interactive logon: Don't display user name at sign-in** setting.
### Potential impact
-Users must always type their usernames and passwords when they log on locally or to the domain. The logon tiles of all logged on users are not displayed.
+Users must always type their usernames and passwords when they log on locally or to the domain. The sign in tiles of all logged on users aren't displayed.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md
index e9a1fea0ae..148956b0f3 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-account-lockout-threshold.md
@@ -29,9 +29,9 @@ Describes the best practices, location, values, management, and security conside
Beginning with Windows Server 2012 and Windows 8, the **Interactive logon: Machine account threshold** security policy setting enforces the lockout policy on those computers that have BitLocker enabled to protect operating system volumes.
-The security setting allows you to set a threshold for the number of failed logon attempts that causes the device to be locked by using BitLocker. This means, if the specified maximum number of failed logon attempts is exceeded, the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to restore full access.
+The security setting allows you to set a threshold for the number of failed sign-in attempts that causes the device to be locked by using BitLocker. This threshold means, if the specified maximum number of failed sign-in attempts is exceeded, the device will invalidate the Trusted Platform Module (TPM) protector and any other protector except the 48-digit recovery password, and then reboot. During Device Lockout mode, the computer or device only boots into the touch-enabled Windows Recovery Environment (WinRE) until an authorized user enters the recovery password to restore full access.
-Failed password attempts on workstations or member servers that have been locked by using either Ctrl+Alt+Delete or password-protected screen savers count as failed logon attempts.
+Failed password attempts on workstations or member servers that have been locked by using either Ctrl+Alt+Delete or password-protected screen savers count as failed sign-in attempts.
### Possible values
@@ -39,7 +39,7 @@ You can set the **invalid logon attempts** value between 1 and 999. Values from
### Best practices
-Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
+Use this policy setting in conjunction with your other failed account sign-in attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
### Location
@@ -64,13 +64,13 @@ This section describes features and tools that are available to help you manage
### Restart requirement
-A restart is required for changes to this policy to become effective when they are saved locally or distributed through Group Policy.
+A restart is required for changes to this policy to become effective when they're saved locally or distributed through Group Policy.
### Group Policy
Because this policy setting was introduced in Windows Server 2012 and Windows 8, it can only be set locally on those devices that contain this policy setting, but it can be set and distributed through Group Policy to any computer running the Windows operating system that supports Group Policy and is BitLocker-enabled.
-When setting this policy, consider the [Account lockout threshold](account-lockout-threshold.md) policy setting, which determines the number of failed logon attempts that will cause a user account to be locked out.
+When setting this policy, consider the [Account lockout threshold](account-lockout-threshold.md) policy setting, which determines the number of failed sign-in attempts that will cause a user account to be locked out.
## Security considerations
@@ -82,7 +82,7 @@ This policy setting helps protect a BitLocker-encrypted device from attackers at
### Countermeasure
-Use this policy setting in conjunction with your other failed account logon attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
+Use this policy setting in conjunction with your other failed account sign-in attempts policy. For example, if the [Account lockout threshold](account-lockout-threshold.md) policy setting is set at 4, then setting **Interactive logon: Machine account lockout threshold** at 6 allows the user to restore access to resources without having to restore access to the device resulting from a BitLocker lock out.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md
index 737bfddba3..01524c765c 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit.md
@@ -67,7 +67,7 @@ This section describes features and tools that are available to help you manage
### Restart requirement
-Restart is required for changes to this policy to become effective when they are saved locally or distributed through Group Policy.
+Restart is required for changes to this policy to become effective when they're saved locally or distributed through Group Policy.
### Group Policy
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md
index ec72b350f1..55437fb4e1 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-text-for-users-attempting-to-log-on.md
@@ -30,13 +30,13 @@ Describes the best practices, location, values, management, and security conside
The **Interactive logon: Message text for users attempting to log on** and [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md) policy settings are closely related.
-**Interactive logon: Message text for users attempting to log on** specifies a text message to be displayed to users when they log on.
+**Interactive logon: Message text for users attempting to log on** specifies a text message to be displayed to users when they sign in.
-**Interactive logon: Message title for users attempting to log on** specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons — for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited.
+**Interactive logon: Message title for users attempting to log on** specifies a title to appear in the title bar of the window that contains the text message. This text is often used for legal reasons—for example, to warn users about the ramifications of misusing company information, or to warn them that their actions might be audited.
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
-When these policy settings are configured, users will see a dialog box before they can log on to the server console.
+When these policy settings are configured, users will see a dialog box before they can sign in to the server console.
### Possible values
@@ -47,10 +47,10 @@ The possible values for this setting are:
### Best practices
-- It is advisable to set **Interactive logon: Message text for users attempting to log on** to a value similar to one of the following:
+- It's advisable to set **Interactive logon: Message text for users attempting to log on** to a value similar to one of the following:
1. IT IS AN OFFENSE TO CONTINUE WITHOUT PROPER AUTHORIZATION.
- 2. This system is restricted to authorized users. Individuals who attempt unauthorized access will be prosecuted. If you are unauthorized, terminate access now. Click OK to indicate your acceptance of this information.
+ 2. This system is restricted to authorized users. Individuals who attempt unauthorized access will be prosecuted. If you're unauthorized, terminate access now. Click OK to indicate your acceptance of this information.
> [!IMPORTANT]
> Any warning that you display in the title or text should be approved by representatives from your organization's legal and human resources departments.
@@ -77,22 +77,22 @@ This section describes different requirements to help you manage this policy.
### Restart requirement
-None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-There are two policy settings that relate to logon displays:
+There are two policy settings that relate to sign-in displays:
- **Interactive logon: Message text for users attempting to log on**
- [Interactive logon: Message title for users attempting to log on](interactive-logon-message-title-for-users-attempting-to-log-on.md)
-The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
+The first policy setting specifies a text message that displays to users when they sign in, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
### Vulnerability
-Users often do not understand the importance of security practices. However, the display of a warning message before logon may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the logon process.
+Users often don't understand the importance of security practices. However, the display of a warning message before signing in may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the sign-in process.
### Countermeasure
@@ -100,7 +100,7 @@ Configure the **Interactive logon: Message text for users attempting to log on**
### Potential impact
-Users see a message in a dialog box before they can log on to the server console.
+Users see a message in a dialog box before they can sign in to the server console.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md
index e5f5ce5eb8..ee32c91b18 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-message-title-for-users-attempting-to-log-on.md
@@ -33,7 +33,7 @@ The **Interactive logon: Message title for users attempting to log on** and [Int
Not using this warning-message policy setting leaves your organization legally vulnerable to trespassers who unlawfully penetrate your network. Legal precedents have established that organizations that display warnings to users who connect to their servers over a network have a higher rate of successfully prosecuting trespassers.
-When these policy settings are configured, users will see a dialog box before they can log on to the server console.
+When these policy settings are configured, users will see a dialog box before they can sign in the server console.
### Possible values
@@ -42,7 +42,7 @@ When these policy settings are configured, users will see a dialog box before th
### Best practices
-1. It is advisable to set **Interactive logon: Message title for users attempting to log on** to a value similar to one the following:
+1. It's advisable to set **Interactive logon: Message title for users attempting to log on** to a value similar to one the following values:
- RESTRICTED SYSTEM
@@ -75,22 +75,22 @@ 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
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-There are two policy settings that relate to logon displays:
+There are two policy settings that relate to sign-in displays:
- [Interactive logon: Message text for users attempting to log on](interactive-logon-message-text-for-users-attempting-to-log-on.md)
- **Interactive logon: Message title for users attempting to log on**
-The first policy setting specifies a text message that displays to users when they log on, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
+The first policy setting specifies a text message that displays to users when they sign in, and the second policy setting specifies a title for the title bar of the text message window. Many organizations use this text for legal purposes; for example, to warn users about the ramifications of misuse of company information, or to warn them that their actions may be audited.
### Vulnerability
-Users often do not understand the importance of security practices. However, the display of a warning message with an appropriate title before logon may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the logon process.
+Users often don't understand the importance of security practices. However, the display of a warning message with an appropriate title before signing in may help prevent an attack by warning malicious or uninformed users about the consequences of their misconduct before it happens. It may also help reinforce corporate policies by notifying employees of appropriate policies during the sign-in process.
### Countermeasure
@@ -100,7 +100,7 @@ Configure the [Interactive logon: Message text for users attempting to log on](i
### Potential impact
-Users see a message in a dialog box before they can log on to the server console.
+Users see a message in a dialog box before they can sign in to the server console.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
index 90773e0b18..966a3f3c4e 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md
@@ -27,19 +27,19 @@ Describes the best practices, location, values, policy management, and security
## Reference
-The **Interactive logon: Number of previous logons to cache (in case domain controller is not available**) policy setting determines whether a user can log on to a Windows domain by using cached account information. Logon information for domain accounts can be cached locally so that, if a domain controller cannot be contacted on subsequent logons, a user can still log on. This policy setting determines the number of unique users whose logon information is cached locally.
+The **Interactive logon: Number of previous logons to cache (in case domain controller is not available**) policy setting determines whether a user can sign in to a Windows domain by using cached account information. Sign-in information for domain accounts can be cached locally so that, if a domain controller can't be contacted on subsequent logons, a user can still sign in. This policy setting determines the number of unique users whose sign-in information is cached locally.
-If a domain controller is unavailable and a user's logon information is cached, the user is prompted with the following message:
+If a domain controller is unavailable and a user's sign-in information is cached, the user is prompted with the following message:
-A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.
+A domain controller for your domain couldn't be contacted. You've been logged on using cached account information. Changes to your profile since you last logged on might not be available.
-If a domain controller is unavailable and a user's logon information is not cached, the user is prompted with this message:
+If a domain controller is unavailable and a user's sign-in information isn't cached, the user is prompted with this message:
-The system cannot log you on now because the domain *DOMAIN NAME* is not available.
+The system can't log you on now because the domain *DOMAIN NAME* isn't available.
-The value of this policy setting indicates the number of users whose logon information the server caches locally. If the value is 10, the server caches logon information for 10 users. When an 11th user logs on to the device, the server overwrites the oldest cached logon session.
+The value of this policy setting indicates the number of users whose sign-in information the server caches locally. If the value is 10, the server caches sign-in information for 10 users. When an 11th user signs in to the device, the server overwrites the oldest cached sign-in session.
-Users who access the server console will have their logon credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by
+Users who access the server console will have their sign-in credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by
encrypting the information and keeping the cached credentials in the system's registries, which are spread across numerous physical locations.
> [!NOTE]
@@ -52,7 +52,7 @@ encrypting the information and keeping the cached credentials in the system's re
### Best practices
-The [Windows security baselines](../windows-security-baselines.md) do not recommend configuring this setting.
+The [Windows security baselines](../windows-security-baselines.md) don't recommend configuring this setting.
### Location
@@ -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 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.
### Policy conflict considerations
@@ -85,7 +85,7 @@ None
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -93,20 +93,20 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The number that is assigned to this policy setting indicates the number of users whose logon information is cache locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an 11th user logs on to the device, the server overwrites the oldest cached logon session.
+The number that is assigned to this policy setting indicates the number of users whose sign-in information is cached locally by the servers. If the number is set to 10, the server caches sign-in information for 10 users. When an 11th user signs in to the device, the server overwrites the oldest cached sign-in session.
-Users who access the server console have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.
+Users who access the server console have their sign-in credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.
To mitigate this type of attack, Windows encrypts the information and obscures its physical location.
### Countermeasure
-Configure the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** setting to 0, which disables the local caching of logon information. Additional countermeasures include enforcement of strong password policies and physically secure locations for the computers.
+Configure the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** setting to 0, which disables the local caching of sign-in information. Other countermeasures include enforcement of strong password policies and physically secure locations for the computers.
### Potential impact
-Users cannot log on to any devices if there is no domain controller available to authenticate them. Organizations can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user's logon information is still in the cache, even if a
-member of the IT department has recently logged on to the device to perform system maintenance. This method allows users to log on to their computers when they are not connected to the organization's network.
+Users can't sign in to any devices if there's no domain controller available to authenticate them. Organizations can configure this value to 2 for end-user computers, especially for mobile users. A configuration value of 2 means that the user's sign-in information is still in the cache, even if a
+member of the IT department has recently logged on to the device to perform system maintenance. This method allows users to sign in to their computers when they aren't connected to the organization's network.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
index 88948dcc4f..be5146c636 100644
--- a/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
+++ b/windows/security/threat-protection/security-policy-settings/interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md
@@ -27,13 +27,13 @@ Describes the best practices, location, values, policy management, and security
## Reference
-Unlocking a locked device requires logon information. For domain accounts, the **Interactive logon: Require Domain Controller authentication to unlock workstation** policy setting determines whether it is necessary to contact a domain controller to unlock a device. Enabling this policy setting requires a domain controller to authenticate the domain account that is being used to unlock the device. Disabling this policy setting allows a user to unlock the device without the computer verifying the logon information with a domain controller. However, if [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) is set to a value greater than zero, the user's cached credentials will be used to unlock the system.
+Unlocking a locked device requires sign-in information. For domain accounts, the **Interactive logon: Require Domain Controller authentication to unlock workstation** policy setting determines whether it's necessary to contact a domain controller to unlock a device. Enabling this policy setting requires a domain controller to authenticate the domain account that is being used to unlock the device. Disabling this policy setting allows a user to unlock the device without the computer verifying the sign-in information with a domain controller. However, if [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) is set to a value greater than zero, the user's cached credentials will be used to unlock the system.
The device caches (locally in memory) the credentials of any users who have been authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console.
-When cached credentials are used, any changes that have recently been made to the account (such as user rights assignments, account lockout, or the account being disabled) are not considered or applied after this authentication process. This means not only that user rights are not updated, but more importantly that disabled accounts are still able to unlock the console of the system.
+When cached credentials are used, any changes that have recently been made to the account (such as user rights assignments, account lockout, or the account being disabled) aren't considered or applied after this authentication process. This result means not only that user rights aren't updated, but more importantly that disabled accounts are still able to unlock the console of the system.
-It is advisable to set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their devices.
+It's advisable to set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to reauthenticate to the domain controller. If no domain controller is available, users can't unlock their devices.
### Possible values
@@ -43,7 +43,7 @@ It is advisable to set **Interactive logon: Require Domain Controller authentica
### Best practices
-- Set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their devices.
+- Set **Interactive logon: Require Domain Controller authentication to unlock workstation** to Enabled and set [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) to 0. When the console of a device is locked by a user or automatically by a screen saver time-out, the console can only be unlocked if the user is able to reauthenticate to the domain controller. If no domain controller is available, users can't unlock their devices.
### Location
@@ -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.
### Policy conflict considerations
@@ -76,7 +76,7 @@ None
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -84,7 +84,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-By default, the device caches locally in memory the credentials of any users who are authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—are not considered or applied after the account is authenticated. User privileges are not updated, and disabled accounts are still able to unlock the console of the device
+By default, the device caches locally in memory the credentials of any users who are authenticated. The device uses these cached credentials to authenticate anyone who attempts to unlock the console. When cached credentials are used, any changes that have recently been made to the account—such as user rights assignments, account lockout, or the account being disabled—aren't considered or applied after the account is authenticated. User privileges aren't updated, and disabled accounts are still able to unlock the console of the device
### Countermeasure
@@ -92,7 +92,7 @@ Configure the **Interactive logon: Require Domain Controller authentication to u
### Potential impact
-When the console on a device is locked by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can re-authenticate to the domain controller. If no domain controller is available, users cannot unlock their workstations. If you configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) cannot log on.
+When the console on a device is locked by a user or automatically by a screen-saver timeout, the console can be unlocked only if the user can reauthenticate to the domain controller. If no domain controller is available, users can't unlock their workstations. If you configure the [Interactive logon: Number of previous logons to cache (in case domain controller is not available)](interactive-logon-number-of-previous-logons-to-cache-in-case-domain-controller-is-not-available.md) setting to 0, users whose domain controllers are unavailable (such as mobile or remote users) can't sign in.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/kerberos-policy.md b/windows/security/threat-protection/security-policy-settings/kerberos-policy.md
index 50e612ee9a..959ced7fdc 100644
--- a/windows/security/threat-protection/security-policy-settings/kerberos-policy.md
+++ b/windows/security/threat-protection/security-policy-settings/kerberos-policy.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
Describes the Kerberos Policy settings and provides links to policy setting descriptions.
-The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used by an attacker. However, this also increases the authorization overhead. In most environments, these settings should not need to be changed.
+The Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user's credentials being stolen and successfully used by an attacker. However, this ticket lifetime reduction also increases the authorization overhead. In most environments, these settings shouldn't need to be changed.
These policy settings are located in **\\Computer Configuration\\Windows Settings\\Security Settings\\Account Policies\\Kerberos Policy**.
diff --git a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md b/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md
index a0534994d0..9a7f5f87d4 100644
--- a/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md
+++ b/windows/security/threat-protection/security-policy-settings/load-and-unload-device-drivers.md
@@ -27,10 +27,10 @@ Describes the best practices, location, values, policy management, and security
## Reference
-This policy setting determines which users can dynamically load and unload device drivers. This user right is not required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code.
+This policy setting determines which users can dynamically load and unload device drivers. This user right isn't required if a signed driver for the new hardware already exists in the driver.cab file on the device. Device drivers run as highly privileged code.
Windows supports the Plug and Play specifications that define how a computer can detect and configure newly added hardware, and then automatically install the device driver. Prior to Plug and Play, users needed to manually configure devices before attaching them to the device. This model allows a user to plug in the hardware, then Windows searches for an appropriate device driver package and automatically configures it to work without interfering with other devices.
-Because device driver software runs as if it is a part of the operating system with unrestricted access to the entire computer, it is critical that only known and authorized device drivers be permitted.
+Because device driver software runs as if it's a part of the operating system with unrestricted access to the entire computer, it's critical that only known and authorized device drivers be permitted.
Constant: SeLoadDriverPrivilege
@@ -42,7 +42,7 @@ Constant: SeLoadDriverPrivilege
### Best practices
-- Because of the potential security risk, do not assign this user right to any user, group, or process that you do not want to take over the system.
+- Because of the potential security risk, don't assign this user right to any user, group, or process that you don't want to take over the system.
### Location
@@ -67,7 +67,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.
@@ -94,11 +94,11 @@ Device drivers run as highly privileged code. A user who has the **Load and unlo
### Countermeasure
-Do not assign the **Load and unload device drivers** user right to any user or group other than Administrators on member servers. On domain controllers, do not assign this user right to any user or group other than Domain Admins.
+Don't assign the **Load and unload device drivers** user right to any user or group other than Administrators on member servers. On domain controllers, don't assign this user right to any user or group other than Domain Admins.
### Potential impact
-If you remove the **Load and unload device drivers** user right from the Print Operators group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.
+If you remove the **Load and unload device drivers** user right from the Print Operators group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks aren't negatively affected.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md
index 17b2d7d0e6..5aae309524 100644
--- a/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md
+++ b/windows/security/threat-protection/security-policy-settings/lock-pages-in-memory.md
@@ -31,7 +31,7 @@ This policy setting determines which accounts can use a process to keep data in
Normally, an application running on Windows can negotiate for more physical memory, and in response to the request, the application begins to move the data from RAM (such as the data cache) to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use.
-Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This could lead to performance degradation.
+Enabling this policy setting for a specific account (a user account or a process account for an application) prevents paging of the data. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This limitation could lead to performance degradation.
>**Note:** By configuring this policy setting, the performance of the Windows operating system will differ depending on if applications are running on 32-bit or 64-bit systems, and if they are virtualized images. Performance will also differ between earlier and later versions of the Windows operating system.
@@ -67,7 +67,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.
@@ -92,7 +92,7 @@ Users with the **Lock pages in memory** user right could assign physical memory
### Countermeasure
-Do not assign the **Lock pages in memory** user right to any accounts.
+Don't assign the **Lock pages in memory** user right to any accounts.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md b/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md
index 4fb931974f..126438d791 100644
--- a/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md
+++ b/windows/security/threat-protection/security-policy-settings/log-on-as-a-batch-job.md
@@ -27,7 +27,7 @@ This article describes the recommended practices, location, values, policy manag
## Reference
-This policy setting determines which accounts can log on by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the **Log on as a batch job** user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user's security context.
+This policy setting determines which accounts can sign in by using a batch-queue tool such as the Task Scheduler service. When you use the Add Scheduled Task Wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the **Log on as a batch job** user right. When the scheduled time arrives, the Task Scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user's security context.
Constant: SeBatchLogonRight
@@ -95,7 +95,7 @@ For IIS servers, configure this policy locally instead of through domain–based
### Potential impact
-If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer can't assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you might need to assign this user right to additional accounts that those components require. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right isn't assigned to this group and these accounts, IIS can't run some COM objects that are necessary for proper functionality.
+If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer can't assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you might need to assign this user right to other accounts that those components require. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right isn't assigned to this group and these accounts, IIS can't run some COM objects that are necessary for proper functionality.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md b/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md
index 5da39ee708..4566dfbf15 100644
--- a/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md
+++ b/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log.md
@@ -27,8 +27,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
-This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the
-Security log in Event Viewer. For more info about the Object Access audit policy, see [Audit object access](../auditing/basic-audit-object-access.md).
+This policy setting determines which users can specify object access audit options for individual resources such as files, Active Directory objects, and registry keys. These objects specify their system access control lists (SACL). A user who is assigned this user right can also view and clear the Security log in Event Viewer. For more information about the Object Access audit policy, see [Audit object access](../auditing/basic-audit-object-access.md).
Constant: SeSecurityPrivilege
@@ -40,7 +39,7 @@ Constant: SeSecurityPrivilege
### Best practices
1. Before removing this right from a group, investigate whether applications are dependent on this right.
-2. Generally, assigning this user right to groups other than Administrators is not necessary.
+2. Generally, assigning this user right to groups other than Administrators isn't necessary.
### Location
@@ -65,11 +64,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 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.
-Audits for object access are not performed unless you enable them by using the Local Group Policy Editor, the Group Policy Management Console (GPMC), or the Auditpol command-line tool.
+Audits for object access aren't performed unless you enable them by using the Local Group Policy Editor, the Group Policy Management Console (GPMC), or the Auditpol command-line tool.
For more information about the Object Access audit policy, see [Audit object access](../auditing/basic-audit-object-access.md).
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md
index e3ed6c49c4..3dbb0c258d 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md
+++ b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-service-ticket.md
@@ -31,16 +31,16 @@ The **Maximum lifetime for service ticket** policy setting determines the maximu
The possible values for this Group Policy setting are:
-- A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets do not expire).
+- A user-defined number of minutes from 10 through 99,999, or 0 (in which case service tickets don't expire).
- Not defined.
-If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that authenticated the connection expires during the connection.
+If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations aren't interrupted if the session ticket that authenticated the connection expires during the connection.
-If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours. In addition, users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire.
+If the value for this policy setting is too high, users might be able to access network resources outside of their sign-in hours. In addition, users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire.
### Best practices
-- It is advisable to set **Maximum lifetime for service ticket** to **600** minutes.
+- It's advisable to set **Maximum lifetime for service ticket** to **600** minutes.
### Location
@@ -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.
This policy setting is configured on the domain controller.
@@ -86,7 +86,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-If you configure the value for the **Maximum lifetime for service ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled.
+If you configure the value for the **Maximum lifetime for service ticket** setting too high, users might be able to access network resources outside of their sign-in hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled.
### Countermeasure
@@ -94,7 +94,7 @@ Configure the **Maximum lifetime for service ticket** setting to 600 minutes.
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md
index 0b5fddd3cd..4807321a05 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md
+++ b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket-renewal.md
@@ -36,9 +36,9 @@ The possible values for this Group Policy setting are:
### Best practices
-- If the value for this policy setting is too high, users may be able to renew very old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.
+- If the value for this policy setting is too high, users may be able to renew old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.
- It is advisable to set **Maximum lifetime for user ticket renewal** to **7** days.
+ It's advisable to set **Maximum lifetime for user ticket renewal** to **7** days.
### Location
@@ -61,7 +61,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.
@@ -84,7 +84,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-If the value for the **Maximum lifetime for user ticket renewal** setting is too high, users might be able to renew very old user tickets.
+If the value for the **Maximum lifetime for user ticket renewal** setting is too high, users might be able to renew old user tickets.
### Countermeasure
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md
index b189dda660..53e36fa838 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md
+++ b/windows/security/threat-protection/security-policy-settings/maximum-lifetime-for-user-ticket.md
@@ -34,7 +34,7 @@ The possible values for this Group Policy setting are:
- A user-defined number of hours from 0 through 99,999
- Not defined
-If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire.
+If the value for this policy setting is too high, users might be able to access network resources outside of their sign-in hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire.
### Best practices
@@ -61,7 +61,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 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.
This policy setting is configured on the domain controller.
@@ -84,7 +84,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-If you configure the value for the **Maximum lifetime for user ticket** setting too high, users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack.
+If you configure the value for the **Maximum lifetime for user ticket** setting too high, users might be able to access network resources outside of their sign-in hours. Also, users whose accounts were disabled might continue to have access to network services with valid user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack.
### Countermeasure
@@ -92,7 +92,7 @@ Configure the **Maximum lifetime for user ticket** setting with a value between
### Potential impact
-Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to access resources that the user does not have rights to. However, it requires more frequent requests to the KDC for ticket-granting tickets on behalf of users. Most KDCs can support a value of four hours without too much additional burden.
+Reducing this setting from the default value reduces the likelihood that the ticket-granting ticket will be used to access resources that the user doesn't have rights to. However, it requires more frequent requests to the KDC for ticket-granting tickets on behalf of users. Most KDCs can support a value of 4 hours without any extra burden.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md b/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
index 546b7de4f2..e63f28edde 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
+++ b/windows/security/threat-protection/security-policy-settings/maximum-password-age.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management, and security
## Reference
-The **Maximum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If **Maximum password age** is between 1 and 999 days, the minimum password age must be less than the maximum password age. If **Maximum password age** is set to 0, [Minimum password age](minimum-password-age.md) can be any value between 0 and 998 days.
+The **Maximum password age** policy setting determines the period of time (in days) that a password can be used before the system requires the user to change it. You can set passwords to expire after a certain number of days between 1 and 999, or you can specify that passwords never expire by setting the number of days to 0. If **Maximum password age** is between 1 and 999 days, the minimum password age must be less than the maximum password age. If **Maximum password age** is set to 0, [Minimum password age](minimum-password-age.md) can be any value between 0 and 998 days.
>**Note:** Setting **Maximum password age** to -1 is equivalent to 0, which means it never expires. Setting it to any other negative number is equivalent to setting it to **Not Defined**.
@@ -66,7 +66,7 @@ This section describes features, tools, and guidance to help you manage this pol
### 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
@@ -78,13 +78,13 @@ The longer a password exists, the higher the likelihood that it will be compromi
### Considerations
-Mandated password changes are a long-standing security practice, but current research strongly indicates that password expiration has a negative effect. See [Microsoft Password Guidance](https://www.microsoft.com/research/publication/password-guidance/) for further information.
+Mandated password changes are a long-standing security practice, but current research strongly indicates that password expiration has a negative effect. For more information, see [Microsoft Password Guidance](https://www.microsoft.com/research/publication/password-guidance/).
-Configure the **Maximum password age** policy setting to a value that is suitable for your organization's business requirements. For example, many organisations have compliance or insurance mandates requiring a short lifespan on passwords. Where such a requirement exists, the **Maximum password age** policy setting can be used to meet business requirements.
+Configure the **Maximum password age** policy setting to a value that is suitable for your organization's business requirements. For example, many organizations have compliance or insurance mandates requiring a short lifespan on passwords. Where such a requirement exists, the **Maximum password age** policy setting can be used to meet business requirements.
### Potential impact
-If the **Maximum password age** policy setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization because users might keep their passwords in an unsecured location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
+If the **Maximum password age** policy setting is too low, users are required to change their passwords often. Such a configuration can reduce security in the organization because users might keep their passwords in an unsecured location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
## Related topics
From 895a909308a83efa90639bd1c0361dc9d8224cd4 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Tue, 28 Jun 2022 09:24:46 +0530
Subject: [PATCH 014/299] Acrolinx Enhancement Effort
---
...m-tolerance-for-computer-clock-synchronization.md | 10 +++++-----
...nencrypted-password-to-third-party-smb-servers.md | 12 ++++++------
...f-idle-time-required-before-suspending-session.md | 6 +++---
...r-attempt-s4u2self-to-obtain-claim-information.md | 8 ++++----
...rk-server-digitally-sign-communications-always.md | 10 +++++-----
5 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md b/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md
index fe607f246f..a3684bbc31 100644
--- a/windows/security/threat-protection/security-policy-settings/maximum-tolerance-for-computer-clock-synchronization.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
index 0cc87e361e..c17a0e599f 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-client-send-unencrypted-password-to-third-party-smb-servers.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
index abe6db2b33..5a14605d54 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-amount-of-idle-time-required-before-suspending-session.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
index 1ef73b3a59..f4ddaa9d5a 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-attempt-s4u2self-to-obtain-claim-information.md
+++ b/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
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md
index afb7ddfe20..080f186f03 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always.md
+++ b/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
1 Default for domain controller SMB traffic
2 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
From efeb3b3aadad02a57c9dac045b6111eba21d2ffa Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Tue, 28 Jun 2022 12:27:56 +0530
Subject: [PATCH 015/299] Acrolinx Enhancement Effort
---
...connect-clients-when-logon-hours-expire.md | 20 ++++++++---------
...server-spn-target-name-validation-level.md | 10 ++++-----
.../minimum-password-age.md | 14 ++++++------
.../minimum-password-length.md | 6 ++---
.../modify-an-object-label.md | 12 +++++-----
...ess-allow-anonymous-sidname-translation.md | 6 ++---
...-enumeration-of-sam-accounts-and-shares.md | 8 +++----
...w-anonymous-enumeration-of-sam-accounts.md | 8 +++----
...-credentials-for-network-authentication.md | 16 +++++++-------
...ne-permissions-apply-to-anonymous-users.md | 8 +++----
...-pipes-that-can-be-accessed-anonymously.md | 8 +++----
...-accessible-registry-paths-and-subpaths.md | 6 ++---
...cess-remotely-accessible-registry-paths.md | 6 ++---
...nymous-access-to-named-pipes-and-shares.md | 6 ++---
...lients-allowed-to-make-remote-sam-calls.md | 22 +++++++++----------
...shares-that-can-be-accessed-anonymously.md | 6 ++---
...g-and-security-model-for-local-accounts.md | 10 ++++-----
...ystem-to-use-computer-identity-for-ntlm.md | 14 ++++++------
...allow-localsystem-null-session-fallback.md | 12 +++++-----
...-this-computer-to-use-online-identities.md | 14 ++++++------
...e-encryption-types-allowed-for-kerberos.md | 16 +++++++-------
...ager-hash-value-on-next-password-change.md | 10 ++++-----
...ty-force-logoff-when-logon-hours-expire.md | 18 +++++++--------
...curity-lan-manager-authentication-level.md | 18 +++++++--------
...curity-ldap-client-signing-requirements.md | 12 +++++-----
...-ssp-based-including-secure-rpc-servers.md | 10 ++++-----
...rver-exceptions-for-ntlm-authentication.md | 14 ++++++------
...lm-add-server-exceptions-in-this-domain.md | 13 +++++------
...strict-ntlm-audit-incoming-ntlm-traffic.md | 16 +++++++-------
...udit-ntlm-authentication-in-this-domain.md | 16 +++++++-------
30 files changed, 177 insertions(+), 178 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
index 5cf58f4daf..6b528db190 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
+++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-disconnect-clients-when-logon-hours-expire.md
@@ -1,6 +1,6 @@
---
-title: Microsoft network server Disconnect clients when logon hours expire (Windows 10)
-description: Best practices, location, values, and security considerations for the policy setting, Microsoft network server Disconnect clients when logon hours expire.
+title: Microsoft network server Disconnect clients when sign-in hours expire (Windows 10)
+description: Best practices, location, values, and security considerations for the policy setting, Microsoft network server Disconnect clients when sign-in hours expire.
ms.assetid: 48b5c424-9ba8-416d-be7d-ccaabb3f49af
ms.reviewer:
ms.author: dansimp
@@ -18,7 +18,7 @@ ms.date: 04/19/2017
ms.technology: windows-sec
---
-# Microsoft network server: Disconnect clients when logon hours expire
+# Microsoft network server: Disconnect clients when sign-in hours expire
**Applies to**
- Windows 10
@@ -27,17 +27,17 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This policy setting enables or disables the forced disconnection of users who are connected to the local device outside their user account's valid logon hours. It affects the SMB component. If you enable this policy setting, client computer sessions with the SMB service are forcibly disconnected when the client's logon hours expire. If you disable this policy setting, established client device sessions are maintained after the client device's logon hours expire.
+This policy setting enables or disables the forced disconnection of users who are connected to the local device outside their user account's valid sign-in hours. It affects the SMB component. If you enable this policy setting, client computer sessions with the SMB service are forcibly disconnected when the client's sign-in hours expire. If you disable this policy setting, established client device sessions are maintained after the client device's sign-in hours expire.
### Possible values
- Enabled
- Client device sessions with the SMB service are forcibly disconnected when the client device's logon hours expire. If logon hours are not used in your organization, enabling this policy setting will have no impact.
+ Client device sessions with the SMB service are forcibly disconnected when the client device's sign-in hours expire. If sign-in hours aren't used in your organization, enabling this policy setting will have no impact.
- Disabled
- The system maintains an established client device session after the client device's logon hours have expired.
+ The system maintains an established client device session after the client device's sign-in hours have expired.
- Not defined
@@ -68,11 +68,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
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -80,7 +80,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-If your organization configures logon hours for users, it makes sense to enable this policy setting. Otherwise, users who should not have access to network resources outside of their logon hours can continue to use those resources with sessions that were established during allowed hours.
+If your organization configures sign-in hours for users, it makes sense to enable this policy setting. Otherwise, users who shouldn't have access to network resources outside of their sign-in hours can continue to use those resources with sessions that were established during allowed hours.
### Countermeasure
@@ -88,7 +88,7 @@ Enable the **Microsoft network server: Disconnect clients when logon hours expir
### Potential impact
-If logon hours are not used in your organization, this policy setting has no impact. If logon hours are used, existing user sessions are forcibly terminated when their logon hours expire.
+If sign-in hours aren't used in your organization, this policy setting has no impact. If sign-in hours are used, existing user sessions are forcibly terminated when their sign-in hours expire.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md
index 23c36d99fa..a403cf9029 100644
--- a/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md
+++ b/windows/security/threat-protection/security-policy-settings/microsoft-network-server-server-spn-target-name-validation-level.md
@@ -37,15 +37,15 @@ The options for validation levels are:
- **Off**
- The SPN from a SMB client is not required or validated by the SMB server.
+ The SPN from an SMB client isn't required or validated by the SMB server.
- **Accept if provided by client**
- The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be established if it matches the SMB server’s list of SPN’s. If the SPN does not match, the session request for that SMB client will be denied.
+ The SMB server will accept and validate the SPN provided by the SMB client and allow a session to be established if it matches the SMB server’s list of SPNs. If the SPN doesn't match, the session request for that SMB client will be denied.
- **Required from client**
- The SMB client must send a SPN name in session setup, and the SPN name provided must match the SMB server that is being requested to establish a connection. If no SPN is provided by the client device, or the SPN provided does not match, the session is denied.
+ The SMB client must send an SPN name in session setup, and the SPN name provided must match the SMB server that is being requested to establish a connection. If no SPN is provided by the client device, or the SPN provided doesn't match, the session is denied.
The default setting is Off.
@@ -78,7 +78,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.
### Policy conflict considerations
@@ -86,7 +86,7 @@ None.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
diff --git a/windows/security/threat-protection/security-policy-settings/minimum-password-age.md b/windows/security/threat-protection/security-policy-settings/minimum-password-age.md
index 960112af64..97ae441bb7 100644
--- a/windows/security/threat-protection/security-policy-settings/minimum-password-age.md
+++ b/windows/security/threat-protection/security-policy-settings/minimum-password-age.md
@@ -35,14 +35,14 @@ The **Minimum password age** policy setting determines the period of time (in da
[Windows security baselines](../windows-security-baselines.md) recommend setting **Minimum password age** to one day.
-Setting the number of days to 0 allows immediate password changes. This setting is not recommended.
+Setting the number of days to 0 allows immediate password changes. This setting isn't recommended.
Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again.
For example, suppose a password is "Ra1ny day!" and the history requirement is 24.
If the minimum password age is 0, the password can be changed 24 times in a row until finally changed back to "Ra1ny day!".
The minimum password age of 1 day prevents that.
If you set a password for a user and you want that user to change the administrator-defined password, you must select the **User must change password at next logon** check box.
-Otherwise, the user will not be able to change the password until the number of days specified by **Minimum password age**.
+Otherwise, the user won't be able to change the password until the number of days specified by **Minimum password age**.
### Location
@@ -67,7 +67,7 @@ This section describes features, tools, and guidance to help you manage this pol
### 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
@@ -75,17 +75,17 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach.
+Users may have favorite passwords that they like to use because they're easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach.
-To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but you do not configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. Configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
+To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users can't reuse any of their last 12 passwords, but you don't configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. Configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
### Countermeasure
-Configure the **Minimum password age** policy setting to a value of 1 day. Users should know about this limitation and contact the Help Desk to change a password sooner. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend.
+Configure the **Minimum password age** policy setting to a value of 1 day. Users should know about this limitation and contact the Help Desk to change a password sooner. If you configure the number of days to 0, immediate password changes would be allowed, which we don't recommend.
### Potential impact
-If you set a password for a user but want that user to change the password when the user first logs on, the administrator must select the **User must change password at next logon** check box, or the user cannot change the password until the next day.
+If you set a password for a user but want that user to change the password when the user first logs on, the administrator must select the **User must change password at next logon** check box, or the user can't change the password until the next day.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/minimum-password-length.md b/windows/security/threat-protection/security-policy-settings/minimum-password-length.md
index d116884fca..79aad414c3 100644
--- a/windows/security/threat-protection/security-policy-settings/minimum-password-length.md
+++ b/windows/security/threat-protection/security-policy-settings/minimum-password-length.md
@@ -38,9 +38,9 @@ The **Minimum password length** policy setting determines the least number of ch
Set Minimum password length to at least a value of 14. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it's long enough to provide adequate security and still short enough for users to easily remember. A minimum password length greater than 14 isn't supported at this time. This value will help provide adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. For more info, see [Password must meet complexity requirements](password-must-meet-complexity-requirements.md).
-Permitting short passwords reduces security because short passwords can be easily broken with tools that do dictionary or brute force attacks against the passwords. Requiring very long passwords can result in mistyped passwords that might cause account lockouts and might increase the volume of Help Desk calls.
+Permitting short passwords reduces security because short passwords can be easily broken with tools that do dictionary or brute force attacks against the passwords. Requiring long passwords can result in mistyped passwords that might cause account lockouts and might increase the volume of Help Desk calls.
-In addition, requiring extremely long passwords can actually decrease the security of an organization because users might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to remember.
+In addition, requiring long passwords can actually decrease the security of an organization because users might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to remember.
### Location
@@ -86,7 +86,7 @@ In most environments, we recommend an eight-character password because it's long
### Potential impact
-Requirements for extremely long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords because of password length requirements, consider teaching your users about passphrases, which are often easier to remember and, because of the larger number of character combinations, much harder to discover.
+Requirements for long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords because of password length requirements, consider teaching your users about passphrases, which are often easier to remember and, because of the larger number of character combinations, much harder to discover.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md b/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md
index b320e305b8..373887c79e 100644
--- a/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md
+++ b/windows/security/threat-protection/security-policy-settings/modify-an-object-label.md
@@ -34,10 +34,10 @@ similar to NTFS file and folder permissions, which are discretionary controls on
- **Untrusted** Default assignment for processes that are logged on anonymously.
- **Low** Default assignment for processes that interact with the Internet.
-- **Medium** Default assignment for standard user accounts and any object that is not explicitly designated with a lower or higher integrity level.
+- **Medium** Default assignment for standard user accounts and any object that isn't explicitly designated with a lower or higher integrity level.
- **High** Default assignment for administrator accounts and processes that request to run using administrative rights.
- **System** Default assignment for Windows kernel and core services.
-- **Installer** Used by setup programs to install software. It is important that only trusted software is installed on computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all other objects.
+- **Installer** Used by setup programs to install software. It's important that only trusted software is installed on computers because objects that are assigned the Installer integrity level can install, modify, and uninstall all other objects.
Constant: SeRelabelPrivilege
@@ -48,7 +48,7 @@ Constant: SeRelabelPrivilege
### Best practices
-- Do not give any group this user right.
+- Don't give any group this user right.
### Location
@@ -73,7 +73,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.
@@ -97,11 +97,11 @@ This section describes how an attacker might exploit a feature or its configurat
Anyone with the **Modify an object label** user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower integrity processes. Either of these states effectively circumvents the protection that is offered by
Windows Integrity Controls and makes your system vulnerable to attacks by malicious software.
-If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator accounts do not have sufficient integrity levels to delete the program from the system. In that case, use of the **Modify an object label** right is mandated so that the object can be relabeled. However, the relabeling must occur by using a process that is at the same or a higher level of integrity than the object that you are attempting to relabel.
+If malicious software is set with an elevated integrity level such as Trusted Installer or System, administrator accounts don't have sufficient integrity levels to delete the program from the system. In that case, use of the **Modify an object label** right is mandated so that the object can be relabeled. However, the relabeling must occur by using a process that is at the same or a higher level of integrity than the object that you're attempting to relabel.
### Countermeasure
-Do not give any group this right. If necessary, implement it for a constrained period of time to a trusted individual to respond to a specific organizational need.
+Don't give any group this right. If necessary, implement it for a constrained period of time to a trusted individual to respond to a specific organizational need.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md b/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md
index 82be9fa1ec..3749e86521 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-allow-anonymous-sidname-translation.md
@@ -37,7 +37,7 @@ Misuse of this policy setting is a common error that can cause data loss or prob
- Enabled
- An anonymous user can request the SID attribute for another user. An anonymous user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name. This setting affects the SID-to-name translation as well as the name-to-SID translation.
+ An anonymous user can request the SID attribute for another user. An anonymous user with knowledge of an administrator's SID could contact a computer that has this policy enabled and use the SID to get the administrator's name. This setting affects the SID-to-name translation and the name-to-SID translation.
- Disabled
@@ -47,7 +47,7 @@ Misuse of this policy setting is a common error that can cause data loss or prob
### Best practices
-- Set this policy to Disabled. This is the default value on member computers; therefore, it will have no impact on them. The default value for domain controllers is Enabled.
+- Set this policy to Disabled, which is the default value on member computers; therefore, it will have no impact on them. The default value for domain controllers is Enabled.
### Location
@@ -79,7 +79,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
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
index aa56038e35..6bad2976ca 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This policy setting determines which additional permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON.
+This policy setting determines which other permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This permission is convenient, for example, when an administrator wants to give access to users in a trusted domain that doesn't maintain a reciprocal trust. However, even with this policy setting enabled, anonymous users will have access to resources with permissions that explicitly include the built-in group, ANONYMOUS LOGON.
This policy setting has no impact on domain controllers.
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
@@ -38,7 +38,7 @@ Misuse of this policy setting is a common error that can cause data loss or prob
- Disabled
- No additional permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions. However, an unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks.
+ No other permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions. However, an unauthorized user could anonymously list account names and use the information to attempt to guess passwords or perform social-engineering attacks.
- Not defined
@@ -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.
### Policy conflicts
@@ -89,7 +89,7 @@ Enable the **Network access: Do not allow anonymous enumeration of SAM accounts
### Potential impact
-It is impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
+It's impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
index 1e144a682f..a6c761b102 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
-This policy setting determines which additional permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to give access to users in a trusted domain that does not maintain a reciprocal trust.
+This policy setting determines which other permissions will be assigned for anonymous connections to the device. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This permission is convenient, for example, when an administrator wants to give access to users in a trusted domain that doesn't maintain a reciprocal trust.
This policy setting has no impact on domain controllers.
@@ -39,7 +39,7 @@ Misuse of this policy setting is a common error that can cause data loss or prob
- Disabled
- No additional permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions.
+ No other permissions can be assigned by the administrator for anonymous connections to the device. Anonymous connections will rely on default permissions.
- Not defined
@@ -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.
### Policy conflicts
@@ -90,7 +90,7 @@ Enable the **Network access: Do not allow anonymous enumeration of SAM accounts*
### Potential impact
-It is impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
+It's impossible to grant access to users of another domain across a one-way trust because administrators in the trusting domain are unable to enumerate lists of accounts in the other domain. Users who access file and print servers anonymously are unable to list the shared network resources on those servers; the users must be authenticated before they can view the lists of shared folders and printers.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
index 160dbb22e8..51152ae5b7 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-storage-of-passwords-and-credentials-for-network-authentication.md
@@ -33,7 +33,7 @@ This security setting determines whether Credential Manager saves passwords and
- Enabled
- Credential Manager does not store passwords and credentials on the device
+ Credential Manager doesn't store passwords and credentials on the device
- Disabled
@@ -43,7 +43,7 @@ This security setting determines whether Credential Manager saves passwords and
### Best practices
-It is a recommended practice to disable the ability of the Windows operating system to cache credentials on any device where credentials are not needed. Evaluate your servers and workstations to determine the requirements. Cached credentials are designed primarily to be used on laptops that require domain credentials when disconnected from the domain.
+It's a recommended practice to disable the ability of the Windows operating system to cache credentials on any device where credentials aren't needed. Evaluate your servers and workstations to determine the requirements. Cached credentials are designed primarily to be used on laptops that require domain credentials when disconnected from the domain.
### Location
@@ -72,7 +72,7 @@ A restart of the device is required before this policy will be effective when ch
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -84,21 +84,21 @@ Passwords that are cached can be accessed by the user when logged on to the devi
>**Note:** The chances of success for this exploit and others that involve malicious software are reduced significantly for organizations that effectively implement and manage an enterprise antivirus solution combined with sensible software restriction policies.
-Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the administrator's password may be overwritten. This procedure requires physical access to the device. Utilities exist that can help overwrite the cached verifier. By using one of these utilities, an attacker can authenticate by using the overwritten value.
+Regardless of what encryption algorithm is used to encrypt the password verifier, a password verifier can be overwritten so that an attacker can authenticate as the user to whom the verifier belongs. Therefore, the administrator's password may be overwritten. This procedure requires physical access to the device. Utilities exist that can help overwrite the cached verifier. With the help of one of these utilities, an attacker can authenticate by using the overwritten value.
-Overwriting the administrator's password does not help the attacker access data that is encrypted by using that password. Also, overwriting the password does not help the attacker access any Encrypting File System (EFS) data that belongs to other users on that device. Overwriting the password does not help an attacker replace the verifier, because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or by using the Data Protection API (DPAPI) will not decrypt.
+Overwriting the administrator's password doesn't help the attacker access data that is encrypted by using that password. Also, overwriting the password doesn't help the attacker access any Encrypting File System (EFS) data that belongs to other users on that device. Overwriting the password doesn't help an attacker replace the verifier, because the base keying material is incorrect. Therefore, data that is encrypted by using Encrypting File System or by using the Data Protection API (DPAPI) won't decrypt.
### Countermeasure
Enable the **Network access: Do not allow storage of passwords and credentials for network authentication** setting.
-To limit the number of cached domain credentials that are stored on the computer, set the **cachedlogonscount** registry entry. By default, the operating system caches the verifier for each unique user's ten most recent valid logons. This value can be set to any value between 0 and 50. By default, all versions of the Windows operating system remember 10 cached logons, except Windows Server 2008 and later, which are set at 25.
+To limit the number of cached domain credentials that are stored on the computer, set the **cachedlogonscount** registry entry. By default, the operating system caches the verifier for each unique user's 10 most recent valid logons. This value can be set to any value between 0 and 50. By default, all versions of the Windows operating system remember 10 cached logons, except Windows Server 2008 and later, which are set at 25.
-When you try to log on to a domain from a Windows-based client device, and a domain controller is unavailable, you do not receive an error message. Therefore, you may not notice that you logged on with cached domain credentials. You can set a notification of logon that uses cached domain credentials with the ReportDC registry entry.
+When you try to sign in to a domain from a Windows-based client device, and a domain controller is unavailable, you don't receive an error message. Therefore, you may not notice that you logged on with cached domain credentials. You can set a notification of a sign in that uses cached domain credentials with the ReportDC registry entry.
### Potential impact
-Users are forced to type passwords whenever they log on to their Microsoft Account or other network resources that are not accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account.
+Users are forced to type passwords whenever they sign in to their Microsoft Account or other network resources that aren't accessible to their domain account. This policy setting should have no impact on users who access network resources that are configured to allow access with their Active Directory–based domain account.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md b/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md
index 542bd046ed..5984f7aa39 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-let-everyone-permissions-apply-to-anonymous-users.md
@@ -27,9 +27,9 @@ Describes the best practices, location, values, policy management and security c
## Reference
-This policy setting determines what additional permissions are granted for anonymous connections to the device. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders and perform certain other activities. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust.
+This policy setting determines what other permissions are granted for anonymous connections to the device. If you enable this policy setting, anonymous users can enumerate the names of domain accounts and shared folders and perform certain other activities. This capability is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust.
-By default, the token that is created for anonymous connections does not include the Everyone SID. Therefore, permissions that are assigned to the Everyone group do not apply to anonymous users.
+By default, the token that is created for anonymous connections doesn't include the Everyone SID. Therefore, permissions that are assigned to the Everyone group don't apply to anonymous users.
### Possible values
@@ -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
@@ -86,7 +86,7 @@ Disable the **Network access: Let Everyone permissions apply to anonymous users*
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md
index 78c22e2c43..ee23e0432c 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-named-pipes-that-can-be-accessed-anonymously.md
@@ -38,7 +38,7 @@ Restricting access over named pipes such as COMNAP and LOCATOR helps prevent una
### Best practices
-- Set this policy to a null value; that is, enable the policy setting, but do not enter named pipes in the text box. This will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function.
+- Set this policy to a null value; that is, enable the policy setting, but don't enter named pipes in the text box. This setting will disable null session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes will no longer function.
### Location
@@ -63,7 +63,7 @@ This section describes different features and tools 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
@@ -90,11 +90,11 @@ You can restrict access over named pipes such as COMNAP and LOCATOR to help prev
### Countermeasure
-Configure the **Network access: Named Pipes that can be accessed anonymously** setting to a null value (enable the setting but do not specify named pipes in the text box).
+Configure the **Network access: Named Pipes that can be accessed anonymously** setting to a null value (enable the setting but don't specify named pipes in the text box).
### Potential impact
-This configuration disables null-session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes no longer function. This may break trust between Windows Server 2003 domains in a mixed mode environment.
+This configuration disables null-session access over named pipes, and applications that rely on this feature or on unauthenticated access to named pipes no longer function. This result may break trust between Windows Server 2003 domains in a mixed mode environment.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md
index 1f5a821007..7a130c03eb 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths-and-subpaths.md
@@ -41,7 +41,7 @@ To allow remote access, you must also enable the Remote Registry service.
### Best practices
-- Set this policy to a null value; that is, enable the policy setting, but do not enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
+- Set this policy to a null value; that is, enable the policy setting, but don't enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
### Location
@@ -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 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
@@ -92,7 +92,7 @@ The registry contains sensitive device configuration information that could be u
### Countermeasure
-Configure the **Network access: Remotely accessible registry paths and sub-paths** setting to a null value (enable the setting but do not enter any paths in the text box).
+Configure the **Network access: Remotely accessible registry paths and sub-paths** setting to a null value (enable the setting but don't enter any paths in the text box).
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md
index fe4a3d425e..746ada8c10 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-remotely-accessible-registry-paths.md
@@ -40,7 +40,7 @@ To allow remote access, you must also enable the Remote Registry service.
### Best practices
-- Set this policy to a null value; that is, enable the policy setting but do not enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
+- Set this policy to a null value; that is, enable the policy setting but don't enter any paths in the text box. Remote management tools, such as the Microsoft Baseline Security Analyzer and Configuration Manager, require remote access to the registry. Removing the default registry paths from the list of accessible paths might cause these and other management tools to fail.
### Location
@@ -71,7 +71,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 @@ An attacker could use information in the registry to facilitate unauthorized act
### Countermeasure
-Configure the **Network access: Remotely accessible registry paths** setting to a null value (enable the setting, but do not enter any paths in the text box).
+Configure the **Network access: Remotely accessible registry paths** setting to a null value (enable the setting, but don't enter any paths in the text box).
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
index 57dc9bbbb8..9bc2a12af5 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-restrict-anonymous-access-to-named-pipes-and-shares.md
@@ -40,7 +40,7 @@ Null sessions are a weakness that can be exploited through the various shared fo
### Best practices
-- Set this policy to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all server pipes and shared folders except those listed in the **NullSessionPipes** and **NullSessionShares** registry entries.
+- Set this policy to Enabled. Enabling this policy setting restricts null session access to unauthenticated users to all server pipes and shared folders except those server pipes and shared folders listed in the **NullSessionPipes** and **NullSessionShares** registry entries.
### 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
@@ -81,7 +81,7 @@ Enable the **Network access: Restrict anonymous access to Named Pipes and Shares
### Potential impact
-You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and shared folders except those that are listed in the NullSessionPipes and NullSessionShares entries.
+You can enable this policy setting to restrict null-session access for unauthenticated users to all server pipes and shared folders except those server pipes and shared folders that are listed in the NullSessionPipes and NullSessionShares entries.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
index 9ffa1041c1..3193b11f86 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-restrict-clients-allowed-to-make-remote-sam-calls.md
@@ -34,7 +34,7 @@ The setting was first supported by Windows 10 version 1607 and Windows Server 20
This topic describes the default values for this security policy setting in different versions of Windows.
By default, computers beginning with Windows 10 version 1607 and Windows Server 2016 are more restrictive than earlier versions of Windows.
-This means that if you have a mix of computers, such as member servers that run both Windows Server 2016 and Windows Server 2012 R2, the servers that run Windows Server 2016 may fail to enumerate accounts by default where the servers that run Windows Server 2012 R2 succeed.
+This restrictive characteristic means that if you have a mix of computers, such as member servers that run both Windows Server 2016 and Windows Server 2012 R2, the servers that run Windows Server 2016 may fail to enumerate accounts by default where the servers that run Windows Server 2012 R2 succeed.
This topic also covers related events, and how to enable audit mode before constraining the security principals that are allowed to remotely enumerate users and groups so that your environment remains secure without impacting application compatibility.
@@ -50,14 +50,14 @@ This information can provide important context and serve as a starting point for
To mitigate this risk, you can configure the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting to force the security accounts manager (SAM) to do an access check against remote calls.
The access check allows or denies remote RPC connections to SAM and Active Directory for users and groups that you define.
-By default, the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting is not defined.
+By default, the **Network access: Restrict clients allowed to make remote calls to SAM** security policy setting isn't defined.
If you define it, you can edit the default Security Descriptor Definition Language (SDDL) string to explicitly allow or deny users and groups to make remote calls to the SAM.
-If the policy setting is left blank after the policy is defined, the policy is not enforced.
+If the policy setting is left blank after the policy is defined, the policy isn't enforced.
The default security descriptor on computers beginning with Windows 10 version 1607 and Windows Server 2016 allows only the local (built-in) Administrators group remote access to SAM on non-domain controllers, and allows Everyone access on domain controllers.
You can edit the default security descriptor to allow or deny other users and groups, including the built-in Administrators.
-The default security descriptor on computers that run earlier versions of Windows does not restrict any remote calls to SAM, but an administrator can edit the security descriptor to enforce restrictions.
+The default security descriptor on computers that run earlier versions of Windows doesn't restrict any remote calls to SAM, but an administrator can edit the security descriptor to enforce restrictions.
This less restrictive default allows for testing the impact of enabling restrictions on existing applications.
## Policy and Registry Names
@@ -72,7 +72,7 @@ This less restrictive default allows for testing the impact of enabling restrict
| **Registry value** | A string that will contain the SDDL of the security descriptor to be deployed. |
The Group Policy setting is only available on computers that run Windows Server 2016 or Windows 10, version 1607 and later.
-This is the only option to configure this setting by using a user interface (UI).
+These computers are the only option to configure this setting by using a user interface (UI).
On computers that run earlier versions of Windows, you need to edit the registry setting directly or use Group Policy Preferences.
To avoid setting it manually in this case, you can configure the GPO itself on a computer that runs Windows Server 2016 or Windows 10, version 1607 or later and have it apply to all computers within the scope of the GPO because the same registry key exists on every computer after the corresponding KB is installed.
@@ -102,7 +102,7 @@ This section explains how to configure audit-only mode, how to analyze related e
### Audit only mode
-Audit only mode configures the SAMRPC protocol to do the access check against the currently configured security descriptor but will not fail the call if the access check fails. Instead, the call will be allowed, but SAMRPC will log an event describing what would have happened if the feature had been enabled. This provides administrators a way to test their applications before enabling the policy in production. Audit only mode is not configured by default. To configure it, add the following registry setting.
+Audit-only mode configures the SAMRPC protocol to do the access check against the currently configured security descriptor but won't fail the call if the access check fails. Instead, the call will be allowed, but SAMRPC will log an event describing what would have happened if the feature had been enabled. This mode provides administrators a way to test their applications before enabling the policy in production. Audit only mode isn't configured by default. To configure it, add the following registry setting.
|Registry|Details|
|---|---|
@@ -110,7 +110,7 @@ Audit only mode configures the SAMRPC protocol to do the access check against th
|Setting|RestrictRemoteSamAuditOnlyMode|
|Data Type|REG_DWORD|
|Value|1|
-|Notes|This setting cannot be added or removed by using predefined Group Policy settings.
Administrators may create a custom policy to set the registry value if needed.
SAM responds dynamically to changes in this registry value without a reboot.
You can use the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script to parse the event logs, as explained in the next section.|
+|Notes|This setting can't be added or removed by using predefined Group Policy settings.
Administrators may create a custom policy to set the registry value if needed.
SAM responds dynamically to changes in this registry value without a reboot.
You can use the [Events 16962 - 16969 Reader](https://gallery.technet.microsoft.com/Events-16962-16969-Reader-2eae5f1d) script to parse the event logs, as explained in the next section.|
### Related events
@@ -130,7 +130,7 @@ There are corresponding events that indicate when remote calls to the SAM are re
|16966|Audit Mode is enabled-
Message Text: "Audit only mode is now enabled for remote calls to the SAM database. SAM will log an event for clients who would have been denied access in normal mode. %n"|Emit event whenever training mode (see 16968) is enabled or disabled.
|16967|Audit Mode is disabled-
Message Text: "Audit only mode is now disabled for remote calls to the SAM database.%n For more information"|Emit event whenever training mode (see 16968) is enabled or disabled.
|16968| Message Text: "Audit only mode is currently enabled for remote calls to the SAM database.%n The following client would have been normally denied access:%nClient SID: %1 from network address: %2. %n"
%1- "Client SID:"
%2- "Client Network Address:"|Emit event when access would have been denied to a remote client, but was allowed through due to training mode being enabled. Event should include identity and network address of the client.|
-|16969|Message Text: "%2 remote calls to the SAM database have been denied in the past %1 seconds throttling window.%n
"%1- "Throttle window:"
%2- "Suppressed Message Count:"| Throttling may be necessary for some events due to expected high volume on some servers causing the event log to wrap.
Note: There is no throttling of events when audit mode is enabled. Environments with a large number of low-privilege and anonymous querying of the remote database may see large numbers of events logged to the System log. For more info, see the [Event Throttling](#event-throttling) section.
+|16969|Message Text: "%2 remote calls to the SAM database have been denied in the past %1-seconds throttling window.%n
"%1- "Throttle window:"
%2- "Suppressed Message Count:"| Throttling may be necessary for some events due to expected high volume on some servers causing the event log to wrap.
Note: There's no throttling of events when audit mode is enabled. Environments with a large number of low-privilege and anonymous querying of the remote database may see large numbers of events logged to the System log. For more info, see the [Event Throttling](#event-throttling) section.
Compare the security context attempting to remotely enumerate accounts with the default security descriptor. Then edit the security descriptor to add accounts that require remote access.
@@ -143,11 +143,11 @@ Setting |RestrictRemoteSamEventThrottlingWindow|
Data Type |DWORD|
|Value|seconds|
|Reboot Required?|No|
-|Notes|**Default** is 900 seconds – 15mins.
The throttling uses a suppressed events counter which starts at 0 and gets incremented during the throttling window.
For example, X events were suppressed in the last 15 minutes.
The counter is restarted after the event 16969 is logged.
+|Notes|**Default** is 900 seconds – 15 mins.
The throttling uses a suppressed events counter that starts at 0 and gets incremented during the throttling window.
For example, X events were suppressed in the last 15 minutes.
The counter is restarted after the event 16969 is logged.
### Restart requirement
-Restarts are not required to enable, disable or modify the **Network access: Restrict clients allowed to make remote calls to SAM security** policy setting, including audit only mode. Changes become effective without a device restart when they are saved locally or distributed through Group Policy.
+Restarts aren't required to enable, disable or modify the **Network access: Restrict clients allowed to make remote calls to SAM security** policy setting, including audit only mode. Changes become effective without a device restart when they're saved locally or distributed through Group Policy.
## Security considerations
@@ -158,7 +158,7 @@ The SAMRPC protocol has a default security posture that makes it possible for lo
The following example illustrates how an attacker might exploit remote SAM enumeration:
1. A low-privileged attacker gains a foothold on a network.
2. The attacker then queries all machines on the network to determine which ones have a highly privileged domain user configured as a local administrator on that machine.
-3. If the attacker can then find any other vulnerability on that machine that allows taking it over, the attacker can then squat on the machine waiting for the high-privileged user to logon and then steal or impersonate those credentials.
+3. If the attacker can, then find any other vulnerability on that machine that allows taking it over, the attacker can then squat on the machine waiting for the high-privileged user to sign in and then steal or impersonate those credentials.
### Countermeasure
You can mitigate this vulnerability by enabling the **Network access: Restrict clients allowed to make remote calls** to SAM security policy setting and configuring the SDDL for only those accounts that are explicitly allowed access.
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md b/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md
index 0e8c62d1a3..8886a5ba0a 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously.md
@@ -36,7 +36,7 @@ This policy setting determines which shared folders can be accessed by anonymous
### Best practices
-- Set this policy to a null value. There should be little impact because this is the default value. All users will have to be authenticated before they can access shared resources on the server.
+- Set this policy to a null value. There should be little impact because this null value is the default one. All users will have to be authenticated before they can access shared resources on the server.
### Location
@@ -61,7 +61,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
@@ -77,7 +77,7 @@ Configure the **Network access: Shares that can be accessed anonymously** settin
### Potential impact
-There should be little impact because this is the default configuration. Only authenticated users have access to shared resources on the server.
+There should be little impact because this state is the default configuration. Only authenticated users have access to shared resources on the server.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md b/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md
index f4a400c044..c13b8ecea9 100644
--- a/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md
+++ b/windows/security/threat-protection/security-policy-settings/network-access-sharing-and-security-model-for-local-accounts.md
@@ -32,7 +32,7 @@ This policy setting determines how network logons that use local accounts are au
>**Note:** This policy setting does not affect network logons that use domain accounts. Nor does this policy setting affect interactive logons that are performed remotely through services such as Telnet or Remote Desktop Services.
When the device is not joined to a domain, this policy setting also tailors the **Sharing** and **Security** tabs in Windows Explorer to correspond to the sharing and security model that is being used.
-When the value of this policy setting is **Guest only - local users authenticate as Guest**, any user who can access your device over the network does so with Guest user rights. This means that they will probably be unable to write to shared folders. Although this does increase security, it makes it impossible for authorized users to access shared resources on those systems. When the value is **Classic - local users authenticate as themselves**, local accounts must be password-protected; otherwise, anyone can use those user accounts to access shared system resources.
+When the value of this policy setting is **Guest only - local users authenticate as Guest**, any user who can access your device over the network does so with Guest user rights. This privilege means that they'll probably be unable to write to shared folders. Although this restriction does increase security, it makes it impossible for authorized users to access shared resources on those systems. When the value is **Classic - local users authenticate as themselves**, local accounts must be password-protected; otherwise, anyone can use those user accounts to access shared system resources.
### Possible values
@@ -68,11 +68,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
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -80,7 +80,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-With the Guest only model, any user who can authenticate to your device over the network does so with Guest privileges, which probably means that they do not have Write access to shared resources on that device. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources.
+With the Guest only model, any user who can authenticate to your device over the network does so with Guest privileges, which probably means that they don't have Write access to shared resources on that device. Although this restriction does increase security, it makes it more difficult for authorized users to access shared resources on those computers because ACLs on those resources must include access control entries (ACEs) for the Guest account. With the Classic model, local accounts should be password protected. Otherwise, if Guest access is enabled, anyone can use those user accounts to access shared system resources.
### Countermeasure
@@ -88,7 +88,7 @@ For network servers, configure the **Network access: Sharing and security model
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
index 261dd0a213..2b7a73365a 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-local-system-to-use-computer-identity-for-ntlm.md
@@ -35,9 +35,9 @@ When a service connects with the device identity, signing and encryption are sup
| Setting | Windows Server 2008 and Windows Vista | At least Windows Server 2008 R2 and Windows 7 |
| - | - | - |
-| Enabled | Services running as Local System that use Negotiate will use the computer identity. This value might cause some authentication requests between Windows operating systems to fail and log an error.| Services running as Local System that use Negotiate will use the computer identity. This is the default behavior. |
-| Disabled| Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. This is the default behavior.| Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously.|
-|Neither|Services running as Local System that use Negotiate when reverting to NTLM authentication will authenticate anonymously. | Services running as Local System that use Negotiate will use the computer identity. This might cause some authentication requests between Windows operating systems to fail and log an error.|
+| Enabled | Services running as Local System that use Negotiate will use the computer identity. This value might cause some authentication requests between Windows operating systems to fail and log an error.| Services running as Local System that use Negotiate will use the computer identity. This behavior is the default behavior. |
+| Disabled| Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously. This behavior is the default behavior.| Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously.|
+|Neither|Services running as Local System that uses Negotiate when reverting to NTLM authentication will authenticate anonymously. | Services running as Local System that uses Negotiate will use the computer identity. This behavior might cause some authentication requests between Windows operating systems to fail and log an error.|
### Location
@@ -61,17 +61,17 @@ 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.
### Policy conflict considerations
-The policy [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md), if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. This will increase the success of interoperability at the expense of security.
+The policy [Network security: Allow LocalSystem NULL session fallback](network-security-allow-localsystem-null-session-fallback.md), if enabled, will allow NTLM or Kerberos authentication to be used when a system service attempts authentication. This privilege will increase the success of interoperability at the expense of security.
The anonymous authentication behavior is different for Windows Server 2008 and Windows Vista than later versions of Windows. Configuring and applying this policy setting on those systems might not produce the same results.
### Group Policy
-This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
+This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@@ -89,7 +89,7 @@ You can configure the **Network security: Allow Local System to use computer ide
### Potential impact
-If you do not configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local System that use the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008.
+If you don't configure this policy setting on Windows Server 2008 and Windows Vista, services running as Local System that uses the default credentials will use the NULL session and revert to NTLM authentication for Windows operating systems earlier than Windows Vista or Windows Server 2008.
Beginning with Windows Server 2008 R2 and Windows 7, the system allows Local System services that use Negotiate to use the computer identity when reverting to NTLM authentication.
## Related articles
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md
index 401a588948..271d990f14 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-localsystem-null-session-fallback.md
@@ -28,7 +28,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
This policy affects session security during the authentication process between devices running Windows Server 2008 R2 and Windows 7 and later and those devices running earlier versions of the Windows operating system. For computers running Windows Server 2008 R2 and Windows 7 and later, services running as Local System require a service principal name (SPN) to generate the session key. However, if [Network security: Allow Local System to use computer identity for NTLM](network-security-allow-local-system-to-use-computer-identity-for-ntlm.md) is set to disabled, services running as Local
-System will fall back to using NULL session authentication when they transmit data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session does not establish a unique session key for each authentication; and thus, it cannot provide integrity or confidentiality protection. The setting **Network security: Allow LocalSystem NULL session fallback** determines whether services that request the use of session security are allowed to perform signature or encryption functions with a well-known key for application compatibility.
+System will fall back to using NULL session authentication when they transmit data to servers running versions of Windows earlier than Windows Vista or Windows Server 2008. NULL session doesn't establish a unique session key for each authentication; and thus, it can't provide integrity or confidentiality protection. The setting **Network security: Allow LocalSystem NULL session fallback** determines whether services that request the use of session security are allowed to perform signature or encryption functions with a well-known key for application compatibility.
### Possible values
@@ -41,13 +41,13 @@ System will fall back to using NULL session authentication when they transmit da
When a service running as Local System connects with a NULL session, session security will be unavailable. Calls seeking encryption or signing will fail. This setting is more secure, but at the risk of degrading application incompatibility. Calls that are using the device identity instead of a
NULL session will still have full use of session security.
-- Not defined. When this policy is not defined, the default takes effect. This is Enabled for versions of the Windows operating system earlier than Windows Server 2008 R2 and Windows 7, and it is Disabled otherwise.
+- Not defined. When this policy isn't defined, the default takes effect. This policy is Enabled for versions of the Windows operating system earlier than Windows Server 2008 R2 and Windows 7, and it's Disabled otherwise.
### Best practices
-When services connect with the device identity, signing and encryption are supported to provide data protection. When services connect with a NULL session, this level of data protection is not provided. However, you will need to evaluate your environment to determine the Windows operating system versions that you support. If this policy is enabled, some services may not be able to authenticate.
+When services connect with the device identity, signing and encryption are supported to provide data protection. When services connect with a NULL session, this level of data protection isn't provided. However, you'll need to evaluate your environment to determine the Windows operating system versions that you support. If this policy is enabled, some services may not be able to authenticate.
-This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer requires support for Windows NT 4, this policy should be disabled. By default, it is disabled in Windows 7 and Windows Server 2008 R2 and later.
+This policy applies to Windows Server 2008 and Windows Vista (SP1 and later). When your environment no longer requires support for Windows NT 4, this policy should be disabled. By default, it's disabled in Windows 7 and Windows Server 2008 R2 and later.
### Location
@@ -74,11 +74,11 @@ If this setting is Enabled, when a service connects with a NULL session, a syste
### Countermeasure
-You can configure the computer to use the computer identity for Local System with the policy **Network security: Allow Local System to use computer identity for NTLM**. If that is not possible, this policy can be used to prevent data from being exposed in transit if it was protected with a well-known key.
+You can configure the computer to use the computer identity for Local System with the policy **Network security: Allow Local System to use computer identity for NTLM**. If that isn't possible, this policy can be used to prevent data from being exposed in transit if it was protected with a well-known key.
### Potential impact
-If you enable this policy, services that use NULL session with Local System could fail to authenticate because they will be prohibited from using signing and encryption.
+If you enable this policy, services that use NULL session with Local System could fail to authenticate because they'll be prohibited from using signing and encryption.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
index 1c229713a8..093d8db29f 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-allow-pku2u-authentication-requests-to-this-computer-to-use-online-identities.md
@@ -27,18 +27,18 @@ This article describes the best practices, location, and values for the **Networ
## Reference
-Starting with Windows Server 2008 R2 and Windows 7, the Negotiate Security Support Provider (SSP) supports an extension SSP, Negoexts.dll. This extension SSP is treated as an authentication protocol by the Windows operating system. It supports SSPs from Microsoft, including PKU2U. You can also develop or add other SSPs.
+From Windows Server 2008 R2 and Windows 7, the Negotiate Security Support Provider (SSP) supports an extension SSP, Negoexts.dll. This extension SSP is treated as an authentication protocol by the Windows operating system. It supports SSPs from Microsoft, including PKU2U. You can also develop or add other SSPs.
-When devices are configured to accept authentication requests by using online IDs, Negoexts.dll calls the PKU2U SSP on the computer that's used to log on. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When it's validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation. It associates the user's certificate to a security token, and then the logon process completes.
+When devices are configured to accept authentication requests by using online IDs, Negoexts.dll calls the PKU2U SSP on the computer that's used to sign in. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer computers. When it's validated on the peer computer, the certificate within the metadata is sent to the sign-in peer for validation. It associates the user's certificate to a security token, and then the sign-in process completes.
> [!NOTE]
> Linking online IDs can be performed by anyone who has an account that has standard user’s credentials through Credential Manager.
-This policy isn't configured by default on domain-joined devices. This would disallow the online identities to authenticate to domain-joined computers from Windows 7 up to Windows 10, Version 1607. This policy is enabled by default in Windows 10, Version 1607, and later.
+This policy isn't configured by default on domain-joined devices. This disablement would disallow the online identities to authenticate to domain-joined computers from Windows 7 up to Windows 10, Version 1607. This policy is enabled by default in Windows 10, Version 1607, and later.
### Possible values
-- **Enabled**: This setting allows authentication to successfully complete between the two (or more) computers that have established a peer relationship through the use of online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer devices. When validated on the peer computer, the certificate within the metadata is sent to the logon peer for validation. It associates the user's certificate to a security token, and then the logon process completes.
+- **Enabled**: This setting allows authentication to successfully complete between the two (or more) computers that have established a peer relationship by using online IDs. The PKU2U SSP obtains a local certificate and exchanges the policy between the peer devices. When validated on the peer computer, the certificate within the metadata is sent to the sign-in peer for validation. It associates the user's certificate to a security token, and then the sign-in process completes.
> [!NOTE]
> PKU2U is disabled by default on Windows Server. If PKU2U is disabled, Remote Desktop connections from a hybrid Azure AD-joined server to an Azure AD-joined Windows 10 device or a Hybrid Azure AD-joined domain member Windows 10 device fail. To resolve this, enable PKU2U on the server and the client.
@@ -75,7 +75,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or an Azure AD account. That account can then log on to a peer device (if the peer device is likewise configured) without the use of a Windows logon account (domain or local). This setup is not only beneficial, but required for Azure AD-joined devices, where they are signed in with an online identity and are issued certificates by Azure AD. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it does not pose any threats in a hybrid environment where Azure AD is used as it relies on the user's online identity and Azure AD to authenticate.
+Enabling this policy setting allows a user’s account on one computer to be associated with an online identity, such as Microsoft account or an Azure AD account. That account can then sign in to a peer device (if the peer device is likewise configured) without the use of a Windows sign-in account (domain or local). This setup isn't only beneficial, but required for Azure AD-joined devices, where they're signed in with an online identity and are issued certificates by Azure AD. This policy may not be relevant for an *on-premises only* environment and might circumvent established security policies. However, it doesn't pose any threats in a hybrid environment where Azure AD is used as it relies on the user's online identity and Azure AD to authenticate.
### Countermeasure
@@ -83,9 +83,9 @@ Set this policy to *Disabled* or don't configure this security policy for *on-pr
### Potential impact
-If you don't set or you disable this policy, the PKU2U protocol won't be used to authenticate between peer devices, which forces users to follow domain-defined access control policies. This is a valid configuration in *on-premises only* environments. Please be aware that some roles/features (such as Failover Clustering) do not utilize a domain account for its PKU2U authentication and will cease to function properly when disabling this policy.
+If you don't set or you disable this policy, the PKU2U protocol won't be used to authenticate between peer devices, which forces users to follow domain-defined access control policies. This disablement is a valid configuration in *on-premises only* environments. Some roles/features (such as Failover Clustering) don't utilize a domain account for its PKU2U authentication and will cease to function properly when disabling this policy.
-If you enable this policy in a hybrid environment, you allow your users to authenticate by using certificates issued by Azure AD and their online identity between the corresponding devices. This configuration allows users to share resources between such devices. Without enabling this policy, remote connections to an Azure AD joined device will not work.
+If you enable this policy in a hybrid environment, you allow your users to authenticate by using certificates issued by Azure AD and their online identity between the corresponding devices. This configuration allows users to share resources between such devices. If this policy isn't enabled, remote connections to an Azure AD joined device won't work.
### Fix/Remediation
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md b/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md
index bcaef6d811..afe9be35da 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos.md
@@ -37,11 +37,11 @@ The following table lists and explains the allowed encryption types.
| Encryption type | Description and version support |
| - | - |
| DES_CBC_CRC | Data Encryption Standard with Cipher Block Chaining using the Cyclic Redundancy Check function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows Server 2008 R2, and later operating systems don't support DES by default. |
-| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows Server 2008 R2, and later operating systems do not support DES by default. |
+| DES_CBC_MD5| Data Encryption Standard with Cipher Block Chaining using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. The Windows 7, Windows 10, Windows Server 2008 R2, and later operating systems don't support DES by default. |
| RC4_HMAC_MD5| Rivest Cipher 4 with Hashed Message Authentication Code using the Message-Digest algorithm 5 checksum function
Supported in Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012 and Windows Server 2012 R2.|
| AES128_HMAC_SHA1| Advanced Encryption Standard in 128-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. |
| AES256_HMAC_SHA1| Advanced Encryption Standard in 256-bit cipher block with Hashed Message Authentication Code using the Secure Hash Algorithm (1).
Not supported in Windows 2000 Server, Windows XP, or Windows Server 2003. Supported in Windows Vista, Windows Server 2008, Windows 7, Windows 10, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. |
-| Future encryption types| Reserved by Microsoft for additional encryption types that might be implemented.|
+| Future encryption types| Reserved by Microsoft for other encryption types that might be implemented.|
### Possible values
@@ -55,7 +55,7 @@ The encryption type options include:
- AES256\_HMAC\_SHA1
- Future encryption types
- As of the release of Windows 7 and Windows Server 2008 R2, this is reserved by Microsoft for additional encryption types that might be implemented.
+ As of the release of Windows 7 and Windows Server 2008 R2, these options are reserved by Microsoft for other encryption types that might be implemented.
### Best practices
@@ -72,9 +72,9 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
| Default domain policy| Not defined|
| Default domain controller policy| Not defined|
| Stand-alone server default settings | Not defined|
-| Domain controller effective default settings | The default OS setting applies, DES suites are not supported by default.|
-| Member server effective default settings | The default OS setting applies, DES suites are not supported by default.|
-| Effective GPO default settings on client computers | The default OS setting applies, DES suites are not supported by default.|
+| Domain controller effective default settings | The default OS setting applies, DES suites aren't supported by default.|
+| Member server effective default settings | The default OS setting applies, DES suites aren't supported by default.|
+| Effective GPO default settings on client computers | The default OS setting applies, DES suites aren't supported by default.|
## Security considerations
@@ -87,14 +87,14 @@ Windows Server 2008 R2, Windows 7 and Windows 10. You can also disable DES fo
### Countermeasure
-Do not configure this policy. This will force the computers running Windows Server 2008 R2, Windows 7, and Windows 10 to use the AES or RC4 cryptographic suites.
+Don't configure this policy. This disablement will force the computers running Windows Server 2008 R2, Windows 7, and Windows 10 to use the AES or RC4 cryptographic suites.
### Potential impact
If you don't select any of the encryption types, computers running Windows Server 2008 R2, Windows 7 and Windows 10, might have Kerberos authentication failures when connecting with computers running non-Windows versions of the Kerberos protocol.
-If you do select any encryption type, you will lower the effectiveness of encryption for Kerberos authentication but you will improve interoperability with computers running older versions of Windows.
+If you do select any encryption type, you'll lower the effectiveness of encryption for Kerberos authentication but you'll improve interoperability with computers running older versions of Windows.
Contemporary non-Windows implementations of the Kerberos protocol support RC4 and AES 128-bit and AES 256-bit encryption. Most implementations, including the MIT Kerberos protocol and the Windows Kerberos protocol, are deprecating DES encryption.
## Related articles
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md b/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
index ebf155ba56..e0ecaddc05 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-do-not-store-lan-manager-hash-value-on-next-password-change.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management and security c
This policy setting determines whether LAN Manager is prevented from storing hash values for the new password the next time the password is changed. Hash values are a representation of the password after the encryption algorithm is applied that corresponds to the format that is specified by the algorithm. To decrypt the hash value, the encryption algorithm must be determined and then reversed. The LAN Manager hash is relatively weak and prone to attack compared to the cryptographically stronger NTLM hash. Because the LM hash is stored on the local device in the security database, the passwords can be compromised if the security database, Security Accounts Manager (SAM), is attacked.
-By attacking the SAM file, attackers can potentially gain access to user names and password hashes. Attackers can use a password-cracking tool to determine what the password is. After they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this policy setting will not prevent these types of attacks, but it will make them much more difficult.
+When the attackers attack the SAM file, they can potentially gain access to user names and password hashes. Attackers can use a password-cracking tool to determine what the password is. After they have access to this information, they can use it to gain access to resources on your network by impersonating users. Enabling this policy setting won't prevent these types of attacks, but it will make them much more difficult.
### Possible values
@@ -40,7 +40,7 @@ By attacking the SAM file, attackers can potentially gain access to user names a
### Best practices
- Set **Network security: Do not store LAN Manager hash value on next password change** to **Enabled**.
- - Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are removed.
+ - Require all users to set new passwords the next time they sign in to the domain so that LAN Manager hashes are removed.
### 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
@@ -73,11 +73,11 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The SAM file can be targeted by attackers who seek access to user names and password hashes. Such attacks use special tools to discover passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks are not prevented by enabling this policy setting because LAN Manager hashes are much weaker than NTLM hashes, but it is much more difficult for these attacks to succeed.
+The SAM file can be targeted by attackers who seek access to user names and password hashes. Such attacks use special tools to discover passwords, which can then be used to impersonate users and gain access to resources on your network. These types of attacks aren't prevented by enabling this policy setting because LAN Manager hashes are much weaker than NTLM hashes, but it's much more difficult for these attacks to succeed.
### Countermeasure
-Enable the **Network security: Do not store LAN Manager hash value on next password change** setting. Require all users to set new passwords the next time they log on to the domain so that LAN Manager hashes are removed.
+Enable the **Network security: Do not store LAN Manager hash value on next password change** setting. Require all users to set new passwords the next time they sign in to the domain so that LAN Manager hashes are removed.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md b/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md
index daab389419..3bc3ec584c 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-force-logoff-when-logon-hours-expire.md
@@ -27,25 +27,25 @@ Describes the best practices, location, values, policy management, and security
## Reference
-This security setting determines whether to disconnect users who are connected to the local device outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component.
+This security setting determines whether to disconnect users who are connected to the local device outside their user account's valid sign-in hours. This setting affects the Server Message Block (SMB) component.
-This policy setting does not apply to administrator accounts, but it behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy Object (GPO), even if there is a different account policy that is applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member devices) also receive the same account policy for their local accounts. However, local account policies for member devices can be different from the domain account policy by defining an account policy for the organizational unit that contains the member devices. Kerberos settings are not applied to member devices.
+This policy setting doesn't apply to administrator accounts, but it behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it's enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy Object (GPO), even if there's a different account policy that is applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member devices) also receive the same account policy for their local accounts. However, local account policies for member devices can be different from the domain account policy by defining an account policy for the organizational unit that contains the member devices. Kerberos settings aren't applied to member devices.
### Possible values
- Enabled
- When enabled, this policy causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.
+ When enabled, this policy causes client sessions with the SMB server to be forcibly disconnected when the client's sign-in hours expire.
- Disabled
- When disabled, this policy allows for the continuation of an established client session after the client's logon hours have expired.
+ When disabled, this policy allows for the continuation of an established client session after the client's sign-in hours have expired.
- Not defined
### Best practices
-- Set **Network security: Force logoff when logon hours expire** to Enabled. SMB sessions will be terminated on member servers when a user's logon time expires, and the user will be unable to log on to the system until their next scheduled access time begins.
+- Set **Network security: Force logoff when logon hours expire** to Enabled. SMB sessions will be terminated on member servers when a user's sign-in time expires, and the user will be unable to sign in to the system until their next scheduled access time begins.
### 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,15 +78,15 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-If you disable this policy setting, users can remain connected to the computer outside of their allotted logon hours.
+If you disable this policy setting, users can remain connected to the computer outside of their allotted sign-in hours.
### Countermeasure
-Enable the **Network security: Force logoff when logon hours expire** setting. This policy setting does not apply to administrator accounts.
+Enable the **Network security: Force logoff when logon hours expire** setting. This policy setting doesn't apply to administrator accounts.
### Potential impact
-When a user's logon time expires, SMB sessions terminate. The user cannot log on to the device until the next scheduled access time commences.
+When a user's sign-in time expires, SMB sessions terminate. The user can't sign in to the device until the next scheduled access time commences.
## Related articles
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md b/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md
index fcd510671f..1841669403 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level.md
@@ -27,15 +27,15 @@ Describes the best practices, location, values, policy management and security c
## Reference
-This policy setting determines which challenge or response authentication protocol is used for network logons. LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal devices together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol is not negotiated for some reason, Active Directory uses LM, NTLM, or NTLM version 2 (NTLMv2).
+This policy setting determines which challenge or response authentication protocol is used for network logons. LAN Manager (LM) includes client computer and server software from Microsoft that allows users to link personal devices together on a single network. Network capabilities include transparent file and print sharing, user security features, and network administration tools. In Active Directory domains, the Kerberos protocol is the default authentication protocol. However, if the Kerberos protocol isn't negotiated for some reason, Active Directory uses LM, NTLM, or NTLM version 2 (NTLMv2).
-LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it is the protocol that is used to authenticate all client devices running the Windows operating system when they perform the following operations:
+LAN Manager authentication includes the LM, NTLM, and NTLMv2 variants, and it's the protocol that is used to authenticate all client devices running the Windows operating system when they perform the following operations:
- Join a domain
- Authenticate between Active Directory forests
- Authenticate to domains based on earlier versions of the Windows operating system
-- Authenticate to computers that do not run Windows operating systems, beginning with Windows 2000
-- Authenticate to computers that are not in the domain
+- Authenticate to computers that don't run Windows operating systems, beginning with Windows 2000
+- Authenticate to computers that aren't in the domain
### Possible values
@@ -56,8 +56,8 @@ authentication level that servers accept. The following table identifies the pol
| Send LM & NTLM – use NTLMv2 session security if negotiated | Client devices use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 1|
| Send NTLM response only| Client devices use NTLMv1 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 2|
| Send NTLMv2 response only | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers accept LM, NTLM, and NTLMv2 authentication.| 3|
-| Send NTLMv2 response only. Refuse LM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they will accept only NTLM and NTLMv2 authentication.| 4|
-| Send NTLMv2 response only. Refuse LM & NTLM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they will accept only NTLMv2 authentication.| 5|
+| Send NTLMv2 response only. Refuse LM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM authentication, and they'll accept only NTLM and NTLMv2 authentication.| 4|
+| Send NTLMv2 response only. Refuse LM & NTLM | Client devices use NTLMv2 authentication, and they use NTLMv2 session security if the server supports it. Domain controllers refuse to accept LM and NTLM authentication, and they'll accept only NTLMv2 authentication.| 5|
### Best practices
@@ -90,7 +90,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
@@ -106,11 +106,11 @@ In Windows 7 and Windows Vista, this setting is undefined. In Windows Server
### Countermeasure
-Configure the **Network security: LAN Manager Authentication Level** setting to **Send NTLMv2 responses only**. Microsoft and a number of independent organizations strongly recommend this level of authentication when all client computers support NTLMv2.
+Configure the **Network security: LAN Manager Authentication Level** setting to **Send NTLMv2 responses only**. Microsoft and many independent organizations strongly recommend this level of authentication when all client computers support NTLMv2.
### Potential impact
-Client devices that do not support NTLMv2 authentication cannot authenticate in the domain and access domain resources by using LM and NTLM.
+Client devices that don't support NTLMv2 authentication can't authenticate in the domain and access domain resources by using LM and NTLM.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md b/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md
index 006e925460..1f59bd9111 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements.md
@@ -30,8 +30,8 @@ This security policy reference topic for the IT professional describes the best
This policy setting determines the level of data signing that is requested on behalf of client devices that issue LDAP BIND requests. The levels of data signing are described in the following list:
- **None**. The LDAP BIND request is issued with the caller-specified options.
-- **Negotiate signing**. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) has not been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
-- **Require signing**. This level is the same as **Negotiate signing**. However, if the LDAP server's intermediate saslBindInProgress response does not indicate that LDAP traffic signing is required, the caller is returned a message that the LDAP BIND command request failed.
+- **Negotiate signing**. If Transport Layer Security/Secure Sockets Layer (TLS/SSL) hasn't been started, the LDAP BIND request is initiated with the LDAP data signing option set in addition to the caller-specified options. If TLS/SSL has been started, the LDAP BIND request is initiated with the caller-specified options.
+- **Require signing**. This level is the same as **Negotiate signing**. However, if the LDAP server's intermediate saslBindInProgress response doesn't indicate that LDAP traffic signing is required, the caller is returned a message that the LDAP BIND command request failed.
Misuse of this policy setting is a common error that can cause data loss or problems with data access or security.
@@ -44,7 +44,7 @@ Misuse of this policy setting is a common error that can cause data loss or prob
### Best practices
-- Set both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings to **Require signing**. To avoid usage of unsigned traffic, set both client and server sides to require signing. Not setting one of the sides will prevent client computers from communicating with the server. This can cause many features to fail, including user authentication, Group Policy, and logon scripts.
+- Set both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings to **Require signing**. To avoid usage of unsigned traffic, set both client and server sides to require signing. Not setting one of the sides will prevent client computers from communicating with the server. This prevention can cause many features to fail, including user authentication, Group Policy, and logon scripts.
### 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.
### Group Policy
@@ -81,7 +81,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 which an intruder captures the packets between the client computer and server, modifies them, and then forwards them to the server. For an LDAP server, this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered data from the LDAP queries. To lower this risk in your network, you can implement strong physical security measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks extremely difficult if you require digital signatures on all network packets by means of IPsec authentication headers.
+Unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures the packets between the client computer and server, modifies them, and then forwards them to the server. For an LDAP server, this susceptibility means that an attacker could cause a server to make decisions that are based on false or altered data from the LDAP queries. To lower this risk in your network, you can implement strong physical security measures to protect the network infrastructure. Also, you can make all types of man-in-the-middle attacks difficult if you require digital signatures on all network packets throughs IPsec authentication headers.
### Countermeasure
@@ -89,7 +89,7 @@ Configure the **Network security: LDAP client signing requirements** setting to
### Potential impact
-If you configure the client to require LDAP signatures, it may fail to communicate with the LDAP servers that do not require requests to be signed. To avoid this issue, make sure that both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings are set to **Require signing**.
+If you configure the client to require LDAP signatures, it may fail to communicate with the LDAP servers that don't require requests to be signed. To avoid this issue, make sure that both the **Network security: LDAP client signing requirements** and **Domain controller: LDAP server signing requirements** settings are set to **Require signing**.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
index d606dc935b..026f314358 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-minimum-session-security-for-ntlm-ssp-based-including-secure-rpc-servers.md
@@ -33,13 +33,13 @@ Setting all of these values for this policy setting will help protect network tr
### Possible values
-- Require 128-bit encryption. The connection fails if strong encryption (128-bit) is not negotiated.
-- Require NTLMv2 session security. The connection fails if the NTLMv2 protocol is not negotiated.
+- Require 128-bit encryption. The connection fails if strong encryption (128-bit) isn't negotiated.
+- Require NTLMv2 session security. The connection fails if the NTLMv2 protocol isn't negotiated.
- Not Defined.
### Best practices
-- Enable all values that are available for this security policy. Legacy client devices that do not support these policy settings will be unable to communicate with the server.
+- Enable all values that are available for this security policy. Legacy client devices that don't support these policy settings will be unable to communicate with the server.
### Location
@@ -64,7 +64,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.
### Policy dependencies
@@ -84,7 +84,7 @@ Enable all options that are available for the **Network security: Minimum sessio
### Potential impact
-Older client devices that do not support these security settings cannot communicate with the computer on which this policy is set.
+Older client devices that don't support these security settings can't communicate with the computer on which this policy is set.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
index bf5804a540..828f91f36b 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md
@@ -31,7 +31,7 @@ The **Network security: Restrict NTLM: Add remote server exceptions for NTLM aut
If you configure this policy setting, you can define a list of remote servers to which client devices are allowed to use NTLM authentication.
-If you do not configure this policy setting, no exceptions will be applied, and if [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, NTLM authentication attempts from the client devices will fail.
+If you don't configure this policy setting, no exceptions will be applied, and if [Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, NTLM authentication attempts from the client devices will fail.
List the NetBIOS server names that are used by the applications as the naming format, one per line. To ensure exceptions, the names that are used by all applications need to be in the list. A single asterisk (\*) can be used anywhere in the string as a wildcard character.
@@ -43,7 +43,7 @@ List the NetBIOS server names that are used by the applications as the naming fo
- Not defined
- If you do not configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
+ If you don't configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
### Best practices
@@ -72,7 +72,7 @@ This section describes the features and tools that are available to help you man
### 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
@@ -90,7 +90,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-When it has been determined that the NTLM authentication protocol should not be used from a client device to any remote servers because you are required to use a more secure protocol such as Kerberos, there might be some client applications that still use NTLM. If so, and you set [Network Security:
+When it has been determined that the NTLM authentication protocol shouldn't be used from a client device to any remote servers because you're required to use a more secure protocol such as Kerberos, there might be some client applications that still use NTLM. If so, and you set [Network Security:
Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) to any of the deny options, those applications will fail because the outbound NTLM authentication traffic from the client computer will be blocked.
If you define an exception list of servers to which client devices are allowed to use NTLM authentication, then NTLM authentication traffic will continue to flow between those client applications and servers. The servers then are vulnerable to any malicious attack that takes advantage of security weaknesses in NTLM.
@@ -98,13 +98,13 @@ If you define an exception list of servers to which client devices are allowed t
### Countermeasure
When you use [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the remote
-servers in your environment. When assessed, you will have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, the client application has to be upgraded to use something other than NTLM authentication.
+servers in your environment. When assessed, you'll have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements. If not, the client application has to be upgraded to use something other than NTLM authentication.
### Potential impact
-Defining a list of servers for this policy setting will enable NTLM authentication traffic from the client application that uses those servers, and this might result in a security vulnerability.
+Defining a list of servers for this policy setting will enable NTLM authentication traffic from the client application that uses those servers, and this traffic might result in a security vulnerability.
-If this list is not defined and [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, then client applications that use NTLM will fail to authenticate to those servers that they have previously used.
+If this list isn't defined and [Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers](network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md) is enabled, then client applications that use NTLM will fail to authenticate to those servers that they've previously used.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
index 5fb535995e..41ca2e0bee 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-add-server-exceptions-in-this-domain.md
@@ -27,11 +27,11 @@ Describes the best practices, location, values, management aspects, and security
## Reference
-The **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting allows you to create an exception list of servers in this domain to which client device are allowed to use NTLM pass-through authentication if any of the deny options are set in the [Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) policy setting.
+The **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting allows you to create an exception list of servers in this domain to which client devices are allowed to use NTLM pass-through authentication if any of the deny options are set in the [Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) policy setting.
If you configure this policy setting, you can define a list of servers in this domain to which client devices are allowed to use NTLM authentication.
-If you do not configure this policy setting, no exceptions will be applied, and if **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, all NTLM authentication attempts in the domain will fail.
+If you don't configure this policy setting, no exceptions will be applied, and if **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, all NTLM authentication attempts in the domain will fail.
List the NetBIOS server names as the naming format, one per line. A single asterisk (\*) can be used anywhere in the string as a wildcard character.
@@ -43,7 +43,7 @@ List the NetBIOS server names as the naming format, one per line. A single aster
- Not defined
- If you do not configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
+ If you don't configure this policy setting by defining a list of servers, the policy is undefined and no exceptions will be applied.
### Best practices
@@ -89,7 +89,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-When it has been determined that the NTLM authentication protocol should not be used within a domain because you are required to use a more secure protocol such as Kerberos, there might be some NTLM authentication traffic that is still present in the domain. If so, and you set Network Security:
+When it has been determined that the NTLM authentication protocol shouldn't be used within a domain because you're required to use a more secure protocol such as Kerberos, there might be some NTLM authentication traffic that is still present in the domain. If so, and you set Network Security:
[Network Security: Restrict NTLM: NTLM authentication in this domain](network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md) to any of the deny options, any NTLM authentication request will fail because the pass-through member server will block the NTLM request.
If you define an exception list of servers in this domain to which client computers are allowed to use NTLM pass-through authentication, then NTLM authentication traffic will continue to flow between those servers, which make them vulnerable to any malicious attack that takes advantage of security
@@ -97,14 +97,13 @@ weaknesses in NTLM.
### Countermeasure
-When you use **Network Security: Restrict NTLM: NTLM authentication in this domain** in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the pass-through authentication servers. When assessed, you will have to determine on a
-case-by-case basis if NTLM authentication still minimally meets your security requirements.
+When you use **Network Security: Restrict NTLM: NTLM authentication in this domain** in audit-only mode, you can determine by reviewing which client applications are making NTLM authentication requests to the pass-through authentication servers. When assessed, you'll have to determine on a case-by-case basis if NTLM authentication still minimally meets your security requirements.
### Potential impact
Defining a list of servers for this policy setting will enable NTLM authentication traffic between those servers might result in a security vulnerability.
-If this list is not defined and **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, then NTLM authentication will fail on those pass-through servers in the domain that they have previously used
+If this list isn't defined and **Network Security: Restrict NTLM: NTLM authentication in this domain** is enabled, then NTLM authentication will fail on those pass-through servers in the domain that they've previously used
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
index 47b963ab2a..d1310a007d 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-incoming-ntlm-traffic.md
@@ -29,18 +29,18 @@ Describes the best practices, location, values, management aspects, and security
The **Network Security: Restrict NTLM: Audit incoming NTLM traffic** policy setting allows you to audit incoming NTLM traffic.
-When this audit policy is enabled within Group Policy, it is enforced on any server where that Group Policy is distributed. The events will be recorded in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently.
+When this audit policy is enabled within Group Policy, it's enforced on any server where that Group Policy is distributed. The events will be recorded in the operational event log located in **Applications and Services Log\\Microsoft\\Windows\\NTLM**. Using an audit event collection system can help you collect the events for analysis more efficiently.
When you enable this policy on a server, only authentication traffic to that server will be logged.
-When you enable this audit policy, it functions in the same way as the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy, but it does not actually block any traffic. Therefore, you can use it effectively to understand the
-authentication traffic in your environment, and when you are ready to block that traffic, you can enable the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting and select **Deny all accounts** or **Deny all domain accounts**.
+When you enable this audit policy, it functions in the same way as the [Network Security: Restrict NTLM: Incoming NTLM traffic](network-security-restrict-ntlm-incoming-ntlm-traffic.md) policy, but it doesn't actually block any traffic. Therefore, you can use it effectively to understand the
+authentication traffic in your environment, and when you're ready to block that traffic, you can enable the Network Security: Restrict NTLM: Incoming NTLM traffic policy setting and select **Deny all accounts** or **Deny all domain accounts**.
### Possible values
- Disable
- The server on which this policy is set will not log events for incoming NTLM traffic.
+ The server on which this policy is set won't log events for incoming NTLM traffic.
- Enable auditing for domain accounts
@@ -52,7 +52,7 @@ authentication traffic in your environment, and when you are ready to block that
- Not defined
- This is the same as **Disable**, and it results in no auditing of NTLM traffic.
+ This state of not being defined is the same as **Disable**, and it results in no auditing of NTLM traffic.
### Best practices
@@ -95,11 +95,11 @@ There are no security audit event policies that can be configured to view output
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
+NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB relay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
### Vulnerability
-Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
+Enabling this policy setting will reveal through logging which servers and client computers within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting doesn't prevent or mitigate any vulnerability because it is for audit purposes only.
### Countermeasure
@@ -107,7 +107,7 @@ Restrict access to the log files when this policy setting is enabled in your pro
### Potential impact
-If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
+If you don't enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
index bdbf0e528d..e1cda4e95c 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-audit-ntlm-authentication-in-this-domain.md
@@ -31,25 +31,25 @@ The **Network Security: Restrict NTLM: Audit NTLM authentication in this domain*
When you enable this policy setting on the domain controller, only authentication traffic to that domain controller will be logged.
-When you enable this audit policy, it functions in the same way as the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting, but it does not actually block any traffic. Therefore, you can use it effectively to understand the authentication traffic to your domain controllers and when you are ready to block that traffic, you can enable the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting and select **Deny for domain accounts to domain servers**, **Deny for domain servers**, or **Deny for domain accounts**.
+When you enable this audit policy, it functions in the same way as the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting, but it doesn't actually block any traffic. Therefore, you can use it effectively to understand the authentication traffic to your domain controllers and when you're ready to block that traffic, you can enable the **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting and select **Deny for domain accounts to domain servers**, **Deny for domain servers**, or **Deny for domain accounts**.
### Possible values
- **Disable**
- The domain controller on which this policy is set will not log events for incoming NTLM traffic.
+ The domain controller on which this policy is set won't log events for incoming NTLM traffic.
- **Enable for domain accounts to domain servers**
- The domain controller on which this policy is set will log events for NTLM authentication logon attempts for accounts in the domain to domain servers when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts to domain servers**.
+ The domain controller on which this policy is set will log events for NTLM authentication sign-in attempts for accounts in the domain to domain servers when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts to domain servers**.
- **Enable for domain accounts**
- The domain controller will log events for NTLM authentication logon attempts that use domain accounts when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts**.
+ The domain controller will log events for NTLM authentication sign-in attempts that use domain accounts when NTLM authentication would be denied because the **Network security: Restrict NTLM: NTLM authentication in this domain** policy setting is set to **Deny for domain accounts**.
- Not defined
- This is the same as **Disable** and results in no auditing of NTLM traffic.
+ This state of not being defined is the same as **Disable** and results in no auditing of NTLM traffic.
### Best practices
@@ -92,19 +92,19 @@ There are no security audit event policies that can be configured to view output
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the
+NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the
Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
### Vulnerability
-Enabling this policy setting will reveal through logging which devices within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting does not prevent or mitigate any vulnerability because it is for audit purposes only.
+Enabling this policy setting will reveal through logging which devices within your network or domain handle NTLM traffic. The identity of these devices can be used in malicious ways if NTLM authentication traffic is compromised. The policy setting doesn't prevent or mitigate any vulnerability because it is for audit purposes only.
### Countermeasure
Restrict access to the log files when this policy setting is enabled in your production environment.
### Potential impact
-If you do not enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
+If you don't enable or configure this policy setting, no NTLM authentication traffic information will be logged. If you do enable this policy setting, only auditing functions will occur; no security enhancements will be implemented.
## Related topics
From 5e97dffc00c36d1b5325c8bd664e6fdf4a48d71f Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Wed, 29 Jun 2022 14:09:34 +0530
Subject: [PATCH 016/299] Acrolinx Enhancement Effort
---
...ity-restrict-ntlm-incoming-ntlm-traffic.md | 12 ++--
...ntlm-ntlm-authentication-in-this-domain.md | 14 ++--
...outgoing-ntlm-traffic-to-remote-servers.md | 12 ++--
...sword-must-meet-complexity-requirements.md | 12 ++--
.../perform-volume-maintenance-tasks.md | 2 +-
.../profile-single-process.md | 6 +-
.../profile-system-performance.md | 2 +-
...le-allow-automatic-administrative-logon.md | 12 ++--
...py-and-access-to-all-drives-and-folders.md | 10 +--
.../remove-computer-from-docking-station.md | 12 ++--
.../reset-account-lockout-counter-after.md | 8 +--
.../security-policy-settings-reference.md | 2 +-
.../security-policy-settings.md | 72 +++++++++----------
.../shut-down-the-system.md | 14 ++--
.../shutdown-clear-virtual-memory-pagefile.md | 10 +--
...nt-digitally-sign-communications-always.md | 12 ++--
...ly-sign-communications-if-server-agrees.md | 14 ++--
...er-digitally-sign-communications-always.md | 16 ++---
...ly-sign-communications-if-client-agrees.md | 14 ++--
...e-passwords-using-reversible-encryption.md | 6 +-
.../synchronize-directory-service-data.md | 6 +-
...on-for-user-keys-stored-on-the-computer.md | 10 +--
...thms-for-encryption-hashing-and-signing.md | 12 ++--
...nsensitivity-for-non-windows-subsystems.md | 10 +--
...-permissions-of-internal-system-objects.md | 14 ++--
.../system-settings-optional-subsystems.md | 6 +-
...ables-for-software-restriction-policies.md | 2 +-
...ake-ownership-of-files-or-other-objects.md | 4 +-
...-for-the-built-in-administrator-account.md | 12 ++--
...vation-without-using-the-secure-desktop.md | 8 +--
30 files changed, 173 insertions(+), 173 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md
index cbcc2e7d66..2bb128f669 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-incoming-ntlm-traffic.md
@@ -37,20 +37,20 @@ The **Network Security: Restrict NTLM: Incoming NTLM traffic** policy setting al
- **Deny all domain accounts**
- The server will deny NTLM authentication requests for domain logon, return an NTLM blocked error message to the client device, and log the error, but the server will allow local account logon.
+ The server will deny NTLM authentication requests for domain sign in, return an NTLM blocked error message to the client device, and log the error, but the server will allow local account sign in.
- **Deny all accounts**
- The server will deny NTLM authentication requests from all incoming traffic (whether domain account logon or local account logon), return an NTLM blocked error message to the client device, and log the error.
+ The server will deny NTLM authentication requests from all incoming traffic (whether domain account sign in or local account sign in), return an NTLM blocked error message to the client device, and log the error.
- Not defined
- This is the same as **Allow all**, and the server will allow all NTLM authentication requests.
+ This state of not being defined is the same as **Allow all**, and the server will allow all NTLM authentication requests.
### Best practices
-If you select **Deny all domain accounts** or **Deny all accounts**, incoming NTLM traffic to the member server will be restricted. It is better to set the **Network Security: Restrict NTLM: Audit Incoming NTLM traffic** policy setting and then review the Operational log to understand what authentication attempts are made to the member servers, and subsequently what client applications are using NTLM.
+If you select **Deny all domain accounts** or **Deny all accounts**, incoming NTLM traffic to the member server will be restricted. It's better to set the **Network Security: Restrict NTLM: Audit Incoming NTLM traffic** policy setting and then review the Operational log to understand what authentication attempts are made to the member servers, and then what client applications are using NTLM.
### Location
@@ -89,7 +89,7 @@ There are no Security Audit Event policies that can be configured to view event
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
+NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
### Vulnerability
@@ -97,7 +97,7 @@ Malicious attacks on NTLM authentication traffic that result in a compromised se
### Countermeasure
-When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as Kerberos, you can select one of several options that this security policy setting offers to restrict NTLM usage.
+When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as Kerberos, you can select one of several options that this security policy setting offers to restrict NTLM usage.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
index 0c1396e74f..2589d1f95d 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain.md
@@ -26,7 +26,7 @@ Describes the best practices, location, values, management aspects, and security
## Reference
-The **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy setting does not affect interactive logon to this domain controller.
+The **Network Security: Restrict NTLM: NTLM authentication in this domain** policy setting allows you to deny or allow NTLM authentication within a domain from this domain controller. This policy setting doesn't affect interactive logon to this domain controller.
### Possible values
@@ -36,17 +36,17 @@ The **Network Security: Restrict NTLM: NTLM authentication in this domain** poli
- **Deny for domain accounts to domain servers**
- The domain controller will deny all NTLM authentication logon attempts using accounts from this domain to all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
+ The domain controller will deny all NTLM authentication sign-in attempts using accounts from this domain to all servers in the domain. The NTLM authentication attempts will be blocked and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
- NTLM can be used if the users are connecting to other domains. This depends on if any Restrict NTLM policies have been set on those domains.
+ NTLM can be used if the users are connecting to other domains, depending on whether any Restrict NTLM policies have been set on those domains.
- **Deny for domain accounts**
- Only the domain controller will deny all NTLM authentication logon attempts from domain accounts and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
+ Only the domain controller will deny all NTLM authentication sign-in attempts from domain accounts and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting.
- **Deny for domain servers**
- The domain controller will deny NTLM authentication requests to all servers in the domain and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. Servers that are not joined to the domain will not be affected if this policy setting is configured.
+ The domain controller will deny NTLM authentication requests to all servers in the domain and will return an NTLM blocked error unless the server name is on the exception list in the **Network security: Restrict NTLM: Add server exceptions in this domain** policy setting. Servers that aren't joined to the domain won't be affected if this policy setting is configured.
- **Deny all**
@@ -97,7 +97,7 @@ There are no security audit event policies that can be configured to view output
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
+NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
### Vulnerability
@@ -105,7 +105,7 @@ Malicious attacks on NTLM authentication traffic resulting in a compromised serv
### Countermeasure
-When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as the Kerberos protocol, then you can select one of several options that this security policy setting offers to restrict NTLM usage
+When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as the Kerberos protocol, then you can select one of several options that this security policy setting offers to restrict NTLM usage
within the domain.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
index f53a1e1665..9f98ea958e 100644
--- a/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
+++ b/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-outgoing-ntlm-traffic-to-remote-servers.md
@@ -39,19 +39,19 @@ The **Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers**
- **Audit all**
- The device that sends the NTLM authentication request to a remote server logs an event for each request. This allows you to identify those servers that receive NTLM authentication requests from the client device
+ The device that sends the NTLM authentication request to a remote server logs an event for each request. This event allows you to identify those servers that receive NTLM authentication requests from the client device.
- **Deny all**
- The device cannot authenticate any identities to a remote server by using NTLM authentication. You can use the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting to define a list of remote servers to which client devices are allowed to use NTLM authentication while denying others. This setting will also log an event on the device that is making the authentication request.
+ The device can't authenticate any identities to a remote server by using NTLM authentication. You can use the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting to define a list of remote servers to which client devices are allowed to use NTLM authentication while denying others. This setting will also log an event on the device that is making the authentication request.
- Not defined
- This is the same as **Allow all**, and the device will allow all NTLM authentication requests when the policy is deployed.
+ This state of being not defined is the same as **Allow all**, and the device will allow all NTLM authentication requests when the policy is deployed.
### Best practices
-If you select **Deny all**, the client device cannot authenticate identities to a remote server by using NTLM authentication. First, select **Audit all** and then review the operational event log to understand which servers are involved in these authentication attempts. You can then add those server names to a server exception list by using the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting.
+If you select **Deny all**, the client device can't authenticate identities to a remote server by using NTLM authentication. First, select **Audit all** and then review the operational event log to understand which servers are involved in these authentication attempts. You can then add those server names to a server exception list by using the [Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication](network-security-restrict-ntlm-add-remote-server-exceptions-for-ntlm-authentication.md) policy setting.
### Location
@@ -90,7 +90,7 @@ There are no security audit event policies that can be configured to view event
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
-NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
+NTLM and NTLMv2 authentication is vulnerable to various malicious attacks, including SMB replay, man-in-the-middle attacks, and brute force attacks. Reducing and eliminating NTLM authentication from your environment forces the Windows operating system to use more secure protocols, such as the Kerberos version 5 protocol, or different authentication mechanisms, such as smart cards.
### Vulnerability
@@ -98,7 +98,7 @@ Malicious attacks on NTLM authentication traffic that result in a compromised se
### Countermeasure
-When it has been determined that the NTLM authentication protocol should not be used within a network because you are required to use a more secure protocol such as Kerberos, then you can select from several options to restrict NTLM usage to servers.
+When it has been determined that the NTLM authentication protocol shouldn't be used within a network because you're required to use a more secure protocol such as Kerberos, then you can select from several options to restrict NTLM usage to servers.
### Potential impact
diff --git a/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md b/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md
index 74efe115ae..5bcf16ede3 100644
--- a/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md
+++ b/windows/security/threat-protection/security-policy-settings/password-must-meet-complexity-requirements.md
@@ -31,7 +31,7 @@ The **Passwords must meet complexity requirements** policy setting determines wh
1. Passwords may not contain the user's samAccountName (Account Name) value or entire displayName (Full Name value). Both checks aren't case-sensitive.
The samAccountName is checked in its entirety only to determine whether it's part of the password. If the samAccountName is fewer than three characters long, this check is skipped.
- The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are shorter than three characters are ignored, and substrings of the tokens aren't checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it's ignored. So, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
+ The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are shorter than three characters are ignored, and substrings of the tokens aren't checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin", "M", and "Hagens". Because the second token is only one character long, it's ignored. So, this user couldn't have a password that included either "erin" or "hagens" as a substring anywhere in the password.
2. The password contains characters from three of the following categories:
@@ -45,11 +45,11 @@ The **Passwords must meet complexity requirements** policy setting determines wh
Complexity requirements are enforced when passwords are changed or created.
-The rules that are included in the Windows Server password complexity requirements are part of Passfilt.dll, and they cannot be directly modified.
+The rules that are included in the Windows Server password complexity requirements are part of Passfilt.dll, and they can't be directly modified.
When enabled, the default Passfilt.dll may cause some more Help Desk calls for locked-out accounts, because users are used to passwords that contain only characters that are in the alphabet. But this policy setting is liberal enough that all users should get used to it.
-Additional settings that can be included in a custom Passfilt.dll are the use of non–upper-row characters. To type upper-row characters, you hold the SHIFT key and press one of any of the keys on the number row of the keyboard (from 1 through 9 and 0).
+Other settings that can be included in a custom Passfilt.dll are the use of non–upper-row characters. To type upper-row characters, you hold the SHIFT key and press one of any of the keys on the number row of the keyboard (from 1 through 9 and 0).
### Possible values
@@ -64,9 +64,9 @@ Additional settings that can be included in a custom Passfilt.dll are the use of
Set **Passwords must meet complexity requirements** to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 159,238,157,238,528 different possibilities for a single password. This setting makes a brute force attack difficult, but still not impossible.
-The use of ALT key character combinations may greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements might result in unhappy users and an over-worked Help Desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of that range can represent standard alphanumeric characters that do not add more complexity to the password.)
+The use of ALT key character combinations may greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements might result in unhappy users and an over-worked Help Desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of that range can represent standard alphanumeric characters that don't add more complexity to the password.)
-Short passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To prevent this, passwords should contain additional characters and/or meet complexity requirements.
+Short passwords that contain only alphanumeric characters are easy to compromise by using publicly available tools. To prevent this vulnerability, passwords should contain other characters and/or meet complexity requirements.
### Location
@@ -95,7 +95,7 @@ Passwords that contain only alphanumeric characters are easy to discover with se
### Countermeasure
-Configure the **Passwords must meet complexity requirements** policy setting to _Enabled_ and advise users to use a variety of characters in their passwords.
+Configure the **Passwords must meet complexity requirements** policy setting to _Enabled_ and advise users to use various characters in their passwords.
When combined with a [Minimum password length](minimum-password-length.md) of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it's difficult (but possible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.)
diff --git a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md b/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md
index 514e1a9ea7..fb0e337c6b 100644
--- a/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md
+++ b/windows/security/threat-protection/security-policy-settings/perform-volume-maintenance-tasks.md
@@ -65,7 +65,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.
diff --git a/windows/security/threat-protection/security-policy-settings/profile-single-process.md b/windows/security/threat-protection/security-policy-settings/profile-single-process.md
index 599cb50810..c0fb47def4 100644
--- a/windows/security/threat-protection/security-policy-settings/profile-single-process.md
+++ b/windows/security/threat-protection/security-policy-settings/profile-single-process.md
@@ -64,7 +64,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.
@@ -85,7 +85,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The **Profile single process** user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They could also identify other users who are logged on to a computer.
+The **Profile single process** user right presents a moderate vulnerability. Attackers with this user right could monitor a computer's performance to help identify critical processes that they might want to attack directly. Attackers may be able to determine what processes run on the computer so that they could identify countermeasures that they may need to avoid, such as anti-virus software or an intrusion-detection system. They could also identify other users who are signed in to a computer.
### Countermeasure
@@ -93,7 +93,7 @@ Ensure that only the local Administrators group is assigned the **Profile single
### Potential impact
-If you remove the **Profile single process** user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks are not negatively affected.
+If you remove the **Profile single process** user right from the Power Users group or other accounts, you could limit the abilities of users who are assigned to specific administrative roles in your environment. You should ensure that delegated tasks aren't negatively affected.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md b/windows/security/threat-protection/security-policy-settings/profile-system-performance.md
index 47f372d723..8eeabdcf30 100644
--- a/windows/security/threat-protection/security-policy-settings/profile-system-performance.md
+++ b/windows/security/threat-protection/security-policy-settings/profile-system-performance.md
@@ -64,7 +64,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 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.
diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md
index c188b74c08..ce9ada3153 100644
--- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md
+++ b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-automatic-administrative-logon.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
This policy setting determines whether the built-in Administrator account password must be provided before access to the device is granted. If you enable this setting, the built-in Administrator account is automatically logged on to the computer at the Recovery Console; no password is required.
-The Recovery Console can be useful when troubleshooting and repairing systems that cannot be restarted. However, enabling this policy setting so a user can automatically log on to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select **Recovery Console** from the **Restart** menu, and then assume full control of the server.
+The Recovery Console can be useful when troubleshooting and repairing systems that can't be restarted. However, enabling this policy setting so a user can automatically sign in to the console is dangerous. Anyone can walk up to the server, shut it down by disconnecting the power, reboot it, select **Recovery Console** from the **Restart** menu, and then assume full control of the server.
### Possible values
@@ -39,15 +39,15 @@ The Recovery Console can be useful when troubleshooting and repairing systems th
- Disabled
- Automatic administrative logon is not allowed.
+ Automatic administrative logon isn't allowed.
- Not defined
- Automatic administrative logon is not allowed.
+ Automatic administrative logon isn't allowed.
### Best practices
-- Set **Recovery Console: Allow automatic administrative logon** to **Disabled**. This requires a user to enter a user name and password to access the Recovery Console account.
+- Set **Recovery Console: Allow automatic administrative logon** to **Disabled**. This setting requires a user to enter a user name and password to access the Recovery Console account.
### Location
@@ -72,7 +72,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
@@ -88,7 +88,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The Recovery Console can be very useful when you must troubleshoot and repair device that do not start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server.
+The Recovery Console can be useful when you must troubleshoot and repair devices that don't start. However, allowing automatic logon to the Recovery Console can make it possible for someone to assume full control of the server.
### Countermeasure
diff --git a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
index c06d6f180c..9c9c56c5db 100644
--- a/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
+++ b/windows/security/threat-protection/security-policy-settings/recovery-console-allow-floppy-copy-and-access-to-all-drives-and-folders.md
@@ -34,7 +34,7 @@ This policy setting enables or disables the Recovery Console SET command, which
- **AllowRemovableMedia**. Allows files to be copied to removable media, such as a floppy disk.
- **NoCopyPrompt**. Suppresses the prompt that typically displays before an existing file is overwritten.
-You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the removable media before the hard disk drive, the server will start from the removable disk. This causes the server's network services to be unavailable.
+You might forget to remove removable media, such as CD or floppy disk, with sensitive data or applications that a malicious user could then steal. Or you could accidentally leave a startup disk in the computer after using the Recovery Console. If the device is restarted for any reason and the BIOS has been configured to boot from the removable media before the hard disk drive, the server will start from the removable disk. This boot causes the server's network services to be unavailable.
### Possible values
@@ -44,7 +44,7 @@ You might forget to remove removable media, such as CD or floppy disk, with sens
### Best practices
-- Set **Recovery Console: Allow floppy copy and access to drives and folders** to **Disabled**. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account will not be able to copy files and folders to a floppy disk.
+- Set **Recovery Console: Allow floppy copy and access to drives and folders** to **Disabled**. Users who have started a server by using the Recovery Console and logged in with the built-in Administrator account won't be able to copy files and folders to a floppy disk.
### 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.
### Group Policy
@@ -86,7 +86,7 @@ Enabling this security option makes the Recovery Console SET command available,
- AllowWildCards: Enable wildcard support for some commands (such as the DEL command).
- AllowAllPaths: Allow access to all files and folders on the device.
- AllowRemovableMedia: Allow files to be copied to removable media, such as a floppy disk.
-- NoCopyPrompt: Do not prompt when overwriting an existing file.
+- NoCopyPrompt: Don't prompt when overwriting an existing file.
## Security considerations
@@ -102,7 +102,7 @@ Disable the **Recovery console: Allow floppy copy and access to drives and folde
### Potential impact
-Users who have started a server through the Recovery Console and logged in with the built-in Administrator account cannot copy files and folders to a floppy disk.
+Users who have started a server through the Recovery Console and logged in with the built-in Administrator account can't copy files and folders to a floppy disk.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md b/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md
index 4508560bdc..b42bad16dd 100644
--- a/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md
+++ b/windows/security/threat-protection/security-policy-settings/remove-computer-from-docking-station.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
This security setting determines whether a user can undock a portable device from its docking station without logging on. This policy setting only affects scenarios that involve a portable computer and its docking station.
-If this user right is assigned to the user’s account (or if the user is a member of the assigned group), the user must log on before removing the portable device from its docking station. Otherwise, as a security measure, the user will not be able to log on after the device is removed from the docking station. If this policy is not assigned, the user may remove the portable device from its docking station without logging on, and then have the ability to start and log on to the device afterwards in its undocked state.
+If this user right is assigned to the user’s account (or if the user is a member of the assigned group), the user must sign in before removing the portable device from its docking station. Otherwise, as a security measure, the user won't be able to sign in after the device is removed from the docking station. If this policy isn't assigned, the user may remove the portable device from its docking station without signing in, and then have the ability to start and sign in to the device afterwards in its undocked state.
Constant: SeUndockPrivilege
@@ -48,7 +48,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
### Default values
-Although this portable device scenario does not normally apply to servers, by default this setting is Administrators on domain controllers and on stand-alone servers.
+Although this portable device scenario doesn't normally apply to servers, by default this setting is Administrators on domain controllers and on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
@@ -65,7 +65,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.
@@ -86,10 +86,10 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-Anyone who has the **Remove computer from docking station** user right can log on and then remove a portable device from its docking station. If this setting is not defined, it has the same effect as if everyone was granted this right. However, the value of implementing this countermeasure is reduced by the following factors:
+Anyone who has the **Remove computer from docking station** user right can sign in and then remove a portable device from its docking station. If this setting isn't defined, it has the same effect as if everyone was granted this right. However, the value of implementing this countermeasure is reduced by the following factors:
- If attackers can restart the device, they could remove it from the docking station after the BIOS starts but before the operating system starts.
-- This setting does not affect servers because they typically are not installed in docking stations.
+- This setting doesn't affect servers because they typically aren't installed in docking stations.
- An attacker could steal the device and the docking station together.
- Devices that can be mechanically undocked can be physically removed by the user whether or not they use the Windows undocking functionality.
@@ -99,7 +99,7 @@ Ensure that only the local Administrators group and the user account to which th
### Potential impact
-By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted this user right as necessary. If your organization's users are not members of the local Administrators groups on their portable devices, they cannot remove their portable devices from their docking stations if they do not first shut down the device. Therefore, you may want to assign the **Remove computer from docking station** privilege to the local Users group for portable devices.
+By default, only members of the local Administrators group are granted this right. Other user accounts must be explicitly granted this user right as necessary. If your organization's users aren't members of the local Administrators groups on their portable devices, they can't remove their portable devices from their docking stations if they don't first shut down the device. Therefore, you may want to assign the **Remove computer from docking station** privilege to the local Users group for portable devices.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md
index 87951d31f4..51f96f1875 100644
--- a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md
+++ b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md
@@ -27,9 +27,9 @@ Describes the best practices, location, values, and security considerations for
## Reference
-The **Reset account lockout counter after** policy setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0. If [Account lockout threshold](account-lockout-threshold.md) is set to a number greater than zero, this reset time must be less than or equal to the value of [Account lockout duration](account-lockout-duration.md).
+The **Reset account lockout counter after** policy setting determines the number of minutes that must elapse from the time a user fails to sign in before the failed sign-in attempt counter is reset to 0. If [Account lockout threshold](account-lockout-threshold.md) is set to a number greater than zero, this reset time must be less than or equal to the value of [Account lockout duration](account-lockout-duration.md).
-The disadvantage of a high setting is that users lock themselves out for an inconveniently long period if they exceed the account lockout threshold through logon errors. Users may make excessive Help Desk calls.
+The disadvantage of a high setting is that users lock themselves out for an inconveniently long period if they exceed the account lockout threshold through sign-in errors. Users may make excessive Help Desk calls.
### Possible values
@@ -40,7 +40,7 @@ The disadvantage of a high setting is that users lock themselves out for an inco
Determine the threat level for your organization and balance that against the cost of your Help Desk support for password resets. Each organization will have specific requirements.
-[Windows security baselines](../windows-security-baselines.md) recommend configuring the **Reset account lockout counter after** policy setting to 15, but as with other account lockeout settings, this value is more of a guideline than a rule or best practice because there is no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout).
+[Windows security baselines](../windows-security-baselines.md) recommend configuring the **Reset account lockout counter after** policy setting to 15, but as with other account lockout settings, this value is more of a guideline than a rule or best practice because there's no "one size fits all." For more information, see [Configuring Account Lockout](/archive/blogs/secguide/configuring-account-lockout).
### Location
@@ -73,7 +73,7 @@ Users can accidentally lock themselves out of their accounts if they mistype the
### Potential impact
-If you do not configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to log on to each user's account numerous times and lock out their accounts, a denial-of-service (DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to log on after a failed logon within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk.
+If you don't configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to sign in to each user's account numerous times and lock out their accounts, a denial-of-service (DoS) attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to sign in after a failed sign in within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md b/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md
index a1d965558b..012a47736e 100644
--- a/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md
+++ b/windows/security/threat-protection/security-policy-settings/security-policy-settings-reference.md
@@ -25,7 +25,7 @@ ms.technology: windows-sec
This reference of security settings provides information about how to implement and manage security policies, including setting options and security considerations.
-This reference focuses on those settings that are considered security settings. This reference examines only the settings and features in the Windows operating systems that can help organizations secure their enterprises against malicious software threats. Management features and those security features that you cannot configure are not described in this reference.
+This reference focuses on those settings that are considered security settings. This reference examines only the settings and features in the Windows operating systems that can help organizations secure their enterprises against malicious software threats. Management features and those security features that you can't configure aren't described in this reference.
Each policy setting described contains referential content such as a detailed explanation of the settings, best practices, default settings, differences between operating system versions, policy management considerations, and security considerations that include a discussion of vulnerability, countermeasures, and potential impact of those countermeasures.
diff --git a/windows/security/threat-protection/security-policy-settings/security-policy-settings.md b/windows/security/threat-protection/security-policy-settings/security-policy-settings.md
index a0a8270da7..48b90c0da2 100644
--- a/windows/security/threat-protection/security-policy-settings/security-policy-settings.md
+++ b/windows/security/threat-protection/security-policy-settings/security-policy-settings.md
@@ -26,7 +26,7 @@ ms.technology: windows-sec
This reference topic describes the common scenarios, architecture, and processes for security settings.
-Security policy settings are rules that administrators configure on a computer or multiple devices for the purpose of protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security settings for multiple devices from any device joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients, and other resources in your organization.
+Security policy settings are rules that administrators configure on a computer or multiple devices for protecting resources on a device or network. The Security Settings extension of the Local Group Policy Editor snap-in allows you to define security configurations as part of a Group Policy Object (GPO). The GPOs are linked to Active Directory containers such as sites, domains, or organizational units, and they enable you to manage security settings for multiple devices from any device joined to the domain. Security settings policies are used as part of your overall security implementation to help secure domain controllers, servers, clients, and other resources in your organization.
Security settings can control:
@@ -44,7 +44,7 @@ For more info about managing security configurations, see [Administer security p
The Security Settings extension of the Local Group Policy Editor includes the following types of security policies:
-- **Account Policies.** These polices are defined on devices; they affect how user accounts can interact with the computer or domain. Account policies include the following types of policies:
+- **Account Policies.** These policies are defined on devices; they affect how user accounts can interact with the computer or domain. Account policies include the following types of policies:
- **Password Policy.** These policies determine settings for passwords, such as enforcement and lifetimes. Password policies are used for domain accounts.
- **Account Lockout Policy.** These policies determine the conditions and length of time that an account will be locked out of the system. Account lockout policies are used for domain or local user accounts.
@@ -57,15 +57,15 @@ The Security Settings extension of the Local Group Policy Editor includes the fo
> [!NOTE]
> For devices running Windows 7 and later, we recommend to use the settings under Advanced Audit Policy Configuration rather than the Audit Policy settings under Local Policies.
- - **User Rights Assignment.** Specify the users or groups that have logon rights or privileges on a device
- - **Security Options.** Specify security settings for the computer, such as Administrator and Guest Account names; access to floppy disk drives and CD-ROM drives; installation of drivers; logon prompts; and so on.
+ - **User Rights Assignment.** Specify the users or groups that have sign-in rights or privileges on a device
+ - **Security Options.** Specify security settings for the computer, such as Administrator and Guest Account names; access to floppy disk drives and CD-ROM drives; installation of drivers; sign-in prompts; and so on.
- **Windows Firewall with Advanced Security.** Specify settings to protect the device on your network by using a stateful firewall that allows you to determine which network traffic is permitted to pass between your device and the network.
- **Network List Manager Policies.** Specify settings that you can use to configure different aspects of how networks are listed and displayed on one device or on many devices.
- **Public Key Policies.** Specify settings to control Encrypting File System, Data Protection, and BitLocker Drive Encryption in addition to certain certificate paths and services settings.
- **Software Restriction Policies.** Specify settings to identify software and to control its ability to run on your local device, organizational unit, domain, or site.
- **Application Control Policies.** Specify settings to control which users or groups can run particular applications in your organization based on unique identities of files.
-- **IP Security Policies on Local Computer.** Specify settings to ensure private, secure communications over IP networks through the use of cryptographic security services. IPsec establishes trust and security from a source IP address to a destination IP address.
+- **IP Security Policies on Local Computer.** Specify settings to ensure private, secure communications over IP networks by using cryptographic security services. IPsec establishes trust and security from a source IP address to a destination IP address.
- **Advanced Audit Policy Configuration.** Specify settings that control the logging of security events into the security log on the device. The settings under Advanced Audit Policy Configuration provide finer control over which activities to monitor as opposed to the Audit Policy settings under Local Policies.
## Policy-based security settings management
@@ -87,7 +87,7 @@ Importing a security template to a GPO ensures that any accounts to which the GP
> [!NOTE]
> These refresh settings vary between versions of the operating system and can be configured.
-By using Group Policy−based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update a number of servers with any additional changes required in the future.
+By using Group Policy−based security configurations in conjunction with the delegation of administration, you can ensure that specific security settings, rights, and behavior are applied to all servers and computers within an OU. This approach makes it simple to update many servers with any other changes required in the future.
### Dependencies on other operating system technologies
@@ -95,7 +95,7 @@ For devices that are members of a Windows Server 2008 or later domain, securit
- **Active Directory Domain Services (AD DS)**
- The Windows-based directory service, AD DS, stores information about objects on a network and makes this information available to administrators and users. By using AD DS, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single logon.
+ The Windows-based directory service, AD DS, stores information about objects on a network and makes this information available to administrators and users. By using AD DS, you can view and manage network objects on the network from a single location, and users can access permitted network resources by using a single sign in.
- **Group Policy**
@@ -103,7 +103,7 @@ For devices that are members of a Windows Server 2008 or later domain, securit
- **Domain Name System (DNS)**
- A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This allows users, computers, and applications to query DNS to specify remote systems by fully qualified domain names rather than by IP addresses.
+ A hierarchical naming system used for locating domain names on the Internet and on private TCP/IP networks. DNS provides a service for mapping DNS domain names to IP addresses, and IP addresses to domain names. This service allows users, computers, and applications to query DNS to specify remote systems by fully qualified domain names rather than by IP addresses.
- **Winlogon**
@@ -115,11 +115,11 @@ For devices that are members of a Windows Server 2008 or later domain, securit
- **Security Accounts Manager (SAM)**
- A Windows service used during the logon process. SAM maintains user account information, including groups to which a user belongs.
+ A Windows service used during the sign-in process. SAM maintains user account information, including groups to which a user belongs.
- **Local Security Authority (LSA)**
- A protected subsystem that authenticates and logs users onto the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system.
+ A protected subsystem that authenticates and signs in users to the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system.
- **Windows Management Instrumentation (WMI)**
@@ -127,7 +127,7 @@ For devices that are members of a Windows Server 2008 or later domain, securit
- **Resultant Set of Policy (RSoP)**
- An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. This allows administrators to easily determine the combination of policy settings that apply to, or will apply to, a user or device.
+ An enhanced Group Policy infrastructure that uses WMI in order to make it easier to plan and debug policy settings. RSoP provides public methods that expose what an extension to Group Policy would do in a what-if situation, and what the extension has done in an actual situation. These public methods allow administrators to easily determine the combination of policy settings that apply to, or will apply to, a user or device.
- **Service Control Manager (SCM)**
@@ -189,11 +189,11 @@ The following list describes these primary features of the security configuratio
- **scesrv.dll**
- This .dll is hosted in services.exe and runs under local system context. scesrv.dll provides core Security Configuration Manager functionality, such as import, configure, analyze, and policy propagation.
+ This .dll file is hosted in services.exe and runs under local system context. scesrv.dll provides core Security Configuration Manager functionality, such as import, configure, analyze, and policy propagation.
Scesrv.dll performs configuration and analysis of various security-related system parameters by calling corresponding system APIs, including LSA, SAM, and the registry.
- Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over LRPC (Windows XP) and fails the call if it is not.
+ Scesrv.dll exposes APIs such as import, export, configure, and analyze. It checks that the request is made over LRPC (Windows XP) and fails the call if it isn't.
Communication between parts of the Security Settings extension occurs by using the following methods:
@@ -210,7 +210,7 @@ The following list describes these primary features of the security configuratio
- **Scecli.dll**
- This is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC snap-ins. It is used by Setup to configure default system security and security of files, registry keys, and services installed by the Setup API .inf files.
+ This Scecli.dll is the client-side interface or wrapper to scesrv.dll. scecli.dll is loaded into Wsecedit.dll to support MMC snap-ins. It's used by Setup to configure default system security and security of files, registry keys, and services installed by the Setup API .inf files.
The command-line version of the security configuration and analysis user interfaces, secedit.exe, uses scecli.dll.
@@ -228,7 +228,7 @@ The following list describes these primary features of the security configuratio
- **Secedit.sdb**
- This is a permanent system database used for policy propagation including a table of persistent settings for rollback purposes.
+ This Secedit.sdb is a permanent system database used for policy propagation including a table of persistent settings for rollback purposes.
- **User databases**
@@ -236,7 +236,7 @@ The following list describes these primary features of the security configuratio
- **.Inf Templates**
- These are text files that contain declarative security settings. They are loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they are downloaded (by using file copy) and merged into the system database during policy propagation.
+ These templates are text files that contain declarative security settings. They're loaded into a database before configuration or analysis. Group Policy security policies are stored in .inf files on the SYSVOL folder of domain controllers, where they're downloaded (by using file copy) and merged into the system database during policy propagation.
## Security settings policy processes and interactions
@@ -244,27 +244,27 @@ For a domain-joined device, where Group Policy is administered, security setting
### Group Policy processing
-When a computer starts and a user logs on, computer policy and user policy are applied according to the following sequence:
+When a computer starts and a user signs in, computer policy and user policy are applied according to the following sequence:
1. The network starts. Remote Procedure Call System Service (RPCSS) and Multiple Universal Naming Convention Provider (MUP) start.
1. An ordered list of Group Policy Objects is obtained for the device. The list might depend on these factors:
- Whether the device is part of a domain and, therefore, subject to Group Policy through Active Directory.
- The location of the device in Active Directory.
- - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
+ - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects hasn't changed, no processing is done.
-1. Computer policy is applied. These are the settings under Computer Configuration from the gathered list. This is a synchronous process by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.
-1. Startup scripts run. This is hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
-1. The user presses CTRL+ALT+DEL to log on.
-1. After the user is validated, the user profile loads; it is governed by the policy settings that are in effect.
+1. Computer policy is applied. These settings are the ones under Computer Configuration from the gathered list. This process is a synchronous one by default and occurs in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while computer policies are processed.
+1. Startup scripts run. These scripts are hidden and synchronous by default; each script must complete or time out before the next one starts. The default time-out is 600 seconds. You can use several policy settings to modify this behavior.
+1. The user presses CTRL+ALT+DEL to sign in.
+1. After the user is validated, the user profile loads; it's governed by the policy settings that are in effect.
1. An ordered list of Group Policy Objects is obtained for the user. The list might depend on these factors:
- Whether the user is part of a domain and, therefore, subject to Group Policy through Active Directory.
- Whether loopback policy processing is enabled, and if so, the state (Merge or Replace) of the loopback policy setting.
- The location of the user in Active Directory.
- - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects has not changed, no processing is done.
+ - Whether the list of Group Policy Objects has changed. If the list of Group Policy Objects hasn't changed, no processing is done.
-1. User policy is applied. These are the settings under User Configuration from the gathered list. This is synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.
+1. User policy is applied. These settings are the ones under User Configuration from the gathered list. These settings are synchronous by default and in the following order: local, site, domain, organizational unit, child organizational unit, and so on. No user interface appears while user policies are processed.
1. Logon scripts run. Group Policy−based logon scripts are hidden and asynchronous by default. The user object script runs last.
1. The operating system user interface that is prescribed by Group Policy appears.
@@ -296,7 +296,7 @@ Group Policy settings are processed in the following order:
1. **Domain.**
- Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you speciy.
+ Processing of multiple domain-linked Group Policy Objects is synchronous and in an order you specify.
1. **Organizational units.**
@@ -306,7 +306,7 @@ At the level of each organizational unit in the Active Directory hierarchy, one,
This order means that the local Group Policy Object is processed first, and Group Policy Objects that are linked to the organizational unit of which the computer or user is a direct member are processed last, which overwrites the earlier Group Policy Objects.
-This is the default processing order and administrators can specify exceptions to this order. A Group Policy Object that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to **Enforced** with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as **Block Inheritance**. Group Policy Object links that are set to **Enforced** are always applied, however, and they cannot be blocked. For more information see [Group Policy Basics – Part 2: Understanding Which GPOs to Apply](/archive/blogs/musings_of_a_technical_tam/group-policy-basics-part-2-understanding-which-gpos-to-apply).
+This order is the default processing order and administrators can specify exceptions to this order. A Group Policy Object that is linked to a site, domain, or organizational unit (not a local Group Policy Object) can be set to **Enforced** with respect to that site, domain, or organizational unit, so that none of its policy settings can be overridden. At any site, domain, or organizational unit, you can mark Group Policy inheritance selectively as **Block Inheritance**. Group Policy Object links that are set to **Enforced** are always applied, however, and they can't be blocked. For more information, see [Group Policy Basics – Part 2: Understanding Which GPOs to Apply](/archive/blogs/musings_of_a_technical_tam/group-policy-basics-part-2-understanding-which-gpos-to-apply).
### Security settings policy processing
@@ -333,9 +333,9 @@ The following figure illustrates the security settings policy processing.
### Merging of security policies on domain controllers
-Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:
+Password policies, Kerberos, and some security options are only merged from GPOs that are linked at the root level on the domain. This merging is done to keep those settings synchronized across all domain controllers in the domain. The following security options are merged:
-- Network Security: Force logoff when logon hours expire
+- Network Security: Force sign out when sign-in hours expire
- Accounts: Administrator account status
- Accounts: Guest account status
- Accounts: Rename administrator account
@@ -349,11 +349,11 @@ If an application is installed on a primary domain controller (PDC) with operati
### When security settings are applied
-After you have edited the security settings policies, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object in the following instances:
+After you've edited the security settings policies, the settings are refreshed on the computers in the organizational unit linked to your Group Policy Object in the following instances:
- When a device is restarted.
- Every 90 minutes on a workstation or server and every 5 minutes on a domain controller. This refresh interval is configurable.
-- By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO has not changed.
+- By default, Security policy settings delivered by Group Policy are also applied every 16 hours (960 minutes) even if a GPO hasn't changed.
### Persistence of security settings policy
@@ -361,11 +361,11 @@ Security settings can persist even if a setting is no longer defined in the poli
Security settings might persist in the following cases:
-- 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 security object.
- The settings are for a file system security object.
-All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is.
+All settings applied through local policy or through a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value doesn't exist in the database, then the setting doesn't revert to anything and remains defined as is.
This behavior is sometimes referred to as "tattooing".
Registry and file security settings will maintain the values applied through Group Policy until that setting is set to other values.
@@ -376,7 +376,7 @@ Both Apply Group Policy and Read permissions are required to have the settings f
### Filtering security policy
-By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or will not have a Group Policy Object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.
+By default, all GPOs have Read and Apply Group Policy both Allowed for the Authenticated Users group. The Authenticated Users group includes both users and computers. Security settings policies are computer-based. To specify which client computers will or won't have a Group Policy Object applied to them, you can deny them either the Apply Group Policy or Read permission on that Group Policy Object. Changing these permissions allows you to limit the scope of the GPO to a specific set of computers within a site, domain, or OU.
> [!NOTE]
> Do not use security policy filtering on a domain controller as this would prevent security policy from applying to it.
@@ -385,9 +385,9 @@ By default, all GPOs have Read and Apply Group Policy both Allowed for the Authe
In some situations, you might want to migrate GPOs from one domain environment to another environment. The two most common scenarios are test-to-production migration, and production-to-production migration. The GPO copying process has implications for some types of security settings.
-Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs is not as simple as taking a folder and copying it from one device to another.
+Data for a single GPO is stored in multiple locations and in various formats; some data is contained in Active Directory and other data is stored on the SYSVOL share on the domain controllers. Certain policy data might be valid in one domain but might be invalid in the domain to which the GPO is being copied. For example, Security Identifiers (SIDs) stored in security policy settings are often domain-specific. So copying GPOs isn't as simple as taking a folder and copying it from one device to another.
-The following security policies can contain security principals and might require some additional work to successfully move them from one domain to another.
+The following security policies can contain security principals and might require some more work to successfully move them from one domain to another.
- User rights assignment
- Restricted groups
@@ -396,7 +396,7 @@ The following security policies can contain security principals and might requir
- Registry
- The GPO DACL, if you choose to preserve it during a copy operation
-To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When migrating a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs.
+To ensure that data is copied correctly, you can use Group Policy Management Console (GPMC). When there's a migration of a GPO from one domain to another, GPMC ensures that all relevant data is properly copied. GPMC also offers migration tables, which can be used to update domain-specific data to new values as part of the migration process. GPMC hides much of the complexity involved in the migrating GPO operations, and it provides simple and reliable mechanisms for performing operations such as copy and backup of GPOs.
## In this section
diff --git a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md b/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md
index 57374f2aa8..597fe3f069 100644
--- a/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md
+++ b/windows/security/threat-protection/security-policy-settings/shut-down-the-system.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
This security setting determines if a user who is logged on locally to a device can shut down Windows.
-Shutting down domain controllers makes them unable to do things like process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles, which are also known as flexible single master operations or FSMO roles, can disable key domain functionality. For example, processing logon requests for new passwords, which are done by the primary domain controller (PDC) emulator master.
+Shutting down domain controllers makes them unable to do things like process sign-in requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles, which are also known as flexible single master operations or FSMO roles, can disable key domain functionality. For example, processing sign-in requests for new passwords, which are done by the primary domain controller (PDC) emulator master.
The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancel a shutdown.
@@ -44,7 +44,7 @@ Constant: SeShutdownPrivilege
### Best practices
1. Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers. And that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks won't be negatively affected.
-2. The ability to shut down domain controllers should be limited to a small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be careful about the accounts and groups that you allow to shut down a domain controller.
+2. The ability to shut down domain controllers should be limited to a few trusted administrators. Even though a system shutdown requires the ability to sign in to the server, you should be careful about the accounts and groups that you allow to shut down a domain controller.
### Location
@@ -69,13 +69,13 @@ 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.
### Group Policy
-This user right does not have the same effect as **Force shutdown from a remote system**. For more information, see [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md).
+This user right doesn't have the same effect as **Force shutdown from a remote system**. For more information, see [Force shutdown from a remote system](force-shutdown-from-a-remote-system.md).
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
@@ -92,11 +92,11 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Although the **Shut down the system** user right requires the ability to log on to the server, you should be careful about which accounts and groups you allow to shut down a domain controller.
+The ability to shut down domain controllers should be limited to a few trusted administrators. Although the **Shut down the system** user right requires the ability to sign in to the server, you should be careful about which accounts and groups you allow to shut down a domain controller.
-When a domain controller is shut down, it can't process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that have operations master roles, you can disable key domain functionality, such as processing logon requests for new passwords, which are performed by the PDC master.
+When a domain controller is shut down, it can't process sign-in requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that have operations master roles, you can disable key domain functionality, such as processing sign-in requests for new passwords, which are performed by the PDC master.
-For other server roles, especially roles where non-administrators have rights to log on to the server, such as RD Session Host servers, it's critical that this user right be removed from users who don't have a legitimate reason to restart the servers.
+For other server roles, especially roles where non-administrators have rights to sign in to the server, such as RD Session Host servers, it's critical that this user right be removed from users who don't have a legitimate reason to restart the servers.
### Countermeasure
diff --git a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md b/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md
index 4cada523db..185bbf975e 100644
--- a/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md
+++ b/windows/security/threat-protection/security-policy-settings/shutdown-clear-virtual-memory-pagefile.md
@@ -27,9 +27,9 @@ Describes the best practices, location, values, policy management and security c
## Reference
-This policy setting determines whether the virtual memory paging file is cleared when the device is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they are not used. On a running device, this paging file is opened exclusively by the operating system, and it is well protected. However, devices that are configured to allow other operating systems to start should verify that the system paging file is cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file is not available to an unauthorized user who manages to directly access the paging file after shutdown.
+This policy setting determines whether the virtual memory paging file is cleared when the device is shut down. Virtual memory support uses a system paging file to swap pages of memory to disk when they aren't used. On a running device, this paging file is opened exclusively by the operating system, and it's well protected. However, devices that are configured to allow other operating systems to start should verify that the system paging file is cleared as the device shuts down. This confirmation ensures that sensitive information from process memory that might be placed in the paging file isn't available to an unauthorized user who manages to directly access the paging file after shutdown.
-Important information that is kept in real memory might be written periodically to the paging file. This helps devices handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This is a time-consuming process, but it can expose data that is cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by simply unplugging the server from its power source.
+Important information that is kept in real memory might be written periodically to the paging file. This periodical write-operation helps devices handle multitasking functions. A malicious user who has physical access to a server that has been shut down can view the contents of the paging file. The attacker can move the system volume into a different computer and then analyze the contents of the paging file. This process is a time-consuming one, but it can expose data that is cached from RAM to the paging file. A malicious user who has physical access to the server can bypass this countermeasure by unplugging the server from its power source.
### Possible values
@@ -42,7 +42,7 @@ Important information that is kept in real memory might be written periodically
### Best practices
-- Set this policy to **Enabled**. This causes Windows to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment.
+- Set this policy to **Enabled**. This policy setting causes Windows to clear the paging file when the system is shut down. Depending on the size of the paging file, this process might take several minutes before the system completely shuts down. This delay in shutting down the server is especially noticeable on servers with large paging files. For a server with 2 gigabytes (GB) of RAM and a 2-GB paging file, this setting can add more than 30 minutes to the shutdown process. For some organizations, this downtime violates their internal service level agreements. Use caution when implementing this countermeasure in your environment.
### Location
@@ -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 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
@@ -85,7 +85,7 @@ Enable the **Shutdown: Clear virtual memory page file** setting. This configurat
### Potential impact
-It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more than 30 minutes. For some organizations this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment.
+It takes longer to shut down and restart the device, especially on devices with large paging files. For a device with 2 gigabytes (GB) of RAM and a 2-GB paging file, this policy setting could increase the shutdown process by more than 30 minutes. For some organizations, this downtime violates their internal service level agreements. Therefore, use caution before you implement this countermeasure in your environment.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md
index d5ebfdefe1..b720770fd9 100644
--- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md
+++ b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-always.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
**Applies to**
- Windows 10
-This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 is not secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 is not installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
+This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network client: Digitally sign communications (always)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network client: Digitally sign communications (always)](microsoft-network-client-digitally-sign-communications-always.md).
@@ -34,7 +34,7 @@ This policy setting determines whether SMB packet signing must be negotiated bef
Implementation of digital signatures in high-security networks helps prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
+If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
@@ -85,7 +85,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
@@ -95,7 +95,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 computer after legitimate authentication, and gain unauthorized access to data.
-SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
+SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place.
### Countermeasure
@@ -112,9 +112,9 @@ In highly secure environments, we recommend that you configure all of these sett
### Potential impact
-Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
+Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
+Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md
index b1dc905ad5..b912861503 100644
--- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md
+++ b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md
@@ -22,7 +22,7 @@ ms.technology: windows-sec
**Applies to**
- Windows 10
-This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 is not secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 is not installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
+This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
The rest of this topic describes the best practices, location, values, and security considerations for the **Microsoft network client: Digitally sign communications (if server agrees)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network client: Digitally sign communications (if server agrees)](microsoft-network-client-digitally-sign-communications-always.md).
@@ -32,7 +32,7 @@ The Server Message Block (SMB) protocol provides the basis for Microsoft file an
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-If server-side SMB signing is required, a client computer will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
+If server-side SMB signing is required, a client computer won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
@@ -84,7 +84,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
@@ -95,7 +95,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 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 NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
+SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place.
### Countermeasure
@@ -106,16 +106,16 @@ Configure the settings as follows:
- Enable **Microsoft network client: Digitally sign communications (if server agrees)**.
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
+In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
> [!NOTE]
> An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
### Potential impact
-Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
+Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking
+Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure devices to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking
attacks.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md
index e091179e64..49782f3f58 100644
--- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md
+++ b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
**Applies to**
- Windows 10
-This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 is not secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMB v1 is not installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
+This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMB v1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (always)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. Fore more information, see [Microsoft network server: Digitally sign communications (always)](microsoft-network-server-digitally-sign-communications-always.md).
@@ -34,9 +34,9 @@ This policy setting determines whether SMB packet signing must be negotiated bef
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). Devices that have this policy set will not be able to communicate with devices that do not have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers. Server-side packet signing can be enabled on devices by setting [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
+For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md). Devices that have this policy set won't be able to communicate with devices that don't have server-side packet signing enabled. By default, server-side packet signing is enabled only on domain controllers. Server-side packet signing can be enabled on devices by setting [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
+If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client devices that have SMB signing enabled.
@@ -88,7 +88,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
@@ -98,7 +98,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 NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
+SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place.
### Countermeasure
@@ -109,15 +109,15 @@ Configure the settings as follows:
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
- Enable [Microsoft network server: Digitally sign communications (if client agrees)](smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md).
-In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
+In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
>**Note:** An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
### Potential impact
-Implementations of the SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
+Implementations of the SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking attacks.
+Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, devices are vulnerable to session-hijacking attacks.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md
index 228cd2ec2b..75a325c3b4 100644
--- a/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md
+++ b/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-if-client-agrees.md
@@ -23,7 +23,7 @@ ms.technology: windows-sec
**Applies to**
- Windows 10
-This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 is not secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 is not installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
+This topic is about the Server Message Block (SMB) v1 protocol. SMBv1 isn't secure and has been deprecated in Windows. Beginning with Windows 10 Fall Creators Update and Windows Server, version 1709, [SMBv1 isn't installed by default](/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows).
The rest of this topic describes the best practices, location, values, policy management and security considerations for the **Microsoft network server: Digitally sign communications (if client agrees)** security policy setting only for SMBv1. The same policy setting can be applied to computers that run SMBv2. For more information, see [Microsoft network server: Digitally sign communications (if client agrees)](microsoft-network-server-digitally-sign-communications-always.md).
@@ -34,7 +34,7 @@ This policy setting determines whether SMB packet signing must be negotiated bef
Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
-If server-side SMB signing is required, a client device will not be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device will not be able to establish a session with servers that do not have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
+If server-side SMB signing is required, a client device won't be able to establish a session with that server, unless it has client-side SMB signing enabled. By default, client-side SMB signing is enabled on workstations, servers, and domain controllers. Similarly, if client-side SMB signing is required, that client device won't be able to establish a session with servers that don't have packet signing enabled. By default, server-side SMB signing is enabled only on domain controllers.
If server-side SMB signing is enabled, SMB packet signing will be negotiated with client computers that have SMB signing enabled.
@@ -87,7 +87,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
@@ -97,7 +97,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 computer after legitimate authentication and gain unauthorized access to data.
-SMB is the resource-sharing protocol that is supported by many Windows operating systems. It is the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission does not take place.
+SMB is the resource-sharing protocol that is supported by many Windows operating systems. It's the basis of NetBIOS and many other protocols. SMB signatures authenticate users and the servers that host the data. If either side fails the authentication process, data transmission doesn't take place.
### Countermeasure
@@ -108,15 +108,15 @@ Configure the settings as follows:
- Enable [Microsoft network client: Digitally sign communications (if server agrees)](smbv1-microsoft-network-client-digitally-sign-communications-if-server-agrees.md).
- Enable **Microsoft network server: Digitally sign communications (if client agrees)**.
-In highly secure environments we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
+In highly secure environments, we recommend that you configure all of these settings to Enabled. However, that configuration may cause slower performance on client devices and prevent communications with earlier SMB applications and operating systems.
>**Note:** An alternative countermeasure that could protect all network traffic is to implement digital signatures with IPsec. There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact on the servers' CPUs. No such accelerators are available for SMB signing.
### Potential impact
-SMB file and print-sharing protocol support mutual authentication. This prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
+SMB file and print-sharing protocol support mutual authentication. This mutual authentication prevents session hijacking attacks and supports message authentication to prevent man-in-the-middle attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by the client and the server.
-Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems cannot connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
+Implementation of SMB signing may negatively affect performance because each packet must be signed and verified. If these settings are enabled on a server that is performing multiple roles, such as a small business server that is serving as a domain controller, file server, print server, and application server, performance may be substantially slowed. Additionally, if you configure computers to ignore all unsigned SMB communications, older applications and operating systems can't connect. However, if you completely disable all SMB signing, computers are vulnerable to session-hijacking attacks.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md b/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md
index ea2f55d403..316d4868dd 100644
--- a/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md
+++ b/windows/security/threat-protection/security-policy-settings/store-passwords-using-reversible-encryption.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, and security considerations for
## Reference
-The **Store password using reversible encryption** policy setting provides support for applications that use protocols that require the user's password for authentication. Storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then log on to network resources by using the compromised account. For this reason, never enable **Store password using reversible encryption** for all users in the domain unless application requirements outweigh the need to protect password information.
+The **Store password using reversible encryption** policy setting provides support for applications that use protocols that require the user's password for authentication. Storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then sign in to network resources by using the compromised account. For this reason, never enable **Store password using reversible encryption** for all users in the domain unless application requirements outweigh the need to protect password information.
If you use the Challenge Handshake Authentication Protocol (CHAP) through remote access or Internet Authentication Services (IAS), you must enable this policy setting. CHAP is an authentication protocol that is used by remote access and network connections. Digest Authentication in Internet
Information Services (IIS) also requires that you enable this policy setting.
@@ -39,7 +39,7 @@ Information Services (IIS) also requires that you enable this policy setting.
### Best practices
-Set the value for **Store password using reversible encryption** to Disabled. If you use CHAP through remote access or IAS, or Digest Authentication in IIS, you must set this value to **Enabled**. This presents a security risk when you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate user account object in Active Directory Users and Computers.
+Set the value for **Store password using reversible encryption** to Disabled. If you use CHAP through remote access or IAS, or Digest Authentication in IIS, you must set this value to **Enabled**. This setting presents a security risk when you apply the setting by using Group Policy on a user-by-user basis because it requires opening the appropriate user account object in Active Directory Users and Computers.
>**Note:** Do not enable this policy setting unless business requirements outweigh the need to protect password information.
@@ -77,7 +77,7 @@ Disable the **Store password using reversible encryption** policy setting.
### Potential impact
-If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure this policy setting to Enabled. This presents a security risk when you apply the setting through Group Policy on a user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
+If your organization uses CHAP through remote access or IAS, or Digest Authentication in IIS, you must configure this policy setting to Enabled. This setting presents a security risk when you apply the setting through Group Policy on a user-by-user basis because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md b/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md
index 88f07c4037..e6e95159e1 100644
--- a/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md
+++ b/windows/security/threat-protection/security-policy-settings/synchronize-directory-service-data.md
@@ -46,7 +46,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
### Default values
-By default this setting is not defined on domain controllers and on stand-alone servers.
+By default this setting isn't defined on domain controllers and on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policy’s property page.
@@ -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.
@@ -84,7 +84,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-The **Synchronize directory service data** user right affects domain controllers (only domain controllers should be able to synchronize directory service data). Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. Attackers who have this user right can view all information that is stored within the directory. They could then use some of that information to facilitate additional attacks or expose sensitive data, such as direct telephone numbers or physical addresses.
+The **Synchronize directory service data** user right affects domain controllers (only domain controllers should be able to synchronize directory service data). Domain controllers have this user right inherently because the synchronization process runs in the context of the **System** account on domain controllers. Attackers who have this user right can view all information that is stored within the directory. They could then use some of that information to facilitate more attacks or expose sensitive data, such as direct telephone numbers or physical addresses.
### Countermeasure
diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
index d5dd1f683e..7e0e17cc6d 100644
--- a/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
+++ b/windows/security/threat-protection/security-policy-settings/system-cryptography-force-strong-key-protection-for-user-keys-stored-on-the-computer.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management and security c
This policy setting determines whether users can use private keys, such as their Secure/Multipurpose Internet Mail Extensions (S/MIME) key, without a password.
-Configuring this policy setting so that users must provide a password every time they use a key (in addition to their domain password) makes it more difficult for a malicious user to access locally-stored user keys, even if the attacker takes control of the user's device and determines their logon password.
+Configuring this policy setting so that users must provide a password every time they use a key (in addition to their domain password) makes it more difficult for a malicious user to access locally stored user keys, even if the attacker takes control of the user's device and determines their sign-in password.
### Possible values
@@ -40,7 +40,7 @@ Configuring this policy setting so that users must provide a password every time
### Best practices
-- Set this policy to **User must enter a password each time they use a key**. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they will be forced to enter the password for that certificate every time they send a signed email message. For some organizations, the overhead that is caused by using this value might be too high, but they should set the value at a minimum to **User is prompted when the key is first used**.
+- Set this policy to **User must enter a password each time they use a key**. Users must enter their password every time they access a key that is stored on their computer. For example, if users use an S/MIME certificate to digitally sign their email, they'll be forced to enter the password for that certificate every time they send a signed email message. For some organizations, the overhead that is caused by using this value might be too high, but they should set the value at a minimum to **User is prompted when the key is first used**.
### Location
@@ -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
@@ -77,11 +77,11 @@ If a user's account is compromised or the user's device is inadvertently left un
### Countermeasure
-Configure the **System cryptography: Force strong key protection for user keys stored on the computer** setting to **User must enter a password each time they use a key** so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the logon password.
+Configure the **System cryptography: Force strong key protection for user keys stored on the computer** setting to **User must enter a password each time they use a key** so that users must provide a password that is distinct from their domain password every time they use a key. This configuration makes it more difficult for an attacker to access locally stored user keys, even if the attacker takes control of the user's computer and determines the sign-in password.
### Potential impact
-Users must type their password every time they access a key that is stored on their device. For example, if users use an S/MIME certificate to digitally sign their email, they are forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this setting should be set to **User is prompted when the key is first used**.
+Users must type their password every time they access a key that is stored on their device. For example, if users use an S/MIME certificate to digitally sign their email, they're forced to type the password for that certificate every time they send a signed email message. For some organizations, the overhead that is involved by using this configuration may be too high. At a minimum, this setting should be set to **User is prompted when the key is first used**.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md b/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
index e98291ef6b..e38443c02b 100644
--- a/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
+++ b/windows/security/threat-protection/security-policy-settings/system-cryptography-use-fips-compliant-algorithms-for-encryption-hashing-and-signing.md
@@ -57,7 +57,7 @@ Additionally, if a data drive is password-protected, it can be accessed by a FIP
### Best practices
-We recommend that customers hoping to comply with FIPS 140-2 research the configuration settings of applications and protocols they may be using to ensure their solutions can be configured to utilize the FIPS 140-2 validated cryptography provided by Windows when it is operating in FIPS 140-2 approved mode.
+We recommend that customers hoping to comply with FIPS 140-2 research the configuration settings of applications and protocols they may be using to ensure their solutions can be configured to utilize the FIPS 140-2 validated cryptography provided by Windows when it's operating in FIPS 140-2 approved mode.
For a complete list of Microsoft-recommended configuration settings, see [Windows security baselines](../windows-security-baselines.md). For more information about Windows and FIPS 140-2, see [FIPS 140 Validation](../fips-140-validation.md).
@@ -82,11 +82,11 @@ The following table lists the actual and effective default values for this polic
When this setting is enabled, the Encrypting File System (EFS) service supports only the Triple DES encryption algorithm for encrypting file data. By default, the Windows Vista and the Windows Server 2003 implementation of EFS uses the Advanced Encryption Standard (AES) with a 256-bit key. The Windows XP implementation uses DESX.
-When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to versions listed in the following:
+When this setting is enabled, BitLocker generates recovery password or recovery keys applicable to the following versions:
| Operating systems | Applicability |
| - | - |
-| Windows 10, Windows 8.1, and Windows Server 2012 R2| When created on these operating systems, the recovery password cannot be used on other systems listed in this table.|
+| Windows 10, Windows 8.1, and Windows Server 2012 R2| When created on these operating systems, the recovery password can't be used on other systems listed in this table.|
| Windows Server 2012 and Windows 8 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
| Windows Server 2008 R2 and Windows 7 | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
| Windows Server 2008 and Windows Vista | When created on these operating systems, the recovery key can be used on other systems listed in this table as well.|
@@ -97,7 +97,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
@@ -117,8 +117,8 @@ Enable the **System cryptography: Use FIPS compliant algorithms for encryption,
### Potential impact
-Client devices that have this policy setting enabled cannot communicate by means of digitally encrypted or signed protocols with servers that do not support these algorithms. Network clients that do not support these algorithms cannot use servers that require them for network communications. For example, many Apache-based Web servers are not configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool
-uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices are not configured to use the same encryption algorithms.
+Client devices that have this policy setting enabled can't communicate through digitally encrypted or signed protocols with servers that don't support these algorithms. Network clients that don't support these algorithms can't use servers that require them for network communications. For example, many Apache-based Web servers aren't configured to support TLS. If you enable this setting, you must also configure Internet Explorer® to use TLS. This policy setting also affects the encryption level that is used for the Remote Desktop Protocol (RDP). The Remote Desktop Connection tool
+uses the RDP protocol to communicate with servers that run Terminal Services and client computers that are configured for remote control; RDP connections fail if both devices aren't configured to use the same encryption algorithms.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
index 3a9ceb4840..9c7c2c4433 100644
--- a/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
+++ b/windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md
@@ -27,9 +27,9 @@ Describes the best practices, location, values, policy management, and security
## Reference
-This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem is not case sensitive; however, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting does not allow the Win32 subsystem to become case sensitive.
+This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft Win32 subsystem isn't case sensitive; however, the kernel supports case sensitivity for other subsystems, such as Portable Operating System Interface for UNIX (POSIX). Enabling this policy setting enforces case insensitivity for all directory objects, symbolic links, and input/output (I/O) objects, including file objects. Disabling this policy setting doesn't allow the Win32 subsystem to become case sensitive.
-Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting is not enforced, it is possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available.
+Because Windows is case insensitive but the POSIX subsystem will support case sensitivity, if this policy setting isn't enforced, it's possible for a user of that subsystem to create a file with the same name as another file but with a different mix of capital letters. That convention might confuse users when they try to access these files by using normal Win32 tools, because only one of the files will be available.
### Possible values
@@ -39,13 +39,13 @@ Because Windows is case insensitive but the POSIX subsystem will support case se
- Disabled
- Will not allow the Win32 subsystem to become case sensitive.
+ Won't allow the Win32 subsystem to become case sensitive.
- Not defined
### Best practices
-- Set this policy to **Enabled**. All subsystems will be forced to observe case insensitivity. However, this might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive operating system.
+- Set this policy to **Enabled**. All subsystems will be forced to observe case insensitivity. However, this insensitivity might confuse users who are familiar with one of the UNIX-based operating systems and are used to a case sensitive operating system.
### 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
diff --git a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md b/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md
index abd9724c03..71e2fa8221 100644
--- a/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md
+++ b/windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md
@@ -1,6 +1,6 @@
---
-title: System objects Strengthen default permissions of internal system objects (e.g., Symbolic Links) (Windows 10)
-description: Best practices and more for the security policy setting, System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links).
+title: System objects Strengthen default permissions of internal system objects (for example, Symbolic Links) (Windows 10)
+description: Best practices and more for the security policy setting, System objects Strengthen default permissions of internal system objects (for example, Symbolic Links).
ms.assetid: 3a592097-9cf5-4fd0-a504-7cbfab050bb6
ms.reviewer:
ms.author: dansimp
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management and security c
## Reference
-This policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. By using this list, processes can locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who are not administrators to read, but not to modify, shared objects that they did not create.
+This policy setting determines the strength of the default discretionary access control list (DACL) for objects. Windows maintains a global list of shared system resources such as MS-DOS device names, mutexes, and semaphores. The processes use this list to locate and share objects. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. Enabling this policy setting strengthens the default DACL and allows users who aren't administrators to read, but not to modify, shared objects that they didn't create.
### Possible values
@@ -37,7 +37,7 @@ This policy setting determines the strength of the default discretionary access
### Best practices
-- It is advisable to set this policy to **Enabled**.
+- It's advisable to set this policy to **Enabled**.
### Location
@@ -62,7 +62,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
@@ -70,7 +70,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this setting is disabled, it is possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten. Enabling **System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)** prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they did not create.
+This policy setting is enabled by default to protect against a known vulnerability that can be used with hard links or symbolic links. Hard links are actual directory entries in the file system. With hard links, the same data in a file system can be referred to by different file names. Symbolic links are text files that provide a pointer to the file that is interpreted and followed by the operating system as a path to another file or directory. Because symbolic links are a separate file, they can exist independently of the target location. If a symbolic link is deleted, its target location remains unaffected. When this setting is disabled, it's possible for a malicious user to destroy a data file by creating a link that looks like a temporary file that the system automatically creates, such as a sequentially named log file, but it points to the data file that the malicious user wants to eradicate. When the system writes the files with that name, the data is overwritten. Enabling **System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links)** prevents an attacker from exploiting programs that create files with predictable names by not allowing them to write to objects that they didn't create.
### Countermeasure
@@ -78,7 +78,7 @@ Enable the **System objects: Strengthen default permissions of global system obj
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md b/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md
index a271d9f87f..8db727008d 100644
--- a/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md
+++ b/windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management, and security
This policy setting determines which subsystems support your applications. You can use this security setting to specify as many subsystems as your environment demands.
-The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a user starts a process and then logs out, the next user who logs on to the system might access the process that the previous user started. This is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything that the second user does using that process is performed with the user rights of the first user. This makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics.
+The subsystem introduces a security risk that is related to processes that can potentially persist across logons. If a user starts a process and then signs out, the next user who signs in to the system might access the process that the previous user started. This pattern is dangerous, because the process started by the first user can retain that user's system user rights; therefore, anything that the second user does using that process is performed with the user rights of the first user. This privileges rollover makes it difficult to trace who creates processes and objects, which is essential for post-security incident forensics.
### Possible values
@@ -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.
## Security considerations
@@ -73,7 +73,7 @@ This section describes how an attacker might exploit a feature or its configurat
The POSIX subsystem is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services. The POSIX subsystem is required if the server supports applications that use that subsystem.
-The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across logons. If a user starts a process and then logs out, there is a potential that the next user who logs on to the computer could access the previous user's process. This would allow the second user to take actions on the process by using the privileges of the first user.
+The POSIX subsystem introduces a security risk that relates to processes that can potentially persist across sign-ins. If a user starts a process and then signs out, there's a potential that the next user who signs in to the computer could access the previous user's process. This accessibility would allow the second user to take actions on the process by using the privileges of the first user.
### Countermeasure
diff --git a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md b/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
index 9791d8a12d..e58a8d0925 100644
--- a/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
+++ b/windows/security/threat-protection/security-policy-settings/system-settings-use-certificate-rules-on-windows-executables-for-software-restriction-policies.md
@@ -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.
## Security considerations
diff --git a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md b/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md
index c4781f258c..b3272708b2 100644
--- a/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md
+++ b/windows/security/threat-protection/security-policy-settings/take-ownership-of-files-or-other-objects.md
@@ -31,7 +31,7 @@ This policy setting determines which users can take ownership of any securable o
Every object has an owner, whether the object resides in an NTFS volume or Active Directory database. The owner controls how permissions are set on the object and to whom permissions are granted.
-By default, the owner is the person who or the process which created the object. Owners can always change permissions to objects, even when they are denied all access to the object.
+By default, the owner is the person who or the process that created the object. Owners can always change permissions to objects, even when they're denied all access to the object.
Constant: SeTakeOwnershipPrivilege
@@ -67,7 +67,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.
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md b/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
index 16e00a82f8..d6d32d8a08 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account.md
@@ -27,7 +27,7 @@ Describes the best practices, location, values, policy management and security c
## Reference
This policy setting determines the behavior of Admin Approval Mode for the built-in administrator account.
-When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode is not enabled, the built-in Administrator account runs all applications by default with full administrative privileges. By default, Admin Approval Mode is set to **Disabled**.
+When the Admin Approval Mode is enabled, the local administrator account functions like a standard user account, but it has the ability to elevate privileges without logging on by using a different account. In this mode, any operation that requires elevation of privilege displays a prompt that allows the administrator to permit or deny the elevation of privilege. If Admin Approval Mode isn't enabled, the built-in Administrator account runs all applications by default with full administrative privileges. By default, Admin Approval Mode is set to **Disabled**.
> [!NOTE]
> If a computer is upgraded from a previous version of the Windows operating system, and the administrator account is the only account on the computer, the built-in administrator account remains enabled, and this setting is also enabled.
@@ -40,11 +40,11 @@ When the Admin Approval Mode is enabled, the local administrator account functio
- Disabled
- If Admin Approval Mode is not enabled, the built-in Administrator account runs all applications by default with full administrative privileges
+ If Admin Approval Mode isn't enabled, the built-in Administrator account runs all applications by default with full administrative privileges
### Best practices
-- It is recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. See [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)
+- It's recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. See [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)
To enable Admin Approval Mode, you must also configure the local security policy setting: [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](/windows/device-security/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) to **Prompt for consent on the secure desktop** and then click OK.
@@ -74,7 +74,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
@@ -82,7 +82,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the Administrator account because that user account was created for all installations of Windows. To address this risk, the built-in Administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the Administrator account is enabled, and the password must be changed the first time the administrator logs on. In a default installation of a computer running at least Windows Vista, if the computer is not joined to a domain, the first user account you create has the equivalent permissions of a local administrator.
+One of the risks that the UAC feature tries to mitigate is that of malicious software running under elevated credentials without the user or administrator being aware of its activity. An attack vector for malicious programs is to discover the password of the Administrator account because that user account was created for all installations of Windows. To address this risk, the built-in Administrator account is disabled in computers running at least Windows Vista. In computers running at least Windows Server 2008, the Administrator account is enabled, and the password must be changed the first time the administrator logs on. In a default installation of a computer running at least Windows Vista, if the computer isn't joined to a domain, the first user account you create has the equivalent permissions of a local administrator.
### Countermeasure
@@ -90,7 +90,7 @@ Enable the **User Account Control: Admin Approval Mode for the Built-in Administ
### Potential impact
-Users who log on by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege.
+Users who sign in by using the local administrator account are prompted for consent whenever a program requests an elevation in privilege.
## Related topics
- [Security Options](/windows/device-security/security-policy-settings/security-options)
\ No newline at end of file
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md b/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
index 8526a457ae..4ade31f9ed 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md
@@ -91,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 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
@@ -99,7 +99,7 @@ All auditing capabilities are integrated in Group Policy. You can configure, dep
### Policy interactions
-If you plan to enable this setting, you should also review the effect of the [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md) setting. If it is configured as **Automatically deny elevation requests**, elevation requests are not presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled.
+If you plan to enable this setting, you should also review the effect of the [User Account Control: Behavior of the elevation prompt for standard users](user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md) setting. If it's configured as **Automatically deny elevation requests**, elevation requests aren't presented to the user. If you disable this setting, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the [User Account Control: Switch to the secure desktop when prompting for elevation](user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md) setting, which by default is enabled.
## Security considerations
@@ -107,13 +107,13 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
-UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation requests to appear on the regular interactive desktop instead of on the secure desktop. This increases the risk that a malicious program could intercept data that is being transferred between the UI and the application. Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:
+UIA programs are designed to interact with Windows and application programs on behalf of a user. This setting allows UIA programs to bypass the secure desktop to increase usability in certain cases, but it allows elevation requests to appear on the regular interactive desktop instead of on the secure desktop. This requests-appearance increases the risk that a malicious program could intercept data that is being transferred between the UI and the application. Because UIA programs must be able to respond to prompts regarding security issues, such as the UAC elevation prompt, UIA programs must be highly trusted. To be considered trusted, a UIA program must be digitally signed. By default, UIA programs can be run only from the following protected paths:
- ..\\Program Files\\ (and subfolders)
- ..\\Program Files (x86)\\ (and subfolders, in 64-bit versions of Windows only)
- ..\\Windows\\System32\\
-The requirement to be in a protected path can be disabled by the [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md) setting. Although this setting applies to any UIA program, it is used primarily in certain Windows Remote Assistance scenarios.
+The requirement to be in a protected path can be disabled by the [User Account Control: Only elevate UIAccess applications that are installed in secure locations](user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md) setting. Although this setting applies to any UIA program, it's used primarily in certain Windows Remote Assistance scenarios.
### Countermeasure
From 639ed4ca6e577247ce458917360ce18dca836095 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Thu, 30 Jun 2022 17:57:54 +0530
Subject: [PATCH 017/299] Acrolinx Enhancement Effort
---
...r-administrators-in-admin-approval-mode.md | 16 +--
...the-elevation-prompt-for-standard-users.md | 12 +-
...-installations-and-prompt-for-elevation.md | 4 +-
...ecutables-that-are-signed-and-validated.md | 12 +-
...-that-are-installed-in-secure-locations.md | 6 +-
...l-administrators-in-admin-approval-mode.md | 2 +-
...re-desktop-when-prompting-for-elevation.md | 6 +-
...ry-write-failures-to-per-user-locations.md | 8 +-
...arding-to-assist-in-intrusion-detection.md | 112 +++++++++---------
.../LOB-win32-apps-on-s.md | 16 +--
...ows-defender-application-control-policy.md | 10 +-
...ged-apps-to-existing-applocker-rule-set.md | 2 +-
.../applocker-architecture-and-components.md | 2 +-
.../applocker/applocker-overview.md | 18 +--
.../applocker-policies-deployment-guide.md | 2 +-
.../applocker-policies-design-guide.md | 8 +-
.../applocker-policy-use-scenarios.md | 13 +-
.../applocker-processes-and-interactions.md | 8 +-
...e-an-applocker-policy-for-enforce-rules.md | 2 +-
...onfigure-the-appLocker-reference-device.md | 8 +-
20 files changed, 133 insertions(+), 134 deletions(-)
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
index e653550846..06252b3d4a 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode.md
@@ -33,9 +33,9 @@ This policy setting determines the behavior of the elevation prompt for accounts
- **Elevate without prompting**
- Assumes that the administrator will permit an operation that requires elevation, and additional consent or credentials are not required.
+ Assumes that the administrator will permit an operation that requires elevation, and more consent or credentials aren't required.
- **Note** Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
+ **Note** Selecting **Elevate without prompting** minimizes the protection that is provided by UAC. We don't recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
- **Prompt for credentials on the secure desktop**
@@ -55,18 +55,18 @@ This policy setting determines the behavior of the elevation prompt for accounts
- **Prompt for consent for non-Windows binaries**
- This is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.
+ This prompt for consent is the default. When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select **Permit** or **Deny**. If the user selects **Permit**, the operation continues with the user's highest available privilege.
-\*If you have enabled the built-in Administrator account and have configured Admin Approval Mode, you must also configure the option **Prompt for consent on the secure desktop**. You can also configure this option from User Account Control, by typing **UAC** in the search box. From the User Account Control Settings dialog box, set the slider control to **Notify me only when apps try to make changes to my computer (default)**.
+\*If you've enabled the built-in Administrator account and have configured Admin Approval Mode, you must also configure the option **Prompt for consent on the secure desktop**. You can also configure this option from User Account Control, by typing **UAC** in the search box. From the User Account Control Settings dialog box, set the slider control to **Notify me only when apps try to make changes to my computer (default)**.
> [!NOTE]
> After enabling Admin Approval Mode, to activate the setting, you must first log in and out. Alternatively, You may perform **gpupdate /force** from an elevated command prompt.
### Best practices
-- Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We do not recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
+- Selecting the option **Elevate without prompting** minimizes the protection that is provided by UAC. We don't recommend selecting this value unless administrator accounts are tightly controlled and the operating environment is highly secure.
-- It is recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. For further information, see [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)
+- It's recommended not to enable the built-in Administrator account on the client computer, but to use the standard user account and User Account Control (UAC) instead. If you want to enable the built-in Administrator account to carry out administrative tasks, for security reasons you should also enable Admin Approval Mode. For more information, see [UAC-Admin-Approval-Mode-for-the-Built-in-Administrator-account](/windows/device-security/security-policy-settings/user-account-control-admin-approval-mode-for-the-built-in-administrator-account)
### Location
@@ -90,7 +90,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.
### Group Policy
@@ -110,7 +110,7 @@ Configure the **User Account Control: Behavior of the elevation prompt for admin
### Potential impact
-Administrators should be made aware that they will be prompted for consent when all binaries attempt to run.
+Administrators should be made aware that they'll be prompted for consent when all binaries attempt to run.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
index 48f2dfa8c7..dcc2829197 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-behavior-of-the-elevation-prompt-for-standard-users.md
@@ -37,7 +37,7 @@ This policy setting determines the behavior of the elevation prompt for standard
- **Prompt for credentials on the secure desktop**
- This is the default. When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
+ This prompt for credentials is the default. When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
- **Prompt for credentials**
@@ -45,8 +45,8 @@ This policy setting determines the behavior of the elevation prompt for standard
### Best practices
-1. Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege.
-2. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, set **Prompt for credentials on the secure desktop** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account.
+1. Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to sign in with an administrative account to run programs that require elevation of privilege.
+2. As a security best practice, standard users shouldn't have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, set **Prompt for credentials on the secure desktop** so that the users don't choose to always sign in with their administrator accounts, and they shift their behavior to use the standard user account.
### Location
@@ -71,7 +71,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.
### Group Policy
@@ -87,11 +87,11 @@ One of the risks that the UAC feature tries to mitigate is that of malicious pro
### Countermeasure
-Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to log on with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users should not have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting **Prompt for credentials** so that the users do not choose to always log on with their administrator accounts, and they shift their behavior to use the standard user account.
+Configure the **User Account Control: Behavior of the elevation prompt for standard users** to **Automatically deny elevation requests**. This setting requires the user to sign in with an administrative account to run programs that require elevation of privilege. As a security best practice, standard users shouldn't have knowledge of administrative passwords. However, if your users have both standard and administrator-level accounts, we recommend setting **Prompt for credentials** so that the users don't choose to always sign in with their administrator accounts, and they shift their behavior to use the standard user account.
### Potential impact
-Users must provide administrative passwords to run programs with elevated privileges. This could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations.
+Users must provide administrative passwords to run programs with elevated privileges. This impact could cause an increased load on IT staff while the programs that are affected are identified and standard operating procedures are modified to support least privilege operations.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md
index 431ac04a15..53b87039e9 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-detect-application-installations-and-prompt-for-elevation.md
@@ -38,7 +38,7 @@ Some software might attempt to install itself after being given permission to ru
- **Disabled**
- Application installation packages that require an elevation of privilege to install are not detected and the user is not prompted for administrative credentials.
+ Application installation packages that require an elevation of privilege to install aren't detected and the user isn't prompted for administrative credentials.
### Best practices
@@ -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.
## Security considerations
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
index 242580312c..0f83be229f 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md
@@ -31,18 +31,18 @@ This policy setting enforces public key infrastructure (PKI) signature checks on
A trusted publisher is a certificate issuer that the computer’s user has chosen to trust and that has certificate details that have been added to the store of trusted publishers.
-Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated with the computer object or they are owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores. A certificate store will often contain numerous certificates, possibly issued from a number of different certification authorities (CAs).
+Windows maintains certificates in certificate stores. These stores can be represented by containers in the file system or the registry, or they can be implemented as physical stores such as smart cards. Certificate stores are associated with the computer object or they're owned by a distinct user who has a security context and profile on that computer. In addition, services can have certificate stores. A certificate store will often contain numerous certificates, possibly issued from many different certification authorities (CAs).
When certificate path discovery is initiated, Windows attempts to locate the issuing CA for the certificates, and it builds a certificate path to the trusted root certificate. Intermediate certificates are included as part of the application protocol or are picked up from Group Policy or through URLs that are specified in the Authority Information Access (AIA) extension. When the path is built, each certificate in the path is verified for validity with respect to various parameters, such as name, time, signature, revocation status, and other constraints.
### Possible values
- **Enabled**
- Enforces the PKI certificate chain validation of a given executable file before it is permitted to run.
+ Enforces the PKI certificate chain validation of a given executable file before it's permitted to run.
- **Disabled**
- Does not enforce PKI certificate chain validation before a given executable file is permitted to run.
+ Doesn't enforce PKI certificate chain validation before a given executable file is permitted to run.
### Best practices
@@ -71,7 +71,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.
### Group Policy
@@ -91,8 +91,8 @@ Enable the **User Account Control: Only elevate executables that are signed and
### Potential impact
-Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications are not signed, and they cannot be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting.
-Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is provided by this setting is not an assurance that all rogue applications will be found.
+Enabling this setting requires that you have a PKI infrastructure and that your enterprise administrators have populated the Trusted Publishers store with the certificates for the allowed applications. Some older applications aren't signed, and they can't be used in an environment that is hardened with this setting. You should carefully test your applications in a preproduction environment before implementing this setting.
+Control over the applications that are installed on the desktops and the hardware that joins your domain should provide similar protection from the vulnerability that is addressed by this setting. Additionally, the level of protection that is provided by this setting isn't an assurance that all rogue applications will be found.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
index 76a8bc97a2..2c36882505 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md
@@ -59,7 +59,7 @@ If an application presents a UIAccess attribute when it requests privileges, the
- **Disabled**
- An application can start with UIAccess integrity even if it does not reside in a secure location in the file system.
+ An application can start with UIAccess integrity even if it doesn't reside in a secure location in the file system.
### Best practices
@@ -103,7 +103,7 @@ This section describes:
### Vulnerability
-UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that transmit user interfaces to alternative forms. But it's not required by most applications. A process that's started with UIAccess rights has the following abilities:
+UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as sign-in prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that transmit user interfaces to alternative forms. But it's not required by most applications. A process that's started with UIAccess rights has the following abilities:
- Set the foreground window.
- Drive any application window by using the SendInput function.
@@ -117,7 +117,7 @@ Enable the **User Account Control: Only elevate UIAccess applications that are i
### Potential impact
-If the application that requests UIAccess meets the UIAccess setting requirements, computers that run at least the Windows Vista operating system start the application with the ability to bypass most UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
+If the application that requests UIAccess meets the UIAccess setting requirements, computers that run at least the Windows Vista operating system start the application with the ability to bypass most UIPI restrictions. If the application doesn't meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
## Related articles
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md b/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md
index 6760e38f5a..3d53a0a2f4 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-run-all-administrators-in-admin-approval-mode.md
@@ -27,7 +27,7 @@ This article describes the best practices, location, values, policy management a
## Reference
-This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This is the setting that turns UAC on or off.
+This policy setting determines the behavior of all User Account Control (UAC) policies for the entire system. This setting is the one that turns on or off the UAC.
### Possible values
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md b/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
index 5eb4fbd4e9..15ef6860e1 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management and security c
This policy setting determines whether the elevation request prompts on the interactive user desktop or on the secure desktop.
-The secure desktop presents the logon UI and restricts functionality and access to the system until the logon requirements are satisfied.
+The secure desktop presents the sign-in UI and restricts functionality and access to the system until the sign-in requirements are satisfied.
The secure desktop’s primary difference from the user desktop is that only trusted processes running as SYSTEM are allowed to run here (that is, nothing is running at the user’s privilege level). The path to get to the secure desktop from the user desktop must also be trusted through the entire chain.
@@ -71,7 +71,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
@@ -91,7 +91,7 @@ Enable the **User Account Control: Switch to the secure desktop when prompting f
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md b/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
index dda6b18a18..97de8498ea 100644
--- a/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
+++ b/windows/security/threat-protection/security-policy-settings/user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations.md
@@ -29,7 +29,7 @@ Describes the best practices, location, values, policy management and security c
This policy setting enables or disables the redirection of the write failures of earlier applications to defined locations in the registry and the file system. This feature mitigates applications that historically ran as administrator and wrote runtime application data to %ProgramFiles%, %Windir%, %Windir%\\system32, or HKEY\_LOCAL\_MACHINE\\Software\\.
-This feature can be disabled for applications on devices running at least Windows Vista because it is unnecessary.
+This feature can be disabled for applications on devices running at least Windows Vista because it's unnecessary.
### Possible values
@@ -43,7 +43,7 @@ This feature can be disabled for applications on devices running at least Window
### Best practices
-1. If you run applications that are not Windows Vista-compliant, enable this security policy to prevent the possibility that these older applications could write data to unsecure locations.
+1. If you run applications that aren't Windows Vista-compliant, enable this security policy to prevent the possibility that these older applications could write data to unsecure locations.
2. If you only run at least Windows Vista–compliant applications, this feature is unnecessary so you can disable this policy.
### 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.
### Group Policy
@@ -89,7 +89,7 @@ Enable the **User Account Control: Virtualize file and registry write failures t
### Potential impact
-None. This is the default configuration.
+None. This non-impact state is the default configuration.
## Related topics
diff --git a/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md b/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
index 411b14fcba..8eabd03b34 100644
--- a/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
+++ b/windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
@@ -23,7 +23,7 @@ Windows Event Forwarding (WEF) reads any operational or administrative event log
To accomplish this functionality, there are two different subscriptions published to client devices - the Baseline subscription and the suspect subscription. The Baseline subscription enrolls all devices in your organization, and a Suspect subscription only includes devices that have been added by you. The Suspect subscription collects more events to help build context for system activity and can quickly be updated to accommodate new events and/or scenarios as needed without impacting baseline operations.
-This implementation helps differentiate where events are ultimately stored. Baseline events can be sent to devices with online analytical capability, such as Security Event Manager (SEM), while also sending events to a MapReduce system, such as HDInsight or Hadoop, for long-term storage and deeper analysis. Events from the Suspect subscription are sent directly to a MapReduce system due to volume and lower signal/noise ratio, they are largely used for host forensic analysis.
+This implementation helps differentiate where events are ultimately stored. Baseline events can be sent to devices with online analytical capability, such as Security Event Manager (SEM), while also sending events to a MapReduce system, such as HDInsight or Hadoop, for long-term storage and deeper analysis. Events from the Suspect subscription are sent directly to a MapReduce system due to volume and lower signal/noise ratio, they're largely used for host forensic analysis.
An SEM’s strength lies in being able to inspect, correlate events, and generate alerts for known patterns manner and alert security staff at machine speed.
@@ -37,7 +37,7 @@ Here's an approximate scaling guide for WEF events:
| 5,000 - 50,000 | SEM |
| 50,000+ | Hadoop/HDInsight/Data Lake |
-Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This condition is because WEF is a passive system regarding the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling additional event channels and expanding the size of event log files hasn't resulted in noticeable performance differences.
+Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This condition is because WEF is a passive system regarding the event log. It can't change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling more event channels and expanding the size of event log files hasn't resulted in noticeable performance differences.
For the minimum recommended audit policy and registry system ACL settings, see [Appendix A - Minimum recommended minimum audit policy](#bkmk-appendixa) and [Appendix B - Recommended minimum registry system ACL policy](#bkmk-appendixb).
@@ -50,7 +50,7 @@ This system of dual subscription means you would create two base subscriptions:
- **Baseline WEF subscription**. Events collected from all hosts; these events include some role-specific events, which will only be emitted by those machines.
- **Targeted WEF subscription**. Events collected from a limited set of hosts due to unusual activity and/or heightened awareness for those systems.
-Each using the respective event query below. For the Targeted subscription enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client.
+Each using the respective event query below. For the Targeted subscription, enabling the “read existing events” option should be set to true to allow collection of existing events from systems. By default, WEF subscriptions will only forward events generated after the WEF subscription was received by the client.
In [Appendix E – Annotated Baseline Subscription Event Query](#bkmk-appendixe) and [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf), the event query XML is included when creating WEF subscriptions. These subscriptions are annotated for query purpose and clarity. Individual <Query> element can be removed or edited without affecting the rest of the query.
@@ -62,11 +62,11 @@ This section addresses common questions from IT pros and customers.
The short answer is: No.
-The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they won't notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there is an issue with the WEF subscription, there is no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel.
+The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they won't notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there's an issue with the WEF subscription, there's no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel.
### Is WEF Push or Pull?
-A WEF subscription can be configured to be push or pull, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients are to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines.
+A WEF subscription can be configured to be pushed or pulled, but not both. The simplest, most flexible IT deployment with the greatest scalability can be achieved by using a push, or source initiated, subscription. WEF clients are configured by using a GPO and the built-in forwarding client is activated. For pull, collector initiated, the subscription on the WEC server is pre-configured with the names of the WEF Client devices from which events are to be selected. Those clients are to be configured ahead of time to allow the credentials used in the subscription to access their event logs remotely (normally by adding the credential to the **Event Log Readers** built-in local security group.) A useful scenario: closely monitoring a specific set of machines.
### Will WEF work over VPN or RAS?
@@ -75,7 +75,7 @@ WEF handles VPN, RAS, and DirectAccess scenarios well and will reconnect and sen
### How is client progress tracked?
The WEC server maintains in its registry the bookmark information and last heartbeat time for each event source for each WEF subscription. When an event source reconnects to a WEC server, the last bookmark position is sent to the device to use as a starting point to resume forwarding events. If a
-WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it is active. This heartbeat value can be individually configured for each subscription.
+WEF client has no events to send, the WEF client will connect periodically to send a Heartbeat to the WEC server to indicate it's active. This heartbeat value can be individually configured for each subscription.
### Will WEF work in an IPv4, IPv6, or mixed IPv4/IPv6 environment?
@@ -93,12 +93,11 @@ The HTTPS option is available if certificate based authentication is used, in ca
The WEF client machines local event log is the buffer for WEF for when the connection to the WEC server is lost. To increase the “buffer size”, increase the maximum file size of the specific event log file where events are being selected. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
-When the event log overwrites existing events (resulting in data loss if the device isn't connected to the Event Collector), there is no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.
+When the event log overwrites existing events (resulting in data loss if the device isn't connected to the Event Collector), there's no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.
### What format is used for forwarded events?
-WEF has two modes for forwarded events. The default is “Rendered Text” which includes the textual description of the event as you would see it in Event Viewer. This means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is
-“Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This is very compact and can more than double the event volume a single WEC server can accommodate.
+WEF has two modes for forwarded events. The default is “Rendered Text” that includes the textual description of the event as you would see it in Event Viewer. This description's inclusion means that the event size is effectively doubled or tripled depending on the size of the rendered description. The alternative mode is “Events” (also sometimes referred to as “Binary” format) – which is just the event XML itself sent in binary XML format (as it would be written to the evtx file.) This format is compact and can more than double the event volume a single WEC server can accommodate.
A subscription “testSubscription” can be configured to use the Events format through the WECUTIL utility:
@@ -109,19 +108,19 @@ Wecutil ss “testSubscription” /cf:Events
### How frequently are WEF events delivered?
-Event delivery options are part of the WEF subscription configuration parameters – There are three built-in subscription delivery options: Normal, Minimize Bandwidth, and Minimize Latency. A fourth, catch-all called “Custom” is available but cannot be selected or configured through the WEF UI by using Event Viewer. The Custom delivery option must be selected and configured using the WECUTIL.EXE command-line application. All subscription options define a maximum event count and maximum event age, if either limit is exceeded then the accumulated events are sent to the event collector.
+Event delivery options are part of the WEF subscription configuration parameters – There are three built-in subscription delivery options: Normal, Minimize Bandwidth, and Minimize Latency. A fourth, catch-all called “Custom” is available but can't be selected or configured through the WEF UI by using Event Viewer. The Custom delivery option must be selected and configured using the WECUTIL.EXE command-line application. All subscription options define a maximum event count and maximum event age, if either limit is exceeded then the accumulated events are sent to the event collector.
This table outlines the built-in delivery options:
| Event delivery optimization options | Description |
| - | - |
-| Normal | This option ensures reliable delivery of events and doesn't attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. |
-| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. |
-| Minimize latency | This option ensures that events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. |
+| Normal | This option ensures reliable delivery of events and doesn't attempt to conserve bandwidth. It's the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. |
+| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It's an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. |
+| Minimize latency | This option ensures that events are delivered with minimal delay. It's an appropriate choice if you're collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. |
For more info about delivery options, see [Configure Advanced Subscription Settings](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc749167(v=ws.11)).
-The primary difference is in the latency which events are sent from the client. If none of the built-in options meet your requirements you can set Custom event delivery options for a given subscription from an elevated command prompt:
+The primary difference is in the latency which events are sent from the client. If none of the built-in options meet your requirements, you can set Custom event delivery options for a given subscription from an elevated command prompt:
``` syntax
@rem required to set the DeliveryMaxItems or DeliveryMaxLatencyTime
@@ -139,15 +138,15 @@ For collector initiated subscriptions: The subscription contains the list of mac
### Can a client communicate to multiple WEF Event Collectors?
-Yes. If you desire a High-Availability environment, simply configure multiple WEC servers with the same subscription configuration and publish both WEC Server URIs to WEF clients. WEF Clients will forward events simultaneously to the configured subscriptions on the WEC servers, if they have the appropriate access.
+Yes. If you desire a High-Availability environment, configure multiple WEC servers with the same subscription configuration and publish both WEC Server URIs to WEF clients. WEF Clients will forward events simultaneously to the configured subscriptions on the WEC servers, if they have the appropriate access.
### What are the WEC server’s limitations?
There are three factors that limit the scalability of WEC servers. The general rule for a stable WEC server on commodity hardware is planning for a total of 3,000 events per second on average for all configured subscriptions.
- **Disk I/O**. The WEC server doesn't process or validate the received event, but rather buffers the received event and then logs it to a local event log file (EVTX file). The speed of logging to the EVTX file is limited by the disk write speed. Isolating the EVTX file to its own array or using high speed disks can increase the number of events per second that a single WEC server can receive.
-- **Network Connections**. While a WEF source doesn't maintain a permanent, persistent connection to the WEC server, it doesn't immediately disconnect after sending its events. This means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server.
-- **Registry size**. For each unique device that connects to a WEF subscription, there is a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this isn't pruned to remove inactive clients this set of registry keys can grow to an unmanageable size over time.
+- **Network Connections**. While a WEF source doesn't maintain a permanent, persistent connection to the WEC server, it doesn't immediately disconnect after sending its events. This leniency means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server.
+- **Registry size**. For each unique device that connects to a WEF subscription, there's a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this information isn't pruned to remove inactive clients, this set of registry keys can grow to an unmanageable size over time.
- When a subscription has >1000 WEF sources connect to it over its operational lifetime, also known as lifetime WEF sources, Event Viewer can become unresponsive for a few minutes when selecting the **Subscriptions** node in the left-navigation, but will function normally afterwards.
- At >50,000 lifetime WEF sources, Event Viewer is no longer an option and wecutil.exe (included with Windows) must be used to configure and manage subscriptions.
@@ -155,30 +154,30 @@ There are three factors that limit the scalability of WEC servers. The general r
## Subscription information
-Below lists all of the items that each subscription collects, the actual subscription XML is available in an Appendix. These are separated out into Baseline and Targeted. The intent is to subscribe all hosts to Baseline, and then enroll (and remove) hosts on an as needed basis to the Targeted subscription.
+Below lists all of the items that each subscription collects, the actual subscription XML is available in an Appendix. These items are separated out into Baseline and Targeted. The intent is to subscribe all hosts to Baseline, and then enroll (and remove) hosts on an as needed basis to the Targeted subscription.
### Baseline subscription
-While this appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription doesn't require special configuration on client devices to enable event channels or modify channel permissions.
+While this subscription appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription doesn't require special configuration on client devices to enable event channels or modify channel permissions.
-The subscription is essentially a collection of query statements applied to the Event Log. This means that it is modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements which filter out specific events, only apply within that query statement and aren't to the entire subscription.
+The subscription is essentially a collection of query statements applied to the Event Log. This subscription means that it's modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements that filter out specific events, only apply within that query statement and aren't to the entire subscription.
### Baseline subscription requirements
-To gain the most value out of the baseline subscription we recommend to have the following requirements set on the device to ensure that the clients are already generating the required events to be forwarded off the system.
+To gain the most value out of the baseline subscription, we recommend having the following requirements set on the device to ensure that the clients are already generating the required events to be forwarded off the system.
-- Apply a security audit policy that is a super-set of the recommended minimum audit policy. For more info, see [Appendix A – Minimum Recommended minimum Audit Policy](#bkmk-appendixa). This ensures that the security event log is generating the required events.
+- Apply a security audit policy that is a super-set of the recommended minimum audit policy. For more info, see [Appendix A – Minimum Recommended minimum Audit Policy](#bkmk-appendixa). This policy ensures that the security event log is generating the required events.
- Apply at least an Audit-Only AppLocker policy to devices.
- - If you are already allowing or restricting events by using AppLocker, then this requirement is met.
- - AppLocker events contain extremely useful information, such as file hash and digital signature information for executables and scripts.
+ - If you're already allowing or restricting events by using AppLocker, then this requirement is met.
+ - AppLocker events contain useful information, such as file hash and digital signature information for executables and scripts.
- Enable disabled event channels and set the minimum size for modern event files.
-- Currently, there is no GPO template for enabling or setting the maximum size for the modern event files. This must be done by using a GPO. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
+- Currently, there's no GPO template for enabling or setting the maximum size for the modern event files. This threshold must be defined by using a GPO. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
The annotated event query can be found in the following. For more info, see [Appendix F – Annotated Suspect Subscription Event Query](#bkmk-appendixf).
-- Anti-malware events from Microsoft Antimalware or Windows Defender. This can be configured for any given anti-malware product easily if it writes to the Windows event log.
+- Anti-malware events from Microsoft Antimalware or Windows Defender. These events can be configured for any given anti-malware product easily if it writes to the Windows event log.
- Security event log Process Create events.
- AppLocker Process Create events (EXE, script, packaged App installation and execution).
- Registry modification events. For more info, see [Appendix B – Recommended minimum Registry System ACL Policy](#bkmk-appendixb).
@@ -192,7 +191,7 @@ The annotated event query can be found in the following. For more info, see [App
- Certificate Authority audit events
- - This is only applicable on systems with the Certificate Authority role installed.
+ - These events are only applicable on systems with the Certificate Authority role installed.
- Logs certificate requests and responses.
- User profile events
@@ -211,28 +210,29 @@ The annotated event query can be found in the following. For more info, see [App
- Find out what initiated the restart of a device.
-- User initiated interactive logoff event
+- User-initiated interactive sign-out event
- Remote Desktop Services sessions connect, reconnect, or disconnect.
- EMET events, if EMET is installed.
- Event forwarding plugin events
- - For monitoring WEF subscription operations, particularly Partial Success events. This is useful for diagnosing deployment issues.
+ - For monitoring WEF subscription operations, such as Partial Success events. This event is useful for diagnosing deployment issues.
- Network share creation and deletion
- Enables detection of unauthorized share creation.
- >**Note:** All shares are re-created when the device starts.
+ > [!NOTE]
+ > All shares are re-created when the device starts.
-- Logon sessions
+- Sign-in sessions
- - Logon success for interactive (local and Remote Interactive/Remote Desktop)
- - Logon success for services for non-built-in accounts, such as LocalSystem, LocalNetwork, and so on.
- - Logon success for batch sessions
- - Logon session close, which is logoff events for non-network sessions.
+ - Sign-in success for interactive (local and Remote Interactive/Remote Desktop)
+ - Sign-in success for services for non-built-in accounts, such as LocalSystem, LocalNetwork, and so on.
+ - Sign-in success for batch sessions
+ - Sign-in session close, which is sign-out events for non-network sessions.
- Windows Error Reporting (Application crash events only)
- - This can help detect early signs of intruder not familiar with enterprise environment using targeted malware.
+ - This session can help detect early signs of intruder not familiar with enterprise environment using targeted malware.
- Event log service events
@@ -240,11 +240,11 @@ The annotated event query can be found in the following. For more info, see [App
- Event log cleared (including the Security Event Log)
- - This could indicate an intruder that is covering their tracks.
+ - This event could indicate an intruder that is covering their tracks.
-- Special privileges assigned to new logon
+- Special privileges assigned to new sign in
- - This indicates that at the time of logon a user is either an Administrator or has the sufficient access to make themselves Administrator.
+ - This assignation indicates that at the time of signing in, a user is either an Administrator or has the sufficient access to make themselves Administrator.
- Outbound Remote Desktop Services session attempts
@@ -265,19 +265,19 @@ The annotated event query can be found in the following. For more info, see [App
- Task Scheduler allows intruders to run code at specified times as LocalSystem.
-- Logon with explicit credentials
+- Sign-in with explicit credentials
- Detect credential use changes by intruders to access more resources.
- Smartcard card holder verification events
- - This detects when a smartcard is being used.
+ - This event detects when a smartcard is being used.
### Suspect subscription
-This adds some possible intruder-related activity to help analyst further refine their determinations about the state of the device.
+This subscription adds some possible intruder-related activity to help analyst further refine their determinations about the state of the device.
-- Logon session creation for network sessions
+- Sign-in session creation for network sessions
- Enables time-series analysis of network graphs.
@@ -290,15 +290,15 @@ This adds some possible intruder-related activity to help analyst further refine
- Detects known bad certificate, CA, or sub-CA
- Detects unusual process use of CAPI
-- Groups assigned to local logon
+- Groups assigned to local sign in
- - Gives visibility to groups which enable account-wide access
+ - Gives visibility to groups that enable account-wide access
- Allows better planning for remediation efforts
- Excludes well known, built-in system accounts.
-- Logon session exit
+- Sign-in session exit
- - Specific for network logon sessions.
+ - Specific for network sign-in sessions.
- Client DNS lookup events
@@ -308,11 +308,11 @@ This adds some possible intruder-related activity to help analyst further refine
- Enables checking for processes terminating unexpectedly.
-- Local credential validation or logon with explicit credentials
+- Local credential validation or signing in with explicit credentials
- Generated when the local SAM is authoritative for the account credentials being authenticated.
- Noisy on domain controllers
- - On client devices this is only generated when local accounts log on.
+ - On client devices, it's only generated when local accounts sign in.
- Registry modification audit events
@@ -370,9 +370,9 @@ If your organizational audit policy enables more auditing to meet its needs, tha
## Appendix B - Recommended minimum registry system ACL policy
-The Run and RunOnce keys are useful for intruders and malware persistence. It allows code to be run (or run only once then removed, respectively) when a user logs into the system.
+The Run and RunOnce keys are useful for intruders and malware persistence. It allows code to be run (or run only once then removed, respectively) when a user signs in to the system.
-This can easily be extended to other Auto-Execution Start Points keys in the registry.
+This implication can easily be extended to other Auto-Execution Start Points keys in the registry.
Use the following figures to see how you can configure those registry keys.
@@ -384,16 +384,16 @@ Use the following figures to see how you can configure those registry keys.
Some channels are disabled by default and have to be enabled. Others, such as Microsoft-Windows-CAPI2/Operational must have the channel access modified to allow the Event Log Readers built-in security group to read from it.
-The recommended and most effective way to do this is configuring the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access.) This will take effect at the next GPO refresh cycle and has minimal impact on the client device.
+The recommended and most effective way to do this customization is configuring the baseline GPO to run a scheduled task to configure the event channels (enable, set maximum size, and adjust channel access). This configuration will take effect at the next GPO refresh cycle and has minimal impact on the client device.
-The following GPO snippet performs the following:
+The following GPO snippet performs the following tasks:
- Enables the **Microsoft-Windows-Capi2/Operational** event channel.
- Sets the maximum file size for **Microsoft-Windows-Capi2/Operational** to 100MB.
-- Sets the maximum file size for **Microsoft-Windows-AppLocker/EXE and DLL** to 100MB.
+- Sets the maximum file size for **Microsoft-Windows-AppLocker/EXE and DLL** to 100 MB.
- Sets the maximum channel access for **Microsoft-Windows-Capi2/Operational** to include the built-in Event Log Readers security group.
- Enables the **Microsoft-Windows-DriverFrameworks-UserMode/Operational** event channel.
-- Sets the maximum file size for **Microsoft-Windows-DriverFrameworks-UserMode/Operational** to 50MB.
+- Sets the maximum file size for **Microsoft-Windows-DriverFrameworks-UserMode/Operational** to 50 MB.

@@ -403,7 +403,7 @@ Here are the minimum steps for WEF to operate:
1. Configure the collector URI(s).
2. Start the WinRM service.
-3. Add the Network Service account to the built-in Event Log Readers security group. This allows reading from secured event channel, such as the security event channel.
+3. Add the Network Service account to the built-in Event Log Readers security group. This addition allows reading from secured event channel, such as the security event channel.

diff --git a/windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md b/windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
index e882f22e84..f85611c594 100644
--- a/windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
+++ b/windows/security/threat-protection/windows-defender-application-control/LOB-win32-apps-on-s.md
@@ -41,7 +41,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
1. Generate a supplemental policy with Windows Defender Application Control tooling
- This policy will expand the S mode base policy to authorize additional applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
+ This policy will expand the S mode base policy to authorize more applications. Anything authorized by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental policies can specify filepath rules, trusted publishers, and more.
Refer to [Deploy multiple Windows Defender Application Control Policies](deploy-multiple-windows-defender-application-control-policies.md) for guidance on creating supplemental policies and [Deploy Windows Defender Application Control policy rules and file rules](select-types-of-rules-to-create.md) to choose the right type of rules to create for your policy.
@@ -56,14 +56,14 @@ The general steps for expanding the S mode base policy on your Intune-managed de
```powershell
Set-CIPolicyIdInfo -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784 -FilePath "\SupplementalPolicy.xml"
```
- Policies which are supplementing the S mode base policy must use **-SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784**, as this is the S mode policy ID.
+ Policies that are supplementing the S mode base policy must use **-SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784**, as this ID is the S mode policy ID.
- Put the policy in enforce mode using [Set-RuleOption](/powershell/module/configci/set-ruleoption?view=win10-ps&preserve-view=true)
```powershell
Set-RuleOption -FilePath "\SupplementalPolicy.xml>" -Option 3 –Delete
```
- This deletes the 'audit mode' qualifier.
- - Since you'll be signing your policy, you must authorize the signing certificate you will use to sign the policy and optionally one or more additional signers that can be used to sign updates to the policy in the future. For more information, refer to Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the Windows Defender Application Control policy:
+ This command deletes the 'audit mode' qualifier.
+ - Since you'll be signing your policy, you must authorize the signing certificate you'll use to sign the policy and optionally one or more extra signers that can be used to sign updates to the policy in the future. For more information, see Section 2, Sign policy. Use Add-SignerRule to add the signing certificate to the Windows Defender Application Control policy:
```powershell
Add-SignerRule -FilePath -CertificatePath -User -Update
@@ -82,7 +82,7 @@ The general steps for expanding the S mode base policy on your Intune-managed de
3. Deploy the signed supplemental policy using Microsoft Intune
- Go to the Azure portal online and navigate to the Microsoft Intune page, then go to the Client apps blade and select 'S mode supplemental policies'. Upload the signed policy to Intune and assign it to user or device groups. Intune will generate tenant- and device- specific authorization tokens. Intune then deploys the corresponding authorization token and supplemental policy to each device in the assigned group. Together, these expand the S mode base policy on the device.
+ Go to the Azure portal online and navigate to the Microsoft Intune page, then go to the Client apps blade and select 'S mode supplemental policies'. Upload the signed policy to Intune and assign it to user or device groups. Intune will generate tenant- and device- specific authorization tokens. Intune then deploys the corresponding authorization token and supplemental policy to each device in the assigned group. Together, these tokens and policies expand the S mode base policy on the device.
> [!Note]
> When updating your supplemental policy, ensure that the new version number is strictly greater than the previous one. Using the same version number is not allowed by Intune. Refer to [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion?view=win10-ps&preserve-view=true) for information on setting the version number.
@@ -95,9 +95,9 @@ Refer to [Intune Standalone - Win32 app management](/intune/apps-win32-app-manag

Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that will authorize all apps signed by that certificate, which may include apps you don't want to allow as well.
-Instead of authorizing signers external to your organization, Intune has added new functionality to make it easier to authorize existing applications (without requiring repackaging or access to the source code) through the use of signed catalogs. This works for apps which may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
+Instead of authorizing signers external to your organization, Intune has added new functionality to make it easier to authorize existing applications (without requiring repackaging or access to the source code) by using signed catalogs. This functionality works for apps that may be unsigned or even signed apps when you don't want to trust all apps that may share the same signing certificate.
-The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using the DGSS or a custom PKI. Use the Add-SignerRule PowerShell cmdlet as shown above to authorize the catalog signing certificate in the supplemental policy. After that, IT Pros can use the standard Intune app deployment process outlined above. Refer to [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md) for more in-depth guidance on generating catalogs.
+The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files using the DGSS or a custom PKI. Use the Add-SignerRule PowerShell cmdlet as shown above to authorize the catalog signing certificate in the supplemental policy. After that, IT Pros can use the standard Intune app deployment process outlined above. For more information on generating catalogs, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
> [!Note]
> Every time an app updates, you will need to deploy an updated catalog. Because of this, IT Pros should try to avoid using catalog files for applications that auto-update and direct users not to update applications on their own.
@@ -186,7 +186,7 @@ Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Regis
```
## Policy removal
-In order to revert users to an unmodified S mode policy, an IT Pro can remove a user or users from the targeted Intune group which received the policy, which will trigger a removal of both the policy and the authorization token from the device.
+In order to revert users to an unmodified S mode policy, an IT Pro can remove a user or users from the targeted Intune group that received the policy, which will trigger a removal of both the policy and the authorization token from the device.
IT Pros also have the choice of deleting a supplemental policy through Intune.
diff --git a/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md b/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md
index 1b90bf0d1c..11e582e4d8 100644
--- a/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/allow-com-object-registration-in-windows-defender-application-control-policy.md
@@ -35,7 +35,7 @@ The [Microsoft Component Object Model (COM)](/windows/desktop/com/the-component-
### COM object configurability in WDAC policy
-Prior to the Windows 10 1903 update, Windows Defender Application Control (WDAC) enforced a built-in allow list for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where additional COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
+Prior to the Windows 10 1903 update, Windows Defender Application Control (WDAC) enforced a built-in allowlist for COM object registration. While this mechanism works for most common application usage scenarios, customers have provided feedback that there are cases where more COM objects need to be allowed. The 1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC policy.
> [!NOTE]
> To add this functionality to other versions of Windows 10, you can install the following or later updates.
@@ -56,7 +56,7 @@ Get GUID of application to allow in one of the following ways:
Three elements:
-- Provider: platform on which code is running (values are Powershell, WSH, IE, VBA, MSI, or a wildcard “AllHostIds”)
+- Provider: platform on which code is running (values are PowerShell, WSH, IE, VBA, MSI, or a wildcard “AllHostIds”)
- Key: GUID for the program you wish to run, in the format Key="{33333333-4444-4444-1616-161616161616}"
- ValueName: needs to be set to "EnterpriseDefinedClsId"
@@ -152,7 +152,7 @@ To add this CLSID to the existing policy, follow these steps:
PS C:\WINDOWS\system32> Set-CIPolicySetting -FilePath \WDAC_policy.xml -Key "{f8d253d9-89a4-4daa-87b6-1168369f0b21}" -Provider WSH -Value true -ValueName EnterpriseDefinedClsId -ValueType Boolean
```
- Once the command has been run, you will find that the following section is added to the policy XML.
+ Once the command has been run, you'll find that the following section is added to the policy XML.
```XML
@@ -162,9 +162,9 @@ To add this CLSID to the existing policy, follow these steps:
```
-### Default COM Object Allow List
+### Default COM Object allowlist
-The table below describes the list of COM objects that are inherently trusted in Windows Defender Application Control. Objects in this list do not need to be allowlisted in your WDAC policies. They can be denied by creating explicit deny rules in your WDAC policy.
+The table below describes the list of COM objects that are inherently trusted in Windows Defender Application Control. Objects in this list don't need to be allowlisted in your WDAC policies. They can be denied by creating explicit deny rules in your WDAC policy.
| File Name | CLSID |
|--------|-----------|
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md b/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
index d3d7b17207..5a985252e9 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/add-rules-for-packaged-apps-to-existing-applocker-rule-set.md
@@ -33,6 +33,6 @@ This topic for IT professionals describes how to update your existing AppLocker
You can create packaged app rules for the computers running Windows Server 2012 or Windows 8 and later in your domain by updating your existing AppLocker rule set. All you need is a computer running at least Windows 8. Download and install the Remote Server Administration Toolkit (RSAT) from the Microsoft Download Center.
-RSAT comes with the Group Policy Management Console which allows you to edit the GPO or GPOs where your existing AppLocker policy are authored. RSAT has the necessary files required to author packaged app rules. Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those computers in your domain running at least Windows Server 2012 and Windows 8.
+RSAT comes with the Group Policy Management Console that allows you to edit the GPO or GPOs where your existing AppLocker policy is authored. RSAT has the necessary files required to author packaged app rules. Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those computers in your domain running at least Windows Server 2012 and Windows 8.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-architecture-and-components.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-architecture-and-components.md
index 206a7b287c..6dbbe7b0fe 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-architecture-and-components.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-architecture-and-components.md
@@ -45,7 +45,7 @@ When a new DLL loads, a notification is sent to AppLocker to verify that the DLL
**A script is run**
-Before a script file is run, the script host (for example. for .ps1 files the script host is PowerShell) invokes AppLocker to verify the script. AppLocker invokes the Application Identity component in user-mode with the file name or file handle to calculate the file properties. The script file then is evaluated against the AppLocker policy to verify that it is allowed to run. In each case, the actions taken by AppLocker are written to the event log.
+Before a script file is run, the script host (for example, for .ps1 files, the script host is PowerShell) invokes AppLocker to verify the script. AppLocker invokes the Application Identity component in user-mode with the file name or file handle to calculate the file properties. The script file then is evaluated against the AppLocker policy to verify that it's allowed to run. In each case, the actions taken by AppLocker are written to the event log.
## Related topics
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
index af1cdbd2d8..4e4e13c016 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview.md
@@ -51,7 +51,7 @@ AppLocker helps reduce administrative overhead and helps reduce the organization
- **Protection against unwanted software**
- AppLocker has the ability to deny apps from running when you exclude them from the list of allowed apps. When AppLocker rules are enforced in the production environment, any apps that are not included in the allowed rules are blocked from running.
+ AppLocker has the ability to deny apps from running when you exclude them from the list of allowed apps. When AppLocker rules are enforced in the production environment, any apps that aren't included in the allowed rules are blocked from running.
- **Licensing conformance**
@@ -59,11 +59,11 @@ AppLocker helps reduce administrative overhead and helps reduce the organization
- **Software standardization**
- AppLocker policies can be configured to allow only supported or approved apps to run on computers within a business group. This permits a more uniform app deployment.
+ AppLocker policies can be configured to allow only supported or approved apps to run on computers within a business group. This configuration permits a more uniform app deployment.
- **Manageability improvement**
- AppLocker includes a number of improvements in manageability as compared to its predecessor Software Restriction Policies. Importing and exporting policies, automatic generation of rules from multiple files, audit-only mode deployment, and Windows PowerShell cmdlets are a few of the improvements over Software Restriction Policies.
+ AppLocker includes many improvements in manageability as compared to its predecessor Software Restriction Policies. Importing and exporting policies, automatic generation of rules from multiple files, audit-only mode deployment, and Windows PowerShell cmdlets are a few of the improvements over Software Restriction Policies.
## When to use AppLocker
@@ -71,7 +71,7 @@ AppLocker helps reduce administrative overhead and helps reduce the organization
In many organizations, information is the most valuable asset, and ensuring that only approved users have access to that information is imperative. Access control technologies, such as Active Directory Rights Management Services (AD RMS) and access control lists (ACLs), help control what users are allowed to access.
However, when a user runs a process, that process has the same level of access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or unknowingly runs malicious software. AppLocker can help mitigate these types of security breaches by restricting the files that users or groups are allowed to run.
-Software publishers are beginning to create more apps that can be installed by non-administrative users. This could jeopardize an organization's written security policy and circumvent traditional app control solutions that rely on the inability of users to install apps. By creating an allowed list of approved files and apps, AppLocker helps prevent such per-user apps from running. Because AppLocker can control DLLs, it is also useful to control who can install and run ActiveX controls.
+Software publishers are beginning to create more apps that can be installed by non-administrative users. This privilege could jeopardize an organization's written security policy and circumvent traditional app control solutions that rely on the inability of users to install apps. AppLocker creates an allowed list of approved files and apps to help prevent such per-user apps from running. Because AppLocker can control DLLs, it's also useful to control who can install and run ActiveX controls.
AppLocker is ideal for organizations that currently use Group Policy to manage their PCs.
@@ -80,9 +80,9 @@ The following are examples of scenarios in which AppLocker can be used:
- Your organization's security policy dictates the use of only licensed software, so you need to prevent users from running unlicensed software and also restrict the use of licensed software to authorized users.
- An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
- The potential that unwanted software can be introduced in your environment is high, so you need to reduce this threat.
-- The license to an app has been revoked or it is expired in your organization, so you need to prevent it from being used by everyone.
+- The license to an app has been revoked or it's expired in your organization, so you need to prevent it from being used by everyone.
- A new app or a new version of an app is deployed, and you need to prevent users from running the old version.
-- Specific software tools are not allowed within the organization, or only specific users should have access to those tools.
+- Specific software tools aren't allowed within the organization, or only specific users should have access to those tools.
- A single user or small group of users needs to use a specific app that is denied for all others.
- Some computers in your organization are shared by people who have different software usage needs, and you need to protect specific apps.
- In addition to other measures, you need to control the access to sensitive data through app usage.
@@ -101,7 +101,7 @@ AppLocker is included with enterprise-level editions of Windows. You can author
### Using AppLocker on Server Core
-AppLocker on Server Core installations is not supported.
+AppLocker on Server Core installations isn't supported.
### Virtualization considerations
@@ -115,9 +115,9 @@ The variety of forms that malicious software can take make it difficult for user
The countermeasure is to create a sound design for your application control policies on PCs in your organization, and then thoroughly test the policies in a lab environment before you deploy them in a production environment. AppLocker can be part of your app control strategy because you can control what software is allowed to run on your computers.
-A flawed application control policy implementation can disable necessary applications or allow malicious or unintended software to run. Therefore, it is important that organizations dedicate sufficient resources to manage and troubleshoot the implementation of such policies.
+A flawed application control policy implementation can disable necessary applications or allow malicious or unintended software to run. Therefore, it's important that organizations dedicate sufficient resources to manage and troubleshoot the implementation of such policies.
-For additional information about specific security issues, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
+For more information about specific security issues, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
When you use AppLocker to create application control policies, you should be aware of the following security considerations:
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-deployment-guide.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-deployment-guide.md
index 8b61cc5f7c..a7af9ef942 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-deployment-guide.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-deployment-guide.md
@@ -32,7 +32,7 @@ ms.technology: windows-sec
This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker policies.
-This guide provides steps based on your design and planning investigation for deploying application control policies by using AppLocker. It is intended for security architects, security administrators, and system administrators. Through a sequential and iterative deployment process, you can create application control policies, test and adjust the policies, and implement a method for maintaining those policies as the needs in your organization change.
+This guide provides steps based on your design and planning investigation for deploying application control policies by using AppLocker. It's intended for security architects, security administrators, and system administrators. Through a sequential and iterative deployment process, you can create application control policies, test and adjust the policies, and implement a method for maintaining those policies as the needs in your organization change.
This guide covers the use of Software Restriction Policies (SRP) in conjunction with AppLocker policies to control application usage. For a comparison of SRP and AppLocker, see [Using Software Restriction Policies and AppLocker policies](using-software-restriction-policies-and-applocker-policies.md) in this guide. To understand if AppLocker is the correct application control solution for you, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-design-guide.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-design-guide.md
index 5175d57766..2c023e6bc0 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-design-guide.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policies-design-guide.md
@@ -31,9 +31,9 @@ ms.technology: windows-sec
This topic for the IT professional introduces the design and planning steps required to deploy application control policies by using AppLocker.
-This guide provides important designing and planning information for deploying application control policies by using AppLocker. It is intended for security architects, security administrators, and system administrators. Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group.
+This guide provides important designing and planning information for deploying application control policies by using AppLocker. It's intended for security architects, security administrators, and system administrators. Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group.
-This guide does not cover the deployment of application control policies by using Software Restriction Policies (SRP). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about these options, see [Determine your application control objectives](determine-your-application-control-objectives.md).
+This guide doesn't cover the deployment of application control policies by using Software Restriction Policies (SRP). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about these options, see [Determine your application control objectives](determine-your-application-control-objectives.md).
To understand if AppLocker is the correct application control solution for your organization, see [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md).
## In this section
@@ -44,8 +44,8 @@ To understand if AppLocker is the correct application control solution for your
| [Determine your application control objectives](determine-your-application-control-objectives.md) | This topic helps you with the decisions you need to make to determine what applications to control and how to control them by comparing Software Restriction Policies (SRP) and AppLocker. |
| [Create a list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md) | This topic describes the process of gathering app usage requirements from each business group in order to implement application control policies by using AppLocker. |
| [Select the types of rules to create](select-types-of-rules-to-create.md) | This topic lists resources you can use when selecting your application control policy rules by using AppLocker. |
-| [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md) | This overview topic describes the process to follow when you are planning to deploy AppLocker rules. |
-| [Plan for AppLocker policy management](plan-for-applocker-policy-management.md) | This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies. |
+| [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md) | This overview topic describes the process to follow when you're planning to deploy AppLocker rules. |
+| [Plan for AppLocker policy management](plan-for-applocker-policy-management.md) | This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies. |
After careful design and detailed planning, the next step is to deploy AppLocker policies. [AppLocker Deployment Guide](applocker-policies-deployment-guide.md) covers the creation and testing of policies, deploying the enforcement setting, and managing and maintaining the policies.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policy-use-scenarios.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policy-use-scenarios.md
index 32d003ef09..77d166aedc 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policy-use-scenarios.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-policy-use-scenarios.md
@@ -39,7 +39,7 @@ AppLocker can help you improve the management of application control and the mai
2. **Protection against unwanted software**
- AppLocker has the ability to deny apps from running simply by excluding them from the list of allowed apps per business group or user. If an app is not identified by its publisher, installation path, or file hash, the attempt to run the application fails.
+ AppLocker has the ability to deny apps from running simply by excluding them from the list of allowed apps per business group or user. If an app isn't identified by its publisher, installation path, or file hash, the attempt to run the application fails.
3. **Licensing conformance**
@@ -47,12 +47,11 @@ AppLocker can help you improve the management of application control and the mai
4. **Software standardization**
- AppLocker policies can be configured to allow only supported or approved apps to run on computers within a business group. This permits a more uniform app deployment.
+ AppLocker policies can be configured to allow only supported or approved apps to run on computers within a business group. This configuration permits a more uniform app deployment.
5. **Manageability improvement**
- AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and can work in conjunction with policies created by using Software Restriction Policies. As you manage ongoing change in your support of a business group's apps, you can modify policies and use
- the AppLocker cmdlets to test the policies for the expected results. You can also design application control policies for situations in which users share computers.
+ AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and can work in conjunction with policies created by using Software Restriction Policies. As you manage ongoing change in your support of a business group's apps, you can modify policies and use the AppLocker cmdlets to test the policies for the expected results. You can also design application control policies for situations in which users share computers.
### Use scenarios
@@ -60,13 +59,13 @@ The following are examples of scenarios in which AppLocker can be used:
- Your organization implements a policy to standardize the applications used within each business group, so you need to determine the expected usage compared to the actual usage.
- The security policy for application usage has changed, and you need to evaluate where and when those deployed apps are being accessed.
-- Your organization's security policy dictates the use of only licensed software, so you need to determine which apps are not licensed or prevent unauthorized users from running licensed software.
+- Your organization's security policy dictates the use of only licensed software, so you need to determine which apps aren't licensed or prevent unauthorized users from running licensed software.
- An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
-- Your organization needs to restrict the use of Universal Windows apps to just those your organization approves of or develops.
+- Your organization needs to restrict the use of Universal Windows apps to just those apps your organization approves of or develops.
- The potential that unwanted software can be introduced in your environment is high, so you need to reduce this threat.
- The license to an app has been revoked or is expired in your organization, so you need to prevent it from being used by everyone.
- A new app or a new version of an app is deployed, and you need to allow certain groups to use it.
-- Specific software tools are not allowed within the organization, or only specific users have access to those tools.
+- Specific software tools aren't allowed within the organization, or only specific users have access to those tools.
- A single user or small group of users needs to use a specific app that is denied for all others.
- Some computers in your organization are shared by people who have different software usage needs.
- In addition to other measures, you need to control the access to sensitive data through app usage.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-processes-and-interactions.md b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-processes-and-interactions.md
index 8460667499..34ff057457 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-processes-and-interactions.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-processes-and-interactions.md
@@ -35,7 +35,7 @@ This topic for the IT professional describes the process dependencies and intera
AppLocker policies are collections of AppLocker rules that might contain any one of the enforcement settings configured. When applied, each rule is evaluated within the policy and the collection of rules is applied according to the enforcement setting and according to your Group Policy structure.
-The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine that evaluates the policies. If the service is not running, policies will not be enforced. The Application Identity service returns the information from the binary -even if product or binary names are empty- to the results pane of the Local Security Policy snap-in.
+The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine that evaluates the policies. If the service isn't running, policies won't be enforced. The Application Identity service returns the information from the binary -even if product or binary names are empty- to the results pane of the Local Security Policy snap-in.
AppLocker policies are stored in a security descriptor format according to Application Identity service requirements. It uses file path, hash, or fully qualified binary name attributes to form allow or deny actions on a rule. Each rule is stored as an access control entry (ACE) in the security descriptor and contains the following information:
@@ -49,7 +49,7 @@ An AppLocker policy for DLLs and executable files is read and cached by kernel m
### Understanding AppLocker rules
-An AppLocker rule is a control placed on a file to govern whether or not it is allowed to run for a specific user or group. Rules apply to five different types, or collections, of files:
+An AppLocker rule is a control placed on a file to govern whether or not it's allowed to run for a specific user or group. Rules apply to five different types, or collections, of files:
- An executable rule controls whether a user or group can run an executable file. Executable files most often have the .exe or .com file name extensions and apply to applications.
- A script rule controls whether a user or group can run scripts with a file name extension of .ps1, .bat, .cmd, .vbs, and .js.
@@ -97,7 +97,7 @@ An AppLocker policy is a set of rule collections and their corresponding configu
- [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)
- Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. The options for rule enforcement are **Not configured**, **Enforce rules**, or **Audit only**. Together, all AppLocker rule collections compose the application control policy, or AppLocker policy. By default, if enforcement is not configured and rules are present in a rule collection, those rules are enforced.
+ Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. The options for rule enforcement are **Not configured**, **Enforce rules**, or **Audit only**. Together, all AppLocker rule collections compose the application control policy, or AppLocker policy. By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced.
### Understanding AppLocker and Group Policy
@@ -105,7 +105,7 @@ Group Policy can be used to create, modify, and distribute AppLocker policies in
- [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)
- When Group Policy is used to distribute AppLocker policies, rule collections that are not configured will be enforced. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy Object (GPO) and applies the AppLocker rules in addition to existing rules.
+ When Group Policy is used to distribute AppLocker policies, rule collections that aren't configured will be enforced. Group Policy doesn't overwrite or replace rules that are already present in a linked Group Policy Object (GPO) and applies the AppLocker rules in addition to existing rules.
AppLocker processes the explicit deny rule configuration before the allow rule configuration, and for rule enforcement, the last write to the GPO is applied.
## Related topics
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/configure-an-applocker-policy-for-enforce-rules.md b/windows/security/threat-protection/windows-defender-application-control/applocker/configure-an-applocker-policy-for-enforce-rules.md
index 4ae757fa97..81a1e43bb4 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/configure-an-applocker-policy-for-enforce-rules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/configure-an-applocker-policy-for-enforce-rules.md
@@ -40,7 +40,7 @@ You can perform this task by using the Group Policy Management Console for an Ap
**To enable the Enforce rules enforcement setting**
1. From the AppLocker console, right-click **AppLocker**, and then click **Properties**.
-2. On the **Enforcement** tab of the **AppLocker Properties** dialog box, select the **Configured** check box for the rule collection that you are editing, and then verify that **Enforce rules** is selected.
+2. On the **Enforcement** tab of the **AppLocker Properties** dialog box, select the **Configured** check box for the rule collection that you're editing, and then verify that **Enforce rules** is selected.
3. Click **OK**.
For info about viewing the events generated from rules enforcement, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/configure-the-appLocker-reference-device.md b/windows/security/threat-protection/windows-defender-application-control/applocker/configure-the-appLocker-reference-device.md
index 0675c5fa73..1f7b314f14 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/configure-the-appLocker-reference-device.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/configure-the-appLocker-reference-device.md
@@ -36,15 +36,15 @@ An AppLocker reference device that is used for the development and deployment of
- Maintain an application list for each business group.
- Develop AppLocker policies by creating individual rules or by creating a policy by automatically generating rules.
- Create the default rules to allow the Windows system files to run properly.
-- Run tests and analyze the event logs to determine the affect of the policies that you intend to deploy.
+- Run tests and analyze the event logs to determine the effect of the policies that you intend to deploy.
-The reference device does not need to be joined to a domain, but it must be able to import and export AppLocker policies in XML format. The reference computer must be running one of the supported editions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
+The reference device doesn't need to be joined to a domain, but it must be able to import and export AppLocker policies in XML format. The reference computer must be running one of the supported editions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md).
>**Warning:** Do not use operating system snapshots when creating AppLocker rules. If you take a snapshot of the operating system, install an app, create AppLocker rules, and then revert to a clean snapshot and repeat the process for another app, there is a chance that duplicate rule GUIDs can be created. If duplicate GUIDs are present, AppLocker policies will not work as expected.
**To configure a reference device**
-1. If the operating system is not already installed, install one of the supported editions of Windows on the device.
+1. If the operating system isn't already installed, install one of the supported editions of Windows on the device.
>**Note:** If you have the Group Policy Management Console (GPMC) installed on another device to test your implementation of AppLocker policies, you can export the policies to that device
@@ -58,7 +58,7 @@ The reference device does not need to be joined to a domain, but it must be able
### See also
-- After you configure the reference computer, you can create the AppLocker rule collections. You can build, import, or automatically generate the rules. For procedures to do this, see [Working with AppLocker rules](working-with-applocker-rules.md).
+- After you configure the reference computer, you can create the AppLocker rule collections. You can build, import, or automatically generate the rules. For procedures to do this task, see [Working with AppLocker rules](working-with-applocker-rules.md).
- [Use a reference device to create and maintain AppLocker policies](use-a-reference-computer-to-create-and-maintain-applocker-policies.md)
From 4e8cbb0dbd9780861e46c8dbbfacf5e9eaf35fb1 Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Fri, 1 Jul 2022 11:38:41 +0530
Subject: [PATCH 018/299] Acrolinx Enhancement Effort
---
.../applocker/create-a-rule-for-packaged-apps.md | 14 +++++++-------
...applications-deployed-to-each-business-group.md | 12 ++++++------
.../applocker/create-your-applocker-policies.md | 8 ++++----
.../applocker/create-your-applocker-rules.md | 6 +++---
.../applocker/delete-an-applocker-rule.md | 6 +++---
...-policies-by-using-the-enforce-rules-setting.md | 10 +++++-----
...-group-policy-structure-and-rule-enforcement.md | 10 +++++-----
...are-digitally-signed-on-a-reference-computer.md | 4 ++--
...etermine-your-application-control-objectives.md | 14 +++++++-------
...-when-users-try-to-run-a-blocked-application.md | 2 +-
10 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md b/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md
index 1c676d9236..3bc3d41f7e 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
This article for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
-Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files within an app package share the same identity. Therefore, it is possible to control the entire app using a single AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity. Windows does not support unsigned packaged apps, which implies all packaged apps must be signed. AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following information:
+Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files within an app package share the same identity. Therefore, it's possible to control the entire app using a single AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity. Windows doesn't support unsigned packaged apps, which implies all packaged apps must be signed. AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following information:
- Publisher of the package
- Package name
@@ -53,19 +53,19 @@ You can perform this task by using the Group Policy Management Console for an Ap
|Selection|Description|Example|
|--- |--- |--- |
- |**Use an installed packaged app as a reference**|If selected, AppLocker requires you to choose an app that is already installed on which to base your new rule. AppLocker uses the publisher, package name and package version to define the rule.|You want the Sales group only to use the app named Microsoft.BingMaps for its outside sales calls. The Microsoft.BingMaps app is already installed on the device where you are creating the rule, so you choose this option, and select the app from the list of apps installed on the computer and create the rule using this app as a reference.|
+ |**Use an installed packaged app as a reference**|If selected, AppLocker requires you to choose an app that is already installed on which to base your new rule. AppLocker uses the publisher, package name and package version to define the rule.|You want the Sales group only to use the app named Microsoft.BingMaps for its outside sales calls. The Microsoft.BingMaps app is already installed on the device where you're creating the rule, so you choose this option, and select the app from the list of apps installed on the computer and create the rule using this app as a reference.|
|**Use a packaged app installer as a reference**|If selected, AppLocker requires you to choose an app installer on which to base your new rule. A packaged app installer has the .appx extension. AppLocker uses the publisher, package name, and package version of the installer to define the rule.|Your company has developed many internal line-of-business packaged apps. The app installers are stored on a common file share. Employees can install the required apps from that file share. You want to allow all your employees to install the Payroll app from this share. So you choose this option from the wizard, browse to the file share, and choose the installer for the Payroll app as a reference to create your rule.|
The following table describes setting the scope for the packaged app rule.
|Selection|Description|Example|
|--- |--- |--- |
- |Applies to **Any publisher**|This is the least restrictive scope condition for an **Allow** rule. It permits every packaged app to run or install.
Conversely, if this is a **Deny** rule, then this option is the most restrictive because it denies all apps from installing or running. | You want the Sales group to use any packaged app from any signed publisher. You set the permissions to allow the Sales group to be able to run any app.|
- |Applies to a specific **Publisher** | This scopes the rule to all apps published by a particular publisher. | You want to allow all your users to install apps published by the publisher of Microsoft.BingMaps. You could select Microsoft.BingMaps as a reference and choose this rule scope. |
- |Applies to a **Package name** | This scopes the rule to all packages that share the publisher name and package name as the reference file. | You want to allow your Sales group to install any version of the Microsoft.BingMaps app. You could select the Microsoft.BingMaps app as a reference and choose this rule scope. |
- |Applies to a **Package version** | This scopes the rule to a particular version of the package. | You want to be very selective in what you allow. You do not want to implicitly trust all future updates of the Microsoft.BingMaps app. You can limit the scope of your rule to the version of the app currently installed on your reference computer. |
+ |Applies to **Any publisher**|This setting is the least restrictive scope condition for an **Allow** rule. It permits every packaged app to run or install.
Conversely, if this setting is a **Deny** rule, then this option is the most restrictive because it denies all apps from installing or running. | You want the Sales group to use any packaged app from any signed publisher. You set the permissions to allow the Sales group to be able to run any app.|
+ |Applies to a specific **Publisher** | This setting scopes the rule to all apps published by a particular publisher. | You want to allow all your users to install apps published by the publisher of Microsoft.BingMaps. You could select Microsoft.BingMaps as a reference and choose this rule scope. |
+ |Applies to a **Package name** | This setting scopes the rule to all packages that share the publisher name and package name as the reference file. | You want to allow your Sales group to install any version of the Microsoft.BingMaps app. You could select the Microsoft.BingMaps app as a reference and choose this rule scope. |
+ |Applies to a **Package version** | This setting scopes the rule to a particular version of the package. | You want to be selective in what you allow. You don't want to implicitly trust all future updates of the Microsoft.BingMaps app. You can limit the scope of your rule to the version of the app currently installed on your reference computer. |
|Applying custom values to the rule | Selecting the **Use custom values** check box allows you to adjust the scope fields for your particular circumstance. | You want to allow users to install all *Microsoft.Bing* applications, which include Microsoft.BingMaps, Microsoft.BingWeather, Microsoft.BingMoney. You can choose the Microsoft.BingMaps as a reference, select the **Use custom values** check box and edit the package name field by adding “Microsoft.Bing*” as the Package name. |
6. Select **Next**.
-7. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Select **Next**.
+7. (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. These conditions allow you to add exceptions based on the same rule reference and rule scope as you set before. Select **Next**.
8. On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then select **Create**.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/create-list-of-applications-deployed-to-each-business-group.md b/windows/security/threat-protection/windows-defender-application-control/applocker/create-list-of-applications-deployed-to-each-business-group.md
index 7daf4320eb..4b22dedc36 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/create-list-of-applications-deployed-to-each-business-group.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/create-list-of-applications-deployed-to-each-business-group.md
@@ -39,7 +39,7 @@ For each business group, determine the following information:
- The full installation path of the app
- The publisher and signed status of each app
- The type of requirement the business groups set for each app, such as business critical, business productivity, optional, or personal. It might also be helpful during this effort to identify which apps are supported or unsupported by your IT department, or supported by others outside your control.
-- A list of files or apps that require administrative credentials to install or run. If the file requires administrative credentials to install or run, users who cannot provide administrative credentials will be prevented from running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies enforced, only members of the Administrators group can install or run files that require administrative credentials.
+- A list of files or apps that require administrative credentials to install or run. If the file requires administrative credentials to install or run, users who can't provide administrative credentials will be prevented from running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies enforced, only members of the Administrators group can install or run files that require administrative credentials.
### How to perform the app usage assessment
@@ -48,9 +48,9 @@ Rules wizard and the **Audit only** enforcement configuration to assist you with
**Application inventory methods**
-Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard is designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit the rules. This method is useful when creating rules from a reference computer and when creating and evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on the reference computer or through a network drive. This might mean additional work in setting up the reference computer and determining a maintenance policy for that computer.
+Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard is designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit the rules. This method is useful when creating rules from a reference computer and when creating and evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on the reference computer or through a network drive. This requirement might mean more work in setting up the reference computer and determining a maintenance policy for that computer.
-Using the **Audit only** enforcement method permits you to view the logs because it collects information about every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets that you can use to analyze the events from the event log and cmdlets to create rules. However, when you use Group Policy to deploy to several computers, a means to collect events in a central location is very important for manageability. Because AppLocker logs information about files that users or other processes start on a computer, you could miss creating some rules initially. Therefore, you should continue your evaluation until you can verify that all required applications that are allowed to run are accessed successfully.
+Using the **Audit only** enforcement method permits you to view the logs because it collects information about every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets that you can use to analyze the events from the event log and cmdlets to create rules. However, when you use Group Policy to deploy to several computers, a means to collect events in a central location is important for manageability. Because AppLocker logs information about files that users or other processes start on a computer, you could miss creating some rules initially. Therefore, you should continue your evaluation until you can verify that all required applications that are allowed to run are accessed successfully.
> [!TIP]
> If you run Application Verifier against a custom application with any AppLocker policies enabled, it might prevent the application from running. You should either disable Application Verifier or AppLocker.
@@ -63,16 +63,16 @@ The following topics describe how to perform each method:
### Prerequisites to completing the inventory
-Identify the business group and each organizational unit (OU) within that group to which you will apply application control policies. In addition, you should have identified whether or not AppLocker is the most appropriate solution for these policies. For info about these steps, see the following topics:
+Identify the business group and each organizational unit (OU) within that group to which you'll apply application control policies. In addition, you should have identified whether or not AppLocker is the most appropriate solution for these policies. For info about these steps, see the following topics:
- [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
- [Determine your application control objectives](determine-your-application-control-objectives.md)
## Next steps
-Identify and develop the list of apps. Record the name of the app, whether it is signed or not as indicated by the publisher's name, and whether or not it is a mission critical, business productivity, optional, or personal application. Record the installation path of the apps. For info about how to do this, see [Document your app list](document-your-application-list.md).
+Identify and develop the list of apps. Record the name of the app, whether it's signed or not as indicated by the publisher's name, and whether or not it's a mission critical, business productivity, optional, or personal application. Record the installation path of the apps. For more information, see [Document your app list](document-your-application-list.md).
-After you have created the list of apps, the next step is to identify the rule collections, which will become the policies. This information can be added to the table under columns labeled:
+After you've created the list of apps, the next step is to identify the rule collections, which will become the policies. This information can be added to the table under columns labeled:
- Use default rule or define new rule condition
- Allow or deny
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-policies.md b/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-policies.md
index 961dd4e3ff..8a5e46aee1 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-policies.md
@@ -35,7 +35,7 @@ Creating effective application control policies with AppLocker starts by creatin
## Step 1: Use your plan
-You can develop an application control policy plan to guide you in making successful deployment decisions. For more info about how to do this and what you should consider, see the [AppLocker Design Guide](applocker-policies-design-guide.md). This guide is intended for security architects, security administrators, and system administrators. It contains the following topics to help you create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group:
+You can develop an application control policy plan to guide you in making successful deployment decisions. For more information about how to develop this policy and what you should consider, see the [AppLocker Design Guide](applocker-policies-design-guide.md). This guide is intended for security architects, security administrators, and system administrators. It contains the following topics to help you create an AppLocker policy deployment plan for your organization that will address your specific application control requirements by department, organizational unit, or business group:
1. [Understand the AppLocker policy deployment process](understand-the-applocker-policy-deployment-process.md)
2. [Understand AppLocker policy design decisions](understand-applocker-policy-design-decisions.md)
@@ -52,12 +52,12 @@ Each rule applies to one or more apps, and it imposes a specific rule condition
## Step 3: Configure the enforcement setting
-An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The enforcement setting can be **Enforce rules**, **Audit only**, or **Not configured**. If an AppLocker policy has at least one rule, and it is set to **Not configured**, all the rules in that
+An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The enforcement setting can be **Enforce rules**, **Audit only**, or **Not configured**. If an AppLocker policy has at least one rule, and it's set to **Not configured**, all the rules in that
policy will be enforced. For info about configuring the rule enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md) and [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
## Step 4: Update the GPO
-AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to apply AppLocker policies, you must create a new Group Policy Object (GPO) or you must update an existing GPO. You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or you can import an AppLocker policy into a GPO. For the procedure to do this, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
+AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to apply AppLocker policies, you must create a new Group Policy Object (GPO), or you must update an existing GPO. You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or you can import an AppLocker policy into a GPO. For the procedure to import this policy into a GPO, see [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
## Step 5: Test the effect of the policy
@@ -68,7 +68,7 @@ In a test environment or with the enforcement setting set at **Audit only**, ver
Depending on your deployment method, import the AppLocker policy to the GPO in your production environment, or if the policy is already deployed, change the enforcement setting to your production environment value—**Enforce rules** or **Audit only**.
## Step 7: Test the effect of the policy and adjust
-Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the policy as necessary. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
+Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the policy as necessary. For information on how to do these tasks, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
## Next steps
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-rules.md b/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-rules.md
index cdda7822da..8efbf0415b 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-rules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/create-your-applocker-rules.md
@@ -33,7 +33,7 @@ This topic for the IT professional describes what you need to know about AppLock
## Creating AppLocker rules
-AppLocker rules apply to the targeted app, and they are the components that make up the AppLocker policy. Depending on your IT environment and the business group that requires application control policies, setting these access rules for each application can be time-consuming and prone to error. With AppLocker, you can generate rules automatically or create rules individually. Creating rules that are derived from your planning document can help you avoid unintended results. For info about this planning document and other planning activities, see [AppLocker Design Guide](applocker-policies-design-guide.md).
+AppLocker rules apply to the targeted app, and they're the components that make up the AppLocker policy. Depending on your IT environment and the business group that requires application control policies, setting these access rules for each application can be time-consuming and prone to error. With AppLocker, you can generate rules automatically or create rules individually. Creating rules that are derived from your planning document can help you avoid unintended results. For info about this planning document and other planning activities, see [AppLocker Design Guide](applocker-policies-design-guide.md).
### Automatically generate your rules
@@ -47,7 +47,7 @@ You can use a reference device to automatically create a set of default rules fo
### Create your rules individually
-You can create rules and set the mode to **Audit only** for each installed app, test and update each rule as necessary, and then deploy the policies. Creating rules individually might be best when you are targeting a small number of applications within a business group.
+You can create rules and set the mode to **Audit only** for each installed app, test and update each rule as necessary, and then deploy the policies. Creating rules individually might be best when you're targeting a few applications within a business group.
>**Note:** AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You can also edit the default rules. For information about creating the default rules for the Windows operating system, see [Create AppLocker default rules](create-applocker-default-rules.md).
@@ -62,7 +62,7 @@ For information about performing this task, see:
## About selecting rules
-AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and they are implemented through an AppLocker policy definition. AppLocker policies are managed by using Group Policy or by using the Local Security Policy snap-in for a single computer.
+AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and they're implemented through an AppLocker policy definition. AppLocker policies are managed by using Group Policy or by using the Local Security Policy snap-in for a single computer.
When you determine what types of rules to create for each of your business groups or organizational units (OUs), you should also determine what enforcement setting to use for each group. Certain rule types are more applicable for some apps, depending on how the apps are deployed in a specific business group.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/delete-an-applocker-rule.md b/windows/security/threat-protection/windows-defender-application-control/applocker/delete-an-applocker-rule.md
index 0add3ed41f..6247e45693 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/delete-an-applocker-rule.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/delete-an-applocker-rule.md
@@ -38,7 +38,7 @@ For info about testing an AppLocker policy to see what rules affect which files
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how to use these MMC snap-ins to administer
AppLocker, see [Administer AppLocker](administer-applocker.md#bkmk-using-snapins).
-These steps apply only for locally managed devices. If the device has AppLocker policies applied by using MDM or a GPO, the local policy will not override those settings.
+These steps apply only for locally managed devices. If the device has AppLocker policies applied by using MDM or a GPO, the local policy won't override those settings.
## To delete a rule in an AppLocker policy
@@ -72,13 +72,13 @@ To use the Set-AppLockerPolicy cmdlet, first import the AppLocker modules:
PS C:\Users\Administrator> import-module AppLocker
```
-We will create a file (for example, clear.xml), place it in the same directory where we are executing our cmdlet, and add the preceding XML contents. Then run the following command:
+We'll create a file (for example, clear.xml), place it in the same directory where we're executing our cmdlet, and add the preceding XML contents. Then run the following command:
```powershell
C:\Users\Administrator> Set-AppLockerPolicy -XMLPolicy .\clear.xml
```
-This will remove all AppLocker Policies on a machine and could be potentially scripted to use on multiple machines using remote execution tools with accounts with proper access.
+This command will remove all AppLocker Policies on a machine and could be potentially scripted to use on multiple machines using remote execution tools with accounts with proper access.
The following PowerShell commands must also be run to stop the AppLocker services and the effects of the former AppLocker policy.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md b/windows/security/threat-protection/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
index 76c4ee127a..fc69f58037 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md
@@ -41,15 +41,15 @@ For info about how to plan an AppLocker policy deployment, see [AppLocker Design
## Step 1: Retrieve the AppLocker policy
-Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the rule or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md). For local AppLocker policies, you can update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your AppLocker reference or test PC. For the procedures to do this, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
+Updating an AppLocker policy that is currently enforced in your production environment can have unintended results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the rule or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do these tasks, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md). For local AppLocker policies, you can update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your AppLocker reference or test PC. For the procedures to do this task, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
## Step 2: Alter the enforcement setting
-Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if enforcement is not configured and rules are present in a rule collection, those rules are enforced. For information about the enforcement setting, see [Understand AppLocker Enforcement Settings](understand-applocker-enforcement-settings.md). For the procedure to alter the enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
+Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced. For information about the enforcement setting, see [Understand AppLocker Enforcement Settings](understand-applocker-enforcement-settings.md). For the procedure to alter the enforcement setting, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
## Step 3: Update the policy
-You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs. An example of this type of software is the [Advanced Group Policy Management](https://go.microsoft.com/fwlink/p/?LinkId=145013) feature from the
+You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the AppLocker policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of GPOs. An example of this type of software is the [Advanced Group Policy Management](https://go.microsoft.com/fwlink/p/?LinkId=145013) feature from the
Microsoft Desktop Optimization Pack.
>**Caution:** You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
@@ -60,9 +60,9 @@ For the procedures to distribute policies for local PCs by using the Local Secur
## Step 4: Monitor the effect of the policy
-When a policy is deployed, it is important to monitor the actual implementation of that policy. You can do this by monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To monitor the effect of the policy, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
+When a policy is deployed, it's important to monitor the actual implementation of that policy by monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To monitor the effect of the policy, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
-## Additional resources
+## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-group-policy-structure-and-rule-enforcement.md b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-group-policy-structure-and-rule-enforcement.md
index 2d9fdbe7c2..13836e63df 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-group-policy-structure-and-rule-enforcement.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-group-policy-structure-and-rule-enforcement.md
@@ -1,6 +1,6 @@
---
title: Determine the Group Policy structure and rule enforcement (Windows)
-description: This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
+description: This overview topic describes the process to follow when you're planning to deploy AppLocker rules.
ms.assetid: f435fcbe-c7ac-4ef0-9702-729aab64163f
ms.reviewer:
ms.author: dansimp
@@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
+This overview topic describes the process to follow when you're planning to deploy AppLocker rules.
## In this section
@@ -39,10 +39,10 @@ This overview topic describes the process to follow when you are planning to dep
| [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md) | This topic for the IT professional describes how application control policies configured in AppLocker are applied through Group Policy.|
| [Document the Group Policy structure and AppLocker rule enforcement](document-group-policy-structure-and-applocker-rule-enforcement.md) | This planning topic describes what you need to investigate, determine, and record in your application control policies plan when you use AppLocker. |
-When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker policy in your organization, you should consider the following:
+When you're determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker policy in your organization, you should consider the following points:
-- Whether you are creating new GPOs or using existing GPOs
-- Whether you are implementing Software Restriction Policies (SRP) policies and AppLocker policies in the same GPO
+- Whether you're creating new GPOs or using existing GPOs
+- Whether you're implementing Software Restriction Policies (SRP) policies and AppLocker policies in the same GPO
- GPO naming conventions
- GPO size limits
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-which-applications-are-digitally-signed-on-a-reference-computer.md b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
index 656ab2805e..e8313de0e1 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-which-applications-are-digitally-signed-on-a-reference-computer.md
@@ -31,14 +31,14 @@ ms.technology: windows-sec
This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications are digitally signed.
-The Windows PowerShell cmdlet **Get-AppLockerFileInformation** can be used to determine which apps installed on your reference devices are digitally signed. Perform the following steps on each reference computer that you used to define the AppLocker policy. The device does not need to be joined to the domain.
+The Windows PowerShell cmdlet **Get-AppLockerFileInformation** can be used to determine which apps installed on your reference devices are digitally signed. Perform the following steps on each reference computer that you used to define the AppLocker policy. The device doesn't need to be joined to the domain.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
**To determine which apps are digitally signed on a reference device**
1. Run **Get-AppLockerFileInformation** with the appropriate parameters.
- The **Get-AppLockerFileInformation** cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information.
+ The **Get-AppLockerFileInformation** cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information. File information from an event log may not contain all of these fields. Files that aren't signed don't have any publisher information.
2. Analyze the publisher's name and digital signature status from the output of the command.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-your-application-control-objectives.md b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-your-application-control-objectives.md
index bb43e3b175..395698f788 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/determine-your-application-control-objectives.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/determine-your-application-control-objectives.md
@@ -43,17 +43,17 @@ Use the following table to develop your own objectives and determine which appli
|Policy creation|SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO.|AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO.
AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC).|AppLocker policies can be updated by using the Local Security Policy snap-in, if the policies are created locally, or the GPMC, or the Windows PowerShell AppLocker cmdlets.|
|Policy application|SRP policies are distributed through Group Policy.|AppLocker policies are distributed through Group Policy.|
-|Enforcement mode|SRP works in the “deny list mode” where administrators can create rules for files that they don't want to allow in this Enterprise, but the rest of the files are allowed to run by default.
SRP can also be configured in the “allow list mode” such that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|By default, AppLocker works in allow list mode. Only those files are allowed to run for which there's a matching allow rule.|
-|File types that can be controlled|SRP can control the following file types:ExecutablesDLLsScriptsWindows Installers
SRP cannot control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:ExecutablesDLLsScriptsWindows InstallersPackaged apps and installers
AppLocker maintains a separate rule collection for each of the five file types.|
-|Designated file types|SRP supports an extensible list of file types that are considered executable. You can add extensions for files that should be considered executable.|AppLocker doesn't support this. AppLocker currently supports the following file extensions:Executables (.exe, .com)DLLs (.ocx, .dll)Scripts (.vbs, .js, .ps1, .cmd, .bat)Windows Installers (.msi, .mst, .msp)Packaged app installers (.appx)|
+|Enforcement mode|SRP works in the “blocklist mode” where administrators can create rules for files that they don't want to allow in this Enterprise, but the rest of the files are allowed to run by default.
SRP can also be configured in the “allowlist mode” such that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|By default, AppLocker works in allowlist mode. Only those files are allowed to run for which there's a matching allow rule.|
+|File types that can be controlled|SRP can control the following file types:ExecutablesDLLsScriptsWindows Installers
SRP can't control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:ExecutablesDLLsScriptsWindows InstallersPackaged apps and installers
AppLocker maintains a separate rule collection for each of the five file types.|
+|Designated file types|SRP supports an extensible list of file types that are considered executable. You can add extensions for files that should be considered executable.|AppLocker doesn't support this addition of extension. AppLocker currently supports the following file extensions:Executables (.exe, .com)DLLs (.ocx, .dll)Scripts (.vbs, .js, .ps1, .cmd, .bat)Windows Installers (.msi, .mst, .msp)Packaged app installers (.appx)|
|Rule types|SRP supports four types of rules:HashPathSignature
Internet zone|AppLocker supports three types of rules:HashPathPublisher|
|Editing the hash value|SRP allows you to select a file to hash.|AppLocker computes the hash value itself. Internally it uses the SHA2 Authenticode hash for Portable Executables (exe and DLL) and Windows Installers and an SHA2 flat file hash for the rest.|
-|Support for different security levels|With SRP, you can specify the permissions with which an app can run. Then configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.
SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker does not support security levels.|
+|Support for different security levels|With SRP, you can specify the permissions with which an app can run. Then configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.
SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker doesn't support security levels.|
|Manage Packaged apps and Packaged app installers.|Unable|.appx is a valid file type which AppLocker can manage.|
|Targeting a rule to a user or a group of users|SRP rules apply to all users on a particular computer.|AppLocker rules can be targeted to a specific user or a group of users.|
-|Support for rule exceptions|SRP does not support rule exceptions|AppLocker rules can have exceptions that allow administrators to create rules such as “Allow everything from Windows except for Regedit.exe”.|
-|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode that allows administrators to test the effect of their policy in the real production environment without impacting the user experience. Once you are satisfied with the results, you can start enforcing the policy.|
-|Support for exporting and importing policies|SRP does not support policy import/export.|AppLocker supports the importing and exporting of policies. This allows you to create AppLocker policy on a sample computer, test it out and then export that policy and import it back into the desired GPO.|
+|Support for rule exceptions|SRP doesn't support rule exceptions|AppLocker rules can have exceptions that allow administrators to create rules such as “Allow everything from Windows except for Regedit.exe”.|
+|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode that allows administrators to test the effect of their policy in the real production environment without impacting the user experience. Once you're satisfied with the results, you can start enforcing the policy.|
+|Support for exporting and importing policies|SRP doesn't support policy import/export.|AppLocker supports the importing and exporting of policies. This support by AppLocker allows you to create AppLocker policy on a sample computer, test it out and then export that policy and import it back into the desired GPO.|
|Rule enforcement|Internally, SRP rules enforcement happens in user-mode, which is less secure.|Internally, AppLocker rules for exes and dlls are enforced in kernel-mode, which is more secure than enforcing them in the user-mode.|
For more general info, see AppLocker.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md b/windows/security/threat-protection/windows-defender-application-control/applocker/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
index 596ca4a50f..542a15ced2 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/display-a-custom-url-message-when-users-try-to-run-a-blocked-application.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps for displaying a customized message to users when an AppLocker policy denies access to an app.
-Using Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL to redirect users to a support site that contains info about why the user received the error and which apps are allowed. If you do not display a custom message when an apps is blocked, the default access denied message is displayed.
+With the help of Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL to redirect users to a support site that contains info about why the user received the error and which apps are allowed. If you don't display a custom message when an app is blocked, the default access denied message is displayed.
To complete this procedure, you must have the **Edit Setting** permission to edit a GPO. By default, members of the **Domain Admins** group, the **Enterprise Admins** group, and the **Group Policy Creator Owners** group have this permission.
From 77d6dd6017edb14554a354d151d072228782bb9b Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Fri, 1 Jul 2022 18:31:21 +0530
Subject: [PATCH 019/299] Acrolinx Enhancement Effort
---
...tructure-and-applocker-rule-enforcement.md | 6 ++--
.../applocker/edit-an-applocker-policy.md | 23 +++++++-------
.../applocker/maintain-applocker-policies.md | 8 ++---
.../manage-packaged-apps-with-applocker.md | 22 +++++++-------
...r-policies-by-using-set-applockerpolicy.md | 4 +--
.../merge-applocker-policies-manually.md | 6 ++--
...onitor-application-usage-with-applocker.md | 16 +++++-----
...ckaged-app-installer-rules-in-applocker.md | 2 +-
.../plan-for-applocker-policy-management.md | 30 +++++++++----------
.../applocker/refresh-an-applocker-policy.md | 6 ++--
...the-automatically-generate-rules-wizard.md | 8 ++---
.../security-considerations-for-applocker.md | 18 +++++------
.../select-types-of-rules-to-create.md | 12 ++++----
.../test-and-update-an-applocker-policy.md | 18 +++++------
.../applocker/tools-to-use-with-applocker.md | 2 +-
15 files changed, 90 insertions(+), 91 deletions(-)
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/document-group-policy-structure-and-applocker-rule-enforcement.md b/windows/security/threat-protection/windows-defender-application-control/applocker/document-group-policy-structure-and-applocker-rule-enforcement.md
index f21a48c714..24d9b339a4 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/document-group-policy-structure-and-applocker-rule-enforcement.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/document-group-policy-structure-and-applocker-rule-enforcement.md
@@ -40,7 +40,7 @@ To complete this AppLocker planning document, you should first complete the foll
3. [Select the types of rules to create](select-types-of-rules-to-create.md)
4. [Determine the Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md)
-After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they are linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
+After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker policies, you should record your findings. You can use the following table to determine how many GPOs to create (or edit) and which objects they're linked to. If you decided to create custom rules to allow system files to run, note the high-level rule configuration in the **Use default rule or define new rule condition** column.
The following table includes the sample data that was collected when you determined your enforcement settings and the GPO structure for your AppLocker policies.
@@ -49,13 +49,13 @@ The following table includes the sample data that was collected when you determi
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|
-||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition|Allow||
+||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||
||||Internet Explorer 7|C:\Program Files\Internet Explorer
|File is signed; create a publisher condition|Deny||
||||Windows files|C:\Windows|Use a default rule for the Windows path|Allow||
## Next steps
-After you have determined the Group Policy structure and rule enforcement strategy for each business group's apps, the following tasks remain:
+After you've determined the Group Policy structure and rule enforcement strategy for each business group's apps, the following tasks remain:
- [Plan for AppLocker policy management](plan-for-applocker-policy-management.md)
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/edit-an-applocker-policy.md b/windows/security/threat-protection/windows-defender-application-control/applocker/edit-an-applocker-policy.md
index 811e3ab499..5f324a437e 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/edit-an-applocker-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/edit-an-applocker-policy.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps required to modify an AppLocker policy.
-You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
+You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't create a new version of the policy by importing more rules. To modify an AppLocker policy that is in production, you should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You can't automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. For info about merging policies, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) or [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
There are three methods you can use to edit an AppLocker policy:
@@ -44,16 +44,15 @@ There are three methods you can use to edit an AppLocker policy:
## Editing an AppLocker policy by using Group Policy
-The steps to edit an AppLocker policy distributed by Group Policy include the following:
+The steps to edit an AppLocker policy distributed by Group Policy include:
### Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
-AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker
-policy to an XML file. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
+AppLocker provides a feature to export and import AppLocker policies as an XML file. This feature allows you to modify an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For information on the procedure to export this policy, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md).
### Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy maintenance
-After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
+After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:** Importing a policy onto another PC will overwrite the existing policy on that PC.
@@ -61,8 +60,8 @@ After exporting the AppLocker policy to an XML file, you should import the XML f
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
-- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
-- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
+- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
+- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
@@ -70,7 +69,7 @@ AppLocker provides ways to modify, delete, or add rules to a policy by modifying
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
- [Enable the DLL rule collection](enable-the-dll-rule-collection.md)
-- For steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
+- For information on the steps to test an AppLocker policy, see [Test and update an AppLocker policy](test-and-update-an-applocker-policy.md).
- For procedures to export the updated policy from the reference computer back into the GPO, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md).
### Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
@@ -89,7 +88,7 @@ The steps to edit an AppLocker policy distributed by using the Local Security Po
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in (secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
-After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
+After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that you can edit the policy. For information on the procedure to import an AppLocker policy, see [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
>**Caution:** Importing a policy onto another PC will overwrite the existing policy on that PC.
@@ -97,8 +96,8 @@ After exporting the AppLocker policy to an XML file, you should import the XML f
AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
-- For the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
-- For the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
+- For information on the procedure to modify a rule, see [Edit AppLocker rules](edit-applocker-rules.md).
+- For information on the procedure to delete a rule, see [Delete an AppLocker rule](delete-an-applocker-rule.md).
- For procedures to create rules, see:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
@@ -114,6 +113,6 @@ For steps to test an AppLocker policy, see [Test and update an AppLocker policy]
For procedures to export the updated policy from the reference computer to targeted computers, see [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md) and [Import an AppLocker policy from another computer](import-an-applocker-policy-from-another-computer.md).
-## Additional resources
+## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/maintain-applocker-policies.md b/windows/security/threat-protection/windows-defender-application-control/applocker/maintain-applocker-policies.md
index 04db4a506d..97c6d66e6c 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/maintain-applocker-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/maintain-applocker-policies.md
@@ -57,7 +57,7 @@ For every scenario, the steps to maintain an AppLocker policy distributed by Gro
As new apps are deployed or existing apps are removed by your organization or updated by the software publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure that your policy is current.
-You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
+You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the AppLocker policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create
versions of GPOs.
>**Caution:** You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
@@ -74,7 +74,7 @@ Updating an AppLocker policy that is currently enforced in your production envir
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or has been accessed on the local computer, the specific rules can be modified as required.
-To modify AppLocker rules, see the following:
+To modify AppLocker rules, see the following articles:
- [Edit AppLocker rules](edit-applocker-rules.md)
- [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md) or [Merge AppLocker policies manually](merge-applocker-policies-manually.md)
@@ -101,7 +101,7 @@ Before modifying a policy, evaluate how the policy is currently implemented.
### Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
-Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
+Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default, AppLocker rules don't allow users to open or run any files that aren't allowed.
To modify AppLocker rules, see the appropriate topic listed on [Administer AppLocker](administer-applocker.md).
@@ -117,6 +117,6 @@ You can export and then import AppLocker policies to deploy the policy to other
After deploying a policy, evaluate the policy's effectiveness.
-## Additional resources
+## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
\ No newline at end of file
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/manage-packaged-apps-with-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/manage-packaged-apps-with-applocker.md
index 6c12bd897b..477f41380a 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/manage-packaged-apps-with-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/manage-packaged-apps-with-applocker.md
@@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and lists procedures to help
## Understanding Packaged apps and Packaged app installers for AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
-With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
+With packaged apps, it's possible to control the entire app by using a single AppLocker rule.
> [!NOTE]
> AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher because Windows does not support unsigned packaged apps.
@@ -46,8 +46,8 @@ Typically, an app consists of multiple components: the installer that is used to
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
-- **Installing the apps** All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
-- **Changing the system state** Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
+- **Installing the apps** All packaged apps can be installed by a standard user, whereas many classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
+- **Changing the system state** Classic Windows apps can be written to change the system state if they're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your AppLocker policies, it's important to understand whether an app that you're allowing can make system-wide changes.
- **Acquiring the apps** Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
@@ -67,12 +67,12 @@ For info about how to use the **Get-AppxPackage** Windows PowerShell cmdlet, see
For info about creating rules for Packaged apps, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md).
-Consider the following info when you are designing and deploying apps:
+Consider the following info when you're designing and deploying apps:
-- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps is not necessary.
-- You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps were not always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
-- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or
-Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app. This might be contrary to your design.
+- Because AppLocker supports only publisher rules for packaged apps, collecting the installation path information for packaged apps isn't necessary.
+- You can't create hash- or path-based rules for packaged apps because all packaged apps and packaged app installers are signed by the software publisher of the package. Classic Windows apps weren't always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
+- By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi, .msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running Windows Server 2008 R2 and Windows 7 wouldn't have rules for Packaged apps. Therefore, when a computer running at least Windows Server 2012 or
+Windows 8 joins a domain where an AppLocker policy is already configured, users would be allowed to run any packaged app, which is contrary to your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the existing domain policy has rules configured in the exe rule collection. You must take explicit action to allow packaged apps in your enterprise. You can allow only a select set of packaged apps. Or if you want to allow all packaged apps, you can create a default rule for the packaged apps collection.
@@ -80,10 +80,10 @@ Windows 8 joins a domain where an AppLocker policy is already configured, users
Just as there are differences in managing each rule collection, you need to manage the packaged apps with the following strategy:
-1. Gather information about which Packaged apps are running in your environment. For information about how to do this, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
+1. Gather information about which Packaged apps are running in your environment. For information about how to gather this information, see [Create list of apps deployed to each business group](create-list-of-applications-deployed-to-each-business-group.md).
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information, see [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) and [Understanding AppLocker default rules](./understanding-applocker-default-rules.md).
-3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
+3. Continue to update the AppLocker policies as new package apps are introduced into your environment. To do this update, see [Add rules for packaged apps to existing AppLocker rule-set](add-rules-for-packaged-apps-to-existing-applocker-rule-set.md).
-4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
\ No newline at end of file
+4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in AppLocker policies. To do this monitoring, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
\ No newline at end of file
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-by-using-set-applockerpolicy.md b/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-by-using-set-applockerpolicy.md
index 7737b4399b..6d553816d9 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-by-using-set-applockerpolicy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-by-using-set-applockerpolicy.md
@@ -31,13 +31,13 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
-The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter is not specified, then the new policy will overwrite the existing policy.
+The **Set-AppLockerPolicy** cmdlet sets the specified Group Policy Object (GPO) to contain the specified AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default. When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the Merge parameter isn't specified, then the new policy will overwrite the existing policy.
For info about using **Set-AppLockerPolicy**, including syntax descriptions and parameters, see [Set-AppLockerPolicy](/powershell/module/applocker/set-applockerpolicy).
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into Windows PowerShell, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
-You can also manually merge AppLocker policies. For the procedure to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
+You can also manually merge AppLocker policies. For information on the procedure to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md).
**To merge a local AppLocker policy with another AppLocker policy by using LDAP paths**
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for AppLocker, see [Use the AppLocker Windows PowerShell cmdlets](use-the-applocker-windows-powershell-cmdlets.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-manually.md b/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-manually.md
index 4063ae1e66..de6eab6cab 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-manually.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/merge-applocker-policies-manually.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group Policy Object (GPO).
-If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
+If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You can't automatically merge policies by using the AppLocker console. You must create one rule collection from two or more policies. For info about merging policies by using the cmdlet, see [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor. Rule collections are specified within the **RuleCollection Type** element. The XML schema includes five attributes for the different rule collections, as shown in the following table:
@@ -51,7 +51,7 @@ Rule enforcement is specified with the **EnforcementMode** element. The three en
| AuditOnly | Audit only|
| Enabled | Enforce rules|
-Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
+Each of the three condition types uses specific elements. For XML examples of the different rule types, see Merge AppLocker policies manually.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
@@ -63,4 +63,4 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
4. Open the policy where you want to add the copied rules.
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
-7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
+7. Upload the policy to a reference computer to ensure that it's functioning properly within the GPO.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/monitor-application-usage-with-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/monitor-application-usage-with-applocker.md
index a19c80618b..0545d013ef 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/monitor-application-usage-with-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/monitor-application-usage-with-applocker.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
-Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy implementation is what you expected.
+Once you set rules and deploy the AppLocker policies, it's a good practice to determine if the policy implementation is what you expected.
### Discover the effect of an AppLocker policy
@@ -39,27 +39,27 @@ You can evaluate how the AppLocker policy is currently implemented for documenta
- **Analyze the AppLocker logs in Event Viewer**
- When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules are not enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
+ When AppLocker policy enforcement is set to **Enforce rules**, rules are enforced for the rule collection and all events are audited. When AppLocker policy enforcement is set to **Audit only**, rules aren't enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
- For the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
+ For information on the procedure to access the log, see [View the AppLocker Log in Event Viewer](#bkmk-applkr-view-log).
- **Enable the Audit only AppLocker enforcement setting**
By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules are properly configured for your organization. When AppLocker policy enforcement is set to **Audit only**, rules are only evaluated but all events generated from that evaluation are written to the AppLocker log.
- For the procedure to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
+ For information on the procedure to do this configuration, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
- **Review AppLocker events with Get-AppLockerFileInformation**
- For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you are using the audit-only enforcement mode) and how many times the event has occurred for each file.
+ For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if you're using the audit-only enforcement mode) and how many times the event has occurred for each file.
- For the procedure to do this, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
+ For information on the procedure to do this verification, see [Review AppLocker Events with Get-AppLockerFileInformation](#bkmk-applkr-review-events).
- **Review AppLocker events with Test-AppLockerPolicy**
You can use the **Test-AppLockerPolicy** Windows PowerShell cmdlet to determine whether any of the rules in your rule collections will be blocked on your reference device or the device on which you maintain policies.
- For the procedure to do this, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
+ For information on the procedure to do this testing, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
### Review AppLocker events with Get-AppLockerFileInformation
@@ -93,7 +93,7 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
**To view events in the AppLocker log by using Event Viewer**
-1. Open Event Viewer. To do this, click **Start**, type **eventvwr.msc**, and then press ENTER.
+1. Open Event Viewer by clicking **Start**, typing **eventvwr.msc**, and then pressing ENTER.
2. In the console tree under **Application and Services Logs\\Microsoft\\Windows**, double-click **AppLocker**.
AppLocker events are listed in either the **EXE and DLL** log, the **MSI and Script** log, or the **Packaged app-Deployment** or **Packaged app-Execution** log. Event information includes the enforcement setting, file name, date and time, and user name. The logs can be exported to other file
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
index c79be76e77..0ee1ed1988 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md
@@ -32,7 +32,7 @@ ms.technology: windows-sec
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Microsoft Store or can be sideloaded using the Windows PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows applications that sometimes require administrative privileges for installation.
-Typically, an app consists of multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is therefore possible to control an entire app with a single rule.
+Typically, an app consists of multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic Windows applications, not all those components always share common attributes such as the publisher name, product name and product version. Therefore, AppLocker has to control each of these components separately through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a Universal Windows app share the same attributes: Publisher name, Package name and Package version. It's therefore possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single AppLocker rule for a Universal Windows app can control both the installation and the running of an app. Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/plan-for-applocker-policy-management.md b/windows/security/threat-protection/windows-defender-application-control/applocker/plan-for-applocker-policy-management.md
index 2f5df9dc7c..65214802ff 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/plan-for-applocker-policy-management.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/plan-for-applocker-policy-management.md
@@ -1,6 +1,6 @@
---
title: Plan for AppLocker policy management (Windows)
-description: This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
+description: This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
ms.assetid: dccc196f-6ae0-4ae4-853a-a3312b18751b
ms.reviewer:
ms.author: dansimp
@@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-This topic for describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
+This topic describes the decisions you need to make to establish the processes for managing and maintaining AppLocker policies.
## Policy management
@@ -46,23 +46,23 @@ Developing a process for managing AppLocker rules helps assure that AppLocker co
**Help desk support**
-If your organization has an established help desk support department in place, consider the following when deploying AppLocker policies:
+If your organization has an established help desk support department in place, consider the following points when deploying AppLocker policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
-- How will the support department resolve application control issues between the end user and those who maintain the AppLocker rules?
+- How will the support department resolve application control issues between the end user and those resources who maintain the AppLocker rules?
**End-user support**
-Because AppLocker is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
+Because AppLocker is preventing unapproved apps from running, it's important that your organization carefully plans how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
**Using an intranet site**
-AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you do not display a custom URL for the message when an app is blocked, the default URL is used.
+AppLocker can be configured to display the default message but with a custom URL. You can use this URL to redirect users to a support site that contains information about why the user received the error and which applications are allowed. If you don't display a custom URL for the message when an app is blocked, the default URL is used.
The following image shows an example of the error message for a blocked app. You can use the **Set a support web link** policy setting to customize the **More information** link.
@@ -72,7 +72,7 @@ For steps to display a custom URL for the message, see [Display a custom URL mes
**AppLocker event management**
-Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The
+Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The event details which was the file that tried to run, the attributes of that file, the user that initiated the request, and the rule GUID that was used to make the AppLocker execution decision. The
AppLocker event log is located in the following path: **Applications and Services Logs\\Microsoft\\Windows\\AppLocker**. The AppLocker log includes three logs:
1. **EXE and DLL**. Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll, and .ocx).
@@ -83,22 +83,22 @@ Collecting these events in a central location can help you maintain your AppLock
### Policy maintenance
-As new apps are deployed or existing apps are updated by the software publisher, you will need to make revisions to your rule collections to ensure that the policy is current.
+As new apps are deployed or existing apps are updated by the software publisher, you'll need to make revisions to your rule collections to ensure that the policy is current.
-You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](https://go.microsoft.com/fwlink/p/?LinkId=145013) (https://go.microsoft.com/fwlink/p/?LinkId=145013).
+You can edit an AppLocker policy by adding, changing, or removing rules. However, you can't specify a version for the policy by importing more rules. To ensure version control when modifying an AppLocker policy, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack. For more info about Advanced Group Policy Management, see [Advanced Group Policy Management Overview](https://go.microsoft.com/fwlink/p/?LinkId=145013) (https://go.microsoft.com/fwlink/p/?LinkId=145013).
> [!IMPORTANT]
> You should not edit an AppLocker rule collection while it is being enforced in Group Policy. Because AppLocker controls what files are allowed to run, making changes to a live policy can create unexpected behavior.
**New version of a supported app**
-When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you are using publisher conditions and the version is not specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app has not altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
+When a new version of an app is deployed in the organization, you need to determine whether to continue to support the previous version of that app. To add the new version, you might only need to create a new rule for each file that is associated with the app. If you're using publisher conditions and the version isn't specified, then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that the updated app hasn't altered the file names or added files to support new functionality. If so, then you must modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file version, you must also ensure that the file's digital signature is still identical to the previous version—the publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly applied.
To determine whether a file has been modified during an app update, review the publisher's release details provided with the update package. You can also review the publisher's web page to retrieve this information. Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support for a new version and maintain support for the older version, you can either create a new file hash rule for the new version or edit the existing rule and add the new file hash to the list of conditions.
-For files with path conditions, you should verify that the installation path has not changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
+For files with path conditions, you should verify that the installation path hasn't changed from what is stated in the rule. If the path has changed, you need to update the rule before installing the new version of the app
**Recently deployed app**
@@ -114,7 +114,7 @@ A file could be blocked for three reasons:
- The most common reason is that no rule exists to allow the app to run.
- There may be an existing rule that was created for the file that is too restrictive.
-- A deny rule, which cannot be overridden, is explicitly blocking the file.
+- A deny rule, which can't be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can troubleshoot the problem by using the **Test-AppLockerPolicy** Windows PowerShell cmdlet. For more info about troubleshooting an AppLocker policy, see [Testing and Updating an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791793(v=ws.10)) (https://go.microsoft.com/fwlink/p/?LinkId=160269).
@@ -132,7 +132,7 @@ The three key areas to determine for AppLocker policy management are:
1. Support policy
- Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
+ Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel know recommended troubleshooting steps and escalation points for your policy.
2. Event processing
@@ -149,7 +149,7 @@ The following table contains the added sample data that was collected when deter
|Bank Tellers|Teller-East and Teller-West|Yes|Teller Software|C:\Program Files\Woodgrove\Teller.exe|File is signed; create a publisher condition|Allow|Tellers-AppLockerTellerRules|Web help|
||||Windows files|C:\Windows|Create a path exception to the default rule to exclude \Windows\Temp|Allow||Help desk|
|Human Resources|HR-All|Yes|Check Payout|C:\Program Files\Woodgrove\HR\Checkcut.exe|File is signed; create a publisher condition|Allow|HR-AppLockerHRRules|Web help|
-||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File is not signed; create a file hash condition|Allow||Web help|
+||||Time Sheet Organizer|C:\Program Files\Woodgrove\HR\Timesheet.exe|File isn't signed; create a file hash condition|Allow||Web help|
||||Internet Explorer 7|C:\Program Files\Internet Explorer|File is signed; create a publisher condition|Deny||Web help|
||||Windows files|C:\Windows|Use the default rule for the Windows path|Allow||Help desk|
@@ -157,7 +157,7 @@ The following two tables illustrate examples of documenting considerations to ma
**Event processing policy**
-One discovery method for app usage is to set the AppLocker enforcement mode to **Audit only**. This will write events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
+One discovery method for app usage is to set the AppLocker enforcement mode to **Audit only**. This setting will write events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
The following table is an example of what to consider and record.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/refresh-an-applocker-policy.md b/windows/security/threat-protection/windows-defender-application-control/applocker/refresh-an-applocker-policy.md
index e4d36fb82e..9d554232ef 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/refresh-an-applocker-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/refresh-an-applocker-policy.md
@@ -42,7 +42,7 @@ To complete this procedure, you must have Edit Setting permission to edit a GPO
**To manually refresh the AppLocker policy by using Group Policy**
1. From a command prompt, type **gpupdate /force**, and then press ENTER.
-2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy applied."
+2. When the command finishes, close the command prompt window, and then verify that the intended rule behavior is correct. You can do this verification by checking the AppLocker event logs for events that include "policy applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using Group Policy, you first need to update the rule within the rule collection. For information about updating existing rules, see [Edit AppLocker rules](edit-applocker-rules.md). For information
about creating a new rule for an existing policy, see:
@@ -64,8 +64,8 @@ When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
-- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do this, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
+- From the device that you made the change on, export the AppLocker policy, and then import the policy onto the other device. To do these tasks, use the AppLocker **Export Policy** and **Import Policy** features to copy the rules from the changed computer.
>**Caution:** When importing rules from another computer, all the rules will be applied, not just the one that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
-- Merge AppLocker policies. For procedures to do this, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
+- Merge AppLocker policies. For information on the procedures to do this merging, see [Merge AppLocker policies manually](merge-applocker-policies-manually.md) and [Merge AppLocker policies by using Set-ApplockerPolicy](merge-applocker-policies-by-using-set-applockerpolicy.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/run-the-automatically-generate-rules-wizard.md b/windows/security/threat-protection/windows-defender-application-control/applocker/run-the-automatically-generate-rules-wizard.md
index b45234c1a0..807313b37d 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/run-the-automatically-generate-rules-wizard.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/run-the-automatically-generate-rules-wizard.md
@@ -40,15 +40,15 @@ You can perform this task by using the Group Policy Management Console for an Ap
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can automatically generate rules for executable, Windows Installer, script and packaged app rules.
3. Click **Automatically Generate Rules**.
-4. On the **Folder and Permissions** page, click **Browse** to choose the folder to be analyzed. By default, this is the Program Files folder.
-5. Click **Select** to choose the security group in which the default rules should be applied. By default, this is the **Everyone** group.
-6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you have selected. Accept the provided name or type a different name, and then click **Next**.
+4. On the **Folder and Permissions** page, click **Browse** to choose the folder to be analyzed. By default, this folder is the Program Files folder.
+5. Click **Select** to choose the security group in which the default rules should be applied. By default, this group is the **Everyone** group.
+6. The wizard provides a name in the **Name to identify this set of rules** box based on the name of the folder that you've selected. Accept the provided name or type a different name, and then click **Next**.
7. On the **Rule Preferences** page, choose the conditions that you want the wizard to use while creating rules, and then click **Next**. For more info about rule conditions, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
>**Note:** The **Reduce the number of rules created by grouping similar files** check box is selected by default. This helps you organize AppLocker rules and reduce the number of rules that you create by performing the following operations for the rule condition that you select:
- One publisher condition is created for all files that have the same publisher and product name.
- - One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder are not signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
+ - One path condition is created for the folder that you select. For example, if you select *C:\\Program Files\\ProgramName\\* and the files in that folder aren't signed, the wizard creates a rule for *%programfiles%\\ProgramName\\\**.
- One file hash condition is created that contains all of the file hashes. When rule grouping is disabled, the wizard creates a file hash rule for each file.
8. Review the files that were analyzed and the rules that will be automatically created. To make changes, click **Previous** to return to the page where you can change your selections. After reviewing the rules, click **Create**.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/security-considerations-for-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/security-considerations-for-applocker.md
index 3b58e12ab7..8aebe54030 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/security-considerations-for-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/security-considerations-for-applocker.md
@@ -34,26 +34,26 @@ This topic for the IT professional describes the security considerations you nee
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software, to a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
-AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials. This makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
+AppLocker is deployed within an enterprise and administered centrally by those resources in IT with trusted credentials. This system makes its policy creation and deployment conform to similar policy deployment processes and security restrictions.
-AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
+AppLocker policies are distributed through known processes and by known means within the domain through Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator privileges, and those policies might be contrary to the organization's written security policy. The enforcement settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO). However, because AppLocker rules are additive, a local policy that isn't in a GPO will still be evaluated for that computer.
-Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
+Microsoft doesn't provide a way to develop any extensions to AppLocker. The interfaces aren't public. A user with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets. For info about the Windows PowerShell cmdlets for AppLocker, see the [AppLocker Cmdlets in Windows PowerShell](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
-AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer. If the local computer is not joined to a domain and is not administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
+AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO that contains the AppLocker rule for the same file (or path) that was changed on the local device. However, because AppLocker rules are additive, a local policy that isn't in a GPO will still be evaluated for that computer. If the local computer isn't joined to a domain and isn't administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
-When securing files in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
+When files are being secured in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it's still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
-AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
+AppLocker doesn't protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or later when there's already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
-You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
+You can't use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
-AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of interpreted code, such as Microsoft Office macros.
+AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It doesn't control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker can't control every kind of interpreted code, such as Microsoft Office macros.
> [!IMPORTANT]
> You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
-AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior of applications after they are launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
+AppLocker rules either allow or prevent an application from launching. AppLocker doesn't control the behavior of applications after they're launched. Applications could contain flags passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must thoroughly examine each application before allowing them to run by using AppLocker rules.
> [!NOTE]
> Two flags that illustrate this condition are `SANDBOX_INERT`, which can be passed to `CreateRestrictedToken`, and `LOAD_IGNORE_CODE_AUTHZ_LEVEL`, which can be passed to `LoadLibraryEx`. Both of these flags signal AppLocker to circumvent the rules and allow a child .exe or .dll to be loaded.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/applocker/select-types-of-rules-to-create.md
index 0e46c32873..a8f29966da 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/select-types-of-rules-to-create.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/select-types-of-rules-to-create.md
@@ -52,7 +52,7 @@ The rules you create will be in one of the following rule collections:
- Packaged apps and packaged app installers: .appx
- DLLs: .dll and .ocx
-By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled by default.
+By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection isn't enabled by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\\Program Files\\Woodgrove\\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a list of allowed applications, all the Windows files under C:\\Windows must be included as well.
@@ -66,13 +66,13 @@ A rule condition is criteria upon which an AppLocker rule is based and can only
| Path| Any file can be assigned this rule condition; however, because path rules specify locations within the file system, any subdirectory will also be affected by the rule (unless explicitly exempted).| For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md). |
| File hash | Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the file is released because the hash value is based in part upon the version.| For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md). |
-In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
+In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is located at C:\\Program Files\\Woodgrove\\Teller.exe. Therefore, the rule can be defined with a publisher condition. If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this rule will allow any updates to this app to occur without interruption of access to the users if the app's name and signed attributes stay the same.
### Determine how to allow system files to run
-Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules (listed in [AppLocker default rules](working-with-applocker-rules.md#applocker-default-rules)) as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule collection.
+Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by generating the default rules for each rule collection. You can use the default rules (listed in [AppLocker default rules](working-with-applocker-rules.md#applocker-default-rules)) as a template when creating your own rules. However, these rules are only meant to function as a starter policy when you're first testing AppLocker rules so that the system files in the Windows folders will be allowed to run. When a default rule is created, it's denoted with "(Default rule)" in its name as it appears in the rule collection.
-You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This will permit access to these files whenever updates are applied and the files change. If you require additional application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
+You can also create a rule for the system files based on the path condition. In the preceding example, for the Bank Tellers group, all Windows files reside under C:\\Windows and can be defined with the path rule condition type. This rule will permit access to these files whenever updates are applied and the files change. If you require more application security, you might need to modify the rules created from the built-in default rule collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp subfolder to which the Users group is given the following permissions:
- Traverse Folder/Execute File
- Create Files/Write Data
@@ -82,6 +82,6 @@ These permissions settings are applied to this folder for application compatibil
## Next steps
-After you have selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
+After you've selected the types of rules to create, record your findings as explained in [Document your AppLocker rules](document-your-applocker-rules.md).
-After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the rules. For info about how to do this, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
+After recording your findings for the AppLocker rules to create, you'll need to consider how to enforce the rules. For information about how to do this enforcement, see [Determine Group Policy structure and rule enforcement](determine-group-policy-structure-and-rule-enforcement.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md b/windows/security/threat-protection/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md
index e94dd7e02a..7767e8d4db 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md
@@ -35,42 +35,42 @@ You should test each set of rules to ensure that the rules perform as intended.
## Step 1: Enable the Audit only enforcement setting
-By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules that you have created are properly configured for your organization. This setting can be enabled on the **Enforcement** tab of the **AppLocker Properties** dialog box. For the procedure to do this, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
+By using the **Audit only** enforcement setting, you can ensure that the AppLocker rules that you have created are properly configured for your organization. This setting can be enabled on the **Enforcement** tab of the **AppLocker Properties** dialog box. For information on the procedure to do this configuration, see [Configure an AppLocker policy for audit only](configure-an-applocker-policy-for-audit-only.md).
## Step 2: Configure the Application Identity service to start automatically
-Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to start automatically in any one GPO that applies AppLocker rules. For the procedure to do this, see [Configure the Application Identity Service](configure-the-application-identity-service.md). For AppLocker policies that are not managed by a GPO, you must ensure that the service is running on each PC in order for the policies to be applied.
+Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to start automatically in any one GPO that applies AppLocker rules. For information on the procedure to do this configuration, see [Configure the Application Identity Service](configure-the-application-identity-service.md). For AppLocker policies that aren't managed by a GPO, you must ensure that the service is running on each PC in order for the policies to be applied.
## Step 3: Test the policy
-Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created AppLocker rules, enabled the Application Identity service, and enabled the **Audit only** enforcement setting, the AppLocker policy should be present on all client PC that are configured to receive your AppLocker policy.
+Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created AppLocker rules, enabled the Application Identity service, and enabled the **Audit only** enforcement setting, the AppLocker policy should be present on all client PCs that are configured to receive your AppLocker policy.
-The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference PCs. For the procedure to do this, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
+The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference PCs. For information on the procedure to do this testing, see [Test an AppLocker policy by using Test-AppLockerPolicy](test-an-applocker-policy-by-using-test-applockerpolicy.md).
## Step 4: Analyze AppLocker events
You can either manually analyze AppLocker events or use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to automate the analysis.
**To manually analyze AppLocker events**
-You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis, such as looking for patterns in application usage events, access frequencies, or access by user groups. If you have not configured an event subscription, then you will have to review the logs on a sampling of computers in your organization. For more information about using Event Viewer, see [Monitor application usage with AppLocker](monitor-application-usage-with-applocker.md).
+You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis, such as looking for patterns in application usage events, access frequencies, or access by user groups. If you haven't configured an event subscription, then you'll have to review the logs on a sampling of computers in your organization. For more information about using Event Viewer, see [Monitor application usage with AppLocker](monitor-application-usage-with-applocker.md).
**To analyze AppLocker events by using Get-AppLockerFileInformation**
You can use the **Get-AppLockerFileInformation** Windows PowerShell cmdlet to analyze AppLocker events from a remote computer. If an app is being blocked and should be allowed, you can use the AppLocker cmdlets to help troubleshoot the problem.
-For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** cmdlet to determine which files have been blocked or would have been blocked (if you are using the **Audit only** enforcement mode) and how many times the event has occurred for each file. For the procedure to do this, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
+For both event subscriptions and local events, you can use the **Get-AppLockerFileInformation** cmdlet to determine which files have been blocked or would have been blocked (if you're using the **Audit only** enforcement mode) and how many times the event has occurred for each file. For information on the procedure to do this monitoring, see [Monitor Application Usage with AppLocker](monitor-application-usage-with-applocker.md).
-After using **Get-AppLockerFileInformation** to determine how many times that a file would have been blocked from running, you should review your rule list to determine whether a new rule should be created for the blocked file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently preventing the file from running. To determine this, you can use the Group Policy Results Wizard to view rule names.
+After using **Get-AppLockerFileInformation** to determine how many times that a file would have been blocked from running, you should review your rule list to determine whether a new rule should be created for the blocked file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently preventing the file from running. To determine this blocker GPO, you can use the Group Policy Results Wizard to view rule names.
## Step 5: Modify the AppLocker policy
-After you have identified which rules need to be edited or added to the policy, you can use the Group Policy Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that are not managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an AppLocker policy, see, [Edit an AppLocker policy](edit-an-applocker-policy.md).
+After you've identified which rules need to be edited or added to the policy, you can use the Group Policy Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that aren't managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an AppLocker policy, see, [Edit an AppLocker policy](edit-an-applocker-policy.md).
## Step 6: Repeat policy testing, analysis, and policy modification
Repeat the previous steps 3–5 until all the rules perform as intended before applying enforcement.
-## Additional resources
+## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/tools-to-use-with-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/tools-to-use-with-applocker.md
index 25bb78c4e1..fd88f08362 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/tools-to-use-with-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/tools-to-use-with-applocker.md
@@ -49,7 +49,7 @@ The following tools can help you administer the application control policies cre
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy Management Console (GPMC).
- If you want additional features to manage AppLocker policies, such as version control, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
+ If you want more features to manage AppLocker policies, such as version control, use Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization Pack.
- **Remote Server Administration Tools (RSAT)**
From 2b2ddbdffeb6b38ab6b9fe4aae36e322287b5b2e Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Mon, 4 Jul 2022 12:54:39 +0530
Subject: [PATCH 020/299] Acrolinx Enhancement Effort
---
...derstand-applocker-enforcement-settings.md | 4 +-
...stand-applocker-policy-design-decisions.md | 50 +++++++++----------
.../understanding-applocker-rule-behavior.md | 2 +-
...understanding-applocker-rule-exceptions.md | 4 +-
...e-file-hash-rule-condition-in-applocker.md | 6 +--
...ng-the-path-rule-condition-in-applocker.md | 8 +--
...e-publisher-rule-condition-in-applocker.md | 12 ++---
...-create-and-maintain-applocker-policies.md | 14 +++---
...restriction-policies-in-the-same-domain.md | 16 +++---
...he-applocker-windows-powershell-cmdlets.md | 4 +-
.../using-event-viewer-with-applocker.md | 18 +++----
...riction-policies-and-applocker-policies.md | 10 ++--
.../applocker/what-is-applocker.md | 4 +-
.../applocker/working-with-applocker-rules.md | 46 ++++++++---------
...-apps-deployed-with-a-managed-installer.md | 14 +++---
15 files changed, 106 insertions(+), 106 deletions(-)
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-enforcement-settings.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-enforcement-settings.md
index 9b7c321d4e..f99766832e 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-enforcement-settings.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-enforcement-settings.md
@@ -31,11 +31,11 @@ ms.technology: windows-sec
This topic describes the AppLocker enforcement settings for rule collections.
-Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule collections, see [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md). By default, if enforcement is not configured and rules are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement settings in Group Policy for each rule collection.
+Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule collections, see [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md). By default, if enforcement isn't configured and rules are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule enforcement settings in Group Policy for each rule collection.
| Enforcement setting | Description |
| - | - |
-| Not configured | By default, enforcement is not configured in a rule collection. If rules are present in the corresponding rule collection, they are enforced. If rule enforcement is configured in a higher-level linked Group Policy object (GPO), that enforcement value overrides the **Not configured** value.|
+| Not configured | By default, enforcement isn't configured in a rule collection. If rules are present in the corresponding rule collection, they're enforced. If rule enforcement is configured in a higher-level linked Group Policy object (GPO), that enforcement value overrides the **Not configured** value.|
| Enforce rules | Rules are enforced for the rule collection, and all rule events are audited.|
| Audit only | Rule events are audited only. Use this value when planning and testing AppLocker rules.|
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md
index c14abfaefc..fb22ebb52e 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understand-applocker-policy-design-decisions.md
@@ -1,6 +1,6 @@
---
title: Understand AppLocker policy design decisions (Windows)
-description: Review some common considerations while you are planning to use AppLocker to deploy application control policies within a Windows environment.
+description: Review some common considerations while you're planning to use AppLocker to deploy application control policies within a Windows environment.
ms.assetid: 3475def8-949a-4b51-b480-dc88b5c1e6e6
ms.reviewer:
ms.author: macapara
@@ -42,34 +42,34 @@ You should consider using AppLocker as part of your organization's application c
- You have resources to involve Help Desk or to build a self-help process for end-user application access issues.
- The group's requirements for productivity, manageability, and security can be controlled by restrictive policies.
-The following questions are not in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
+The following questions aren't in priority or sequential order. They should be considered when you deploy application control policies (as appropriate for your targeted environment).
### Which apps do you need to control in your organization?
-You might need to control a limited number of apps because they access sensitive data, or you might have to exclude all applications except those that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
+You might need to control a limited number of applications because they access sensitive data, or you might have to exclude all applications except those applications that are sanctioned for business purposes. There might be certain business groups that require strict control, and others that promote independent application usage.
| Possible answers | Design considerations|
| - | - |
| Control all apps | AppLocker policies control applications by creating an allowed list of applications by file type. Exceptions are also possible. AppLocker policies can only be applied to applications installed on computers running one of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
-| Control specific apps | When you create AppLocker rules, a list of allowed apps is created. All apps on that list will be allowed to run (except those on the exception list). Apps that are not on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
+| Control specific apps | When you create AppLocker rules, a list of allowed apps is created. All applications on that list will be allowed to run (except those applications on the exception list). Applications that aren't on the list will be prevented from running. AppLocker policies can only be applied to apps installed on computers running any of the supported versions of Windows. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).|
|Control only Classic Windows applications, only Universal Windows apps, or both| AppLocker policies control apps by creating an allowed list of apps by file type. Because Universal Windows apps are categorized under the Publisher condition, Classic Windows applications and Universal Windows apps can be controlled together. AppLocker policies for Universal Windows apps can be applied only to apps that are installed on PCs that support the Microsoft Store, but Classic Windows applications can be controlled with AppLocker on all supported versions of Windows. The rules you currently have configured for Classic Windows applications can remain, and you can create new ones for Universal Windows apps.
For a comparison of Classic Windows applications and Universal Windows apps, see [Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions](#bkmk-compareclassicmetro) in this topic.|
| Control apps by business group and user | AppLocker policies can be applied through a Group Policy Object (GPO) to computer objects within an organizational unit (OU). Individual AppLocker rules can be applied to individual users or to groups of users.|
-| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure is not based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you will have to identify users, their computers, and their app access requirements.|
-|Understand app usage, but there is no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.|
+| Control apps by computer, not user | AppLocker is a computer-based policy implementation. If your domain or site organizational structure isn't based on a logical user structure, such as an OU, you might want to set up that structure before you begin your AppLocker planning. Otherwise, you'll have to identify users, their computers, and their app access requirements.|
+|Understand app usage, but there's no need to control any apps yet | AppLocker policies can be set to audit app usage to help you track which apps are used in your organization. You can then use the AppLocker event log to create AppLocker policies.|
> [!IMPORTANT]
> The following list contains files or types of files that cannot be managed by AppLocker:
-- AppLocker does not protect against running 16-bit DOS binaries in an NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there is already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
+- AppLocker doesn't protect against running 16-bit DOS binaries in an NT Virtual DOS Machine (NTVDM). This technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386 or higher when there's already another operating system running and controlling the hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to otherwise block binaries and libraries. If it's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the Executable rule collection for NTVDM.exe.
-- You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
+- You can't use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's a requirement to prevent applications from running in the POSIX subsystem, you must disable the subsystem.
-- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does not control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros.
+- AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It doesn't control all interpreted code that runs within a host process, for example Perl scripts and macros. Interpreted code is a form of executable code that runs within a host process. For example, Windows batch files (\*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to control interpreted code, the host process must call AppLocker before it runs the interpreted code, and then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker. Therefore, AppLocker can't control every kind of interpreted code, for example Microsoft Office macros.
> [!IMPORTANT]
> You should configure the appropriate security settings of these host processes if you must allow them to run. For example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
-- AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of apps after they are launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules.
+- AppLocker rules allow or prevent an app from launching. AppLocker doesn't control the behavior of apps after they're launched. Applications could contain flags that are passed to functions that signal AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must follow a process that best suits your needs to thoroughly vet each app before allowing them to run using AppLocker rules.
For more info, see [Security considerations for AppLocker](security-considerations-for-applocker.md).
@@ -77,8 +77,8 @@ You might need to control a limited number of apps because they access sensitive
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers running Windows operating systems that support Microsoft Store apps. However, Classic Windows applications can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be enforced together. The differences you should consider for Universal Windows apps are:
-- All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
-- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps cannot change the system state because they run with limited permissions. When you design your AppLocker policies, it is important to understand whether an app that you are allowing can make system-wide changes.
+- All Universal Windows apps can be installed by a standard user, whereas many Classic Windows applications require administrative credentials to install. So in an environment where most of the users are standard users, you might not need numerous exe rules, but you might want more explicit policies for packaged apps.
+- Classic Windows applications can be written to change the system state if they run with administrative credentials. Most Universal Windows apps can't change the system state because they run with limited permissions. When you design your AppLocker policies, it's important to understand whether an app that you're allowing can make system-wide changes.
- Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means, such as through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both.
@@ -91,7 +91,7 @@ Most organizations have evolved app control policies and methods over time. With
| Possible answers | Design considerations |
| - | - |
-| Security polices (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this results in a simpler distribution method.|
+| Security policies (locally set or through Group Policy) | Using AppLocker requires increased effort in planning to create correct policies, but this policy creation results in a simpler distribution method.|
| Non-Microsoft app control software | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Managed usage by group or OU | Using AppLocker requires a complete app control policy evaluation and implementation.|
| Authorization Manager or other role-based access technologies | Using AppLocker requires a complete app control policy evaluation and implementation.|
@@ -103,7 +103,7 @@ If your organization supports multiple Windows operating systems, app control po
|Possible answers|Design considerations|
|--- |--- |
-|Your organization's computers are running a combination of the following operating systems:Windows 11Windows 10Windows 8Windows 7Windows VistaWindows XPWindows Server 2012Windows Server 2008 R2Windows Server 2008Windows Server 2003|AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
**Note:** If you are using the Basic User security level as assigned in SRP, those privileges are not supported on computers running that support AppLocker.
AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way.|
+|Your organization's computers are running a combination of the following operating systems:Windows 11Windows 10Windows 8Windows 7Windows VistaWindows XPWindows Server 2012Windows Server 2008 R2Windows Server 2008Windows Server 2003|AppLocker rules are only applied to computers running the supported versions of Windows, but SRP rules can be applied to all versions of Windows beginning with Windows XP and Windows Server 2003. For specific operating system version requirements, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
**Note:** If you're using the Basic User security level as assigned in SRP, those privileges aren't supported on computers running that support AppLocker.
AppLocker policies as applied through a GPO take precedence over SRP policies in the same or linked GPO. SRP policies can be created and maintained the same way.|
|Your organization's computers are running only the following operating systems:Windows 11Windows 10Windows 8.1Windows 8Windows 7Windows Server 2012 R2Windows Server 2012Windows Server 2008 R2|Use AppLocker to create your application control policies.|
### Are there specific groups in your organization that need customized application control policies?
@@ -112,7 +112,7 @@ Most business groups or departments have specific security requirements that per
| Possible answers | Design considerations |
| - | - |
-| Yes | For each group, you need to create a list that includes their application control requirements. Although this may increase the planning time, it will most likely result in a more effective deployment.
If your GPO structure is not currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.|
+| Yes | For each group, you need to create a list that includes their application control requirements. Although this consideration may increase the planning time, it will most likely result in a more effective deployment.
If your GPO structure isn't currently configured so that you can apply different policies to specific groups, you can alternatively apply AppLocker rules in a GPO to specific user groups.|
| No | AppLocker policies can be applied globally to applications that are installed on PCs running the supported versions of Windows as listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). Depending on the number of apps you need to control, managing all the rules and exceptions might be challenging.|
### Does your IT department have resources to analyze application usage, and to design and manage the policies?
@@ -121,12 +121,12 @@ The time and resources that are available to you to perform the research and ana
| Possible answers | Design considerations |
| - | - |
-| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as simply constructed as possible.|
-| No | Consider a focused and phased deployment for specific groups by using a small number of rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. |
+| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are as constructed as possible.|
+| No | Consider a focused and phased deployment for specific groups by using a few rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. |
### Does your organization have Help Desk support?
-Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.
+Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow isn't hampered.
| Possible answers | Design considerations |
| - | - |
@@ -140,7 +140,7 @@ Any successful application control policy implementation is based on your knowle
| Possible answers | Design considerations |
| - | - |
| Yes | You should determine the application control priorities for a business group and then attempt to design the simplest scheme for their application control policies. |
-| No | You will have to perform an audit and requirements gathering project to discover the application usage. AppLocker provides the means to deploy policies in **Audit only** mode, and tools to view the event logs.|
+| No | You'll have to perform an audit and requirements gathering project to discover the application usage. AppLocker provides the means to deploy policies in **Audit only** mode, and tools to view the event logs.|
### How do you deploy or sanction applications (upgraded or new) in your organization?
@@ -159,7 +159,7 @@ Although SRP and AppLocker have the same goal, AppLocker is a major revision of
| Possible answers | Design considerations |
| - | - |
-| Yes | You cannot use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running on any of the supported operating systems listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). In addition, if AppLocker and SRP settings are configured in the same GPO, only the AppLocker settings will be enforced on computers running those supported operating systems.
**Note:** If you are using the Basic User security level as assigned in SRP, those permissions are not supported on computers running the supported operating systems.|
+| Yes | You can't use AppLocker to manage SRP settings, but you can use SRP to manage application control policies on computers running on any of the supported operating systems listed in [Requirements to use AppLocker](requirements-to-use-applocker.md). In addition, if AppLocker and SRP settings are configured in the same GPO, only the AppLocker settings will be enforced on computers running those supported operating systems.
**Note:** If you're using the Basic User security level as assigned in SRP, those permissions aren't supported on computers running the supported operating systems.|
| No | Policies that are configured for AppLocker can only be applied to computers running the supported operating systems, but SRP is also available on those operating systems. |
### What are your organization's priorities when implementing application control policies?
@@ -168,19 +168,19 @@ Some organizations will benefit from application control policies as shown by an
| Possible answers | Design considerations |
| - | - |
-| Productivity: The organization assures that tools work and required applications can be installed. | To meet innovation and productivity goals, some groups require the ability to install and run a variety of software from different sources, including software that they developed. Therefore, if innovation and productivity is a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress. |
-| Management: The organization is aware of and controls the apps it supports. | In some business groups, application usage can be managed from a central point of control. AppLocker policies can be built into a GPO for that purpose. This shifts the burden of app access to the IT department, but it also has the benefit of controlling the number of apps that can be run and controlling the versions of those apps|
+| Productivity: The organization assures that tools work and required applications can be installed. | To meet innovation and productivity goals, some groups require the ability to install and run various softwares from different sources, including software that they developed. Therefore, if innovation and productivity are a high priority, managing application control policies through an allowed list might be time consuming and an impediment to progress. |
+| Management: The organization is aware of and controls the applications it supports. | In some business groups, application usage can be managed from a central point of control. AppLocker policies can be built into a GPO for that purpose. This GPO shifts the burden of application access to the IT department, but it also has the benefit of controlling the number of applications that can be run and controlling the versions of those applications|
| Security: The organization must protect data in part by ensuring that only approved apps are used. | AppLocker can help protect data by allowing a defined set of users access to apps that access the data. If security is the top priority, the application control policies will be the most restrictive.|
### How are apps currently accessed in your organization?
-AppLocker is very effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers that are connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a small number of rules.
+AppLocker is effective for organizations that have application restriction requirements if they have environments with a simple topography and application control policy goals that are straightforward. For example, AppLocker can benefit an environment where non-employees have access to computers that are connected to the organizational network, such as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers with a relatively small number of applications to manage, or when the applications are manageable with a few rules.
| Possible answers | Design considerations |
| - | - |
| Users run without administrative rights. | Apps are installed by using an installation deployment technology.|
-| AppLocker can help reduce the total cost of ownership for business groups that typically use a finite set of apps, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using AppLocker to create rules for specific apps that are allowed to run, you can help limit unauthorized applications from accessing this information.
**Note:** AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it is important to note that users with administrative credentials can add new rules to the local AppLocker policy.| Users must be able to install applications as needed.
-| Users currently have administrator access, and it would be difficult to change this.|Enforcing AppLocker rules is not suited for business groups that must be able to install apps as needed and without approval from the IT department. If one or more OUs in your organization has this requirement, you can choose not to enforce application rules in those OUs by using AppLocker or to implement the **Audit only** enforcement setting through AppLocker.|
+| AppLocker can help reduce the total cost of ownership for business groups that typically use a finite set of apps, such as human resources and finance departments. At the same time, these departments access highly sensitive information, much of which contains confidential and proprietary information. By using AppLocker to create rules for specific apps that are allowed to run, you can help limit unauthorized applications from accessing this information.
**Note:** AppLocker can also be effective in helping create standardized desktops in organizations where users run as administrators. However, it's important to note that users with administrative credentials can add new rules to the local AppLocker policy.| Users must be able to install applications as needed.
+| Users currently have administrator access, and it would be difficult to change this privilege.|Enforcing AppLocker rules isn't suited for business groups that must be able to install apps as needed and without approval from the IT department. If one or more OUs in your organization has this requirement, you can choose not to enforce application rules in those OUs by using AppLocker or to implement the **Audit only** enforcement setting through AppLocker.|
### Is the structure in Active Directory Domain Services based on the organization's hierarchy?
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-behavior.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-behavior.md
index 92bd84efc4..5afe6be646 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-behavior.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-behavior.md
@@ -36,7 +36,7 @@ If no AppLocker rules for a specific rule collection exist, all files with that
A rule can be configured to use either an allow or deny action:
- **Allow**. You can specify which files are allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
-- **Deny**. You can specify which files are not allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
+- **Deny**. You can specify which files aren't allowed to run in your environment and for which users or groups of users. You can also configure exceptions to identify files that are excluded from the rule.
>**Important:** You can use a combination of allow actions and deny actions. However, we recommend using allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run the file from any other path.
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-exceptions.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-exceptions.md
index 295497d103..d4eab6bcf6 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-exceptions.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-applocker-rule-exceptions.md
@@ -33,9 +33,9 @@ This topic describes the result of applying AppLocker rule exceptions to rule co
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset.
-For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows binaries, but does not allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception of the rule).
+For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows binaries, but doesn't allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception for the rule).
The effect of this rule would prevent users such as Helpdesk personnel from running the Registry Editor, a program that is necessary for their support tasks.
-To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor" and add %WINDIR%\regedit.exe as an allowed path. If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor.
+To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run Registry Editor" and add %WINDIR%\regedit.exe as an allowed path. If you create a deny rule that doesn't allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user group to run Registry Editor.
## Related topics
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-file-hash-rule-condition-in-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-file-hash-rule-condition-in-applocker.md
index 2a8b980f8f..9e63783239 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-file-hash-rule-condition-in-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-file-hash-rule-condition-in-applocker.md
@@ -1,6 +1,6 @@
---
title: Understanding the file hash rule condition in AppLocker (Windows)
-description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
+description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
ms.assetid: 4c6d9af4-2b1a-40f4-8758-1a6f9f147756
ms.reviewer:
ms.author: macapara
@@ -29,9 +29,9 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is applied.
+This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
-File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
+File hash rules use a system-computed cryptographic hash of the identified file. For files that aren't digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
| File hash condition advantages | File hash condition disadvantages |
| - | - |
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-path-rule-condition-in-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-path-rule-condition-in-applocker.md
index 4aa28b9f43..e47540ebc1 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-path-rule-condition-in-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-path-rule-condition-in-applocker.md
@@ -1,6 +1,6 @@
---
title: Understanding the path rule condition in AppLocker (Windows)
-description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
+description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
ms.assetid: 3fa54ded-4466-4f72-bea4-2612031cad43
ms.reviewer:
ms.author: macapara
@@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
+This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
The path condition identifies an application by its location in the file system of the computer or on the network.
@@ -39,11 +39,11 @@ When creating a rule that uses a deny action, path conditions are less secure th
|--- |--- |
|You can easily control many folders or a single file.You can use the asterisk (*) as a wildcard character within path rules.|It might be less secure if a rule that is configured to use a folder path contains subfolders that are writable by non-administrators.You must specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.|
-AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.
+AppLocker doesn't enforce rules that specify paths with short names. You should always specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.
The asterisk (\*) wildcard character can be used within **Path** field. The asterisk (\*) character used by itself represents any path. When combined with any string value, the rule is limited to the path of the file and all the files under that path. For example, %ProgramFiles%\\Internet Explorer\\\* indicates that all files and subfolders within the Internet Explorer folder will be affected by the rule.
-AppLocker uses path variables for well-known directories in Windows. Path variables are not environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
+AppLocker uses path variables for well-known directories in Windows. Path variables aren't environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
| Windows directory or drive | AppLocker path variable | Windows environment variable |
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker.md
index 55d9299a0f..22ab048b3b 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker.md
@@ -1,6 +1,6 @@
---
title: Understanding the publisher rule condition in AppLocker (Windows)
-description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
+description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
ms.assetid: df61ed8f-a97e-4644-9d0a-2169f18c1c4f
ms.reviewer:
ms.author: macapara
@@ -29,25 +29,25 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
+This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on its digital signature and extended attributes. The digital signature contains information about the company that created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain the name of the product that the app is part of and the version number of the app. The publisher may be a software development company, such as Microsoft, or the Information Technology department of your organization.
-Publisher conditions are easier to maintain than file hash conditions and are generally more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages
+Publisher conditions are easier to maintain than file hash conditions and are more secure than path conditions. Rules that are specified to the version level might have to be updated when a new version of the file is released. The following table describes the advantages and disadvantages
of the publisher condition.
|Publisher condition advantages|Publisher condition disadvantages|
|--- |--- |
-|Frequent updating is not required.You can apply different values within a certificate.A single rule can be used to allow an entire product suite.You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|The file must be signed.Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
+|Frequent updating isn't required.You can apply different values within a certificate.A single rule can be used to allow an entire product suite.You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|The file must be signed.Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
- **Publisher**
- The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. For example, using the characters "M\*" limits the publisher name to only a publisher with the name "M\*." Using the characters "\*x\*" limits the publisher name only to the name “\*x\*”. A question mark (?) is not a valid wildcard character in this field.
+ The asterisk (\*) character used by itself represents any publisher. When combined with any string value, the rule is limited to the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk isn't treated as a wildcard character if used with other characters in this field. For example, using the characters "M\*" limits the publisher name to only a publisher with the name "M\*." Using the characters "\*x\*" limits the publisher name only to the name “\*x\*”. A question mark (?) isn't a valid wildcard character in this field.
- **Product name**
- The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk is not treated as a wildcard character if used with other characters in this field. A question mark (?) is not a valid wildcard character in this field.
+ The asterisk (\*) character used by itself represents any product name. When combined with any string value, the rule is limited to the product of the publisher with a value in the signed certificate that matches the character string. In other words, the asterisk isn't treated as a wildcard character if used with other characters in this field. A question mark (?) isn't a valid wildcard character in this field.
- **File name**
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/use-a-reference-computer-to-create-and-maintain-applocker-policies.md b/windows/security/threat-protection/windows-defender-application-control/applocker/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
index e054f32aa9..a5ef9054dc 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/use-a-reference-computer-to-create-and-maintain-applocker-policies.md
@@ -33,7 +33,7 @@ This topic for the IT professional describes the steps to create and maintain Ap
## Background and prerequisites
-An AppLocker reference device is a baseline device you can use to configure policies and can subsequently be used to maintain AppLocker policies. For the procedure to configure a reference device, see [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md).
+An AppLocker reference device is a baseline device you can use to configure policies and can then be used to maintain AppLocker policies. For the procedure to configure a reference device, see [Configure the AppLocker reference device](configure-the-appLocker-reference-device.md).
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the corresponding apps for each organizational unit (OU) to mimic your production environment.
@@ -43,7 +43,7 @@ You can perform AppLocker policy testing on the reference device by using the **
## Step 1: Automatically generate rules on the reference device
-With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified folder and creates the condition types that you choose for each file in that folder. For the procedure to do this, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
+With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified folder and creates the condition types that you choose for each file in that folder. For information on how to automatically generate rules, see [Run the Automatically Generate Rules wizard](run-the-automatically-generate-rules-wizard.md).
>**Note:** If you run this wizard to create your first rules for a Group Policy Object (GPO), after you complete the wizard, you will be prompted to create the default rules, which allow critical system files to run. You can edit the default rules at any time. If your organization has decided to edit the default rules or create custom rules to allow the Windows system files to run, ensure that you delete the default rules after you replace them with your custom rules.
@@ -55,7 +55,7 @@ AppLocker includes default rules for each rule collection. These rules are inten
## Step 3: Modify rules and the rule collection on the reference device
-If AppLocker policies are currently running in your production environment, export the policies from the corresponding GPOs and save them to the reference device. For the procedure to do this, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md). If no AppLocker policies have been deployed, create the rules and develop the policies by using the following procedures:
+If AppLocker policies are currently running in your production environment, export the policies from the corresponding GPOs and save them to the reference device. For information on how to export and save the policies, see [Export an AppLocker policy from a GPO](export-an-applocker-policy-from-a-gpo.md). If no AppLocker policies have been deployed, create the rules and develop the policies by using the following procedures:
- [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md)
- [Create a rule that uses a file hash condition](create-a-rule-that-uses-a-file-hash-condition.md)
@@ -68,7 +68,7 @@ If AppLocker policies are currently running in your production environment, expo
## Step 4: Test and update AppLocker policy on the reference device
-You should test each set of rules to ensure that they perform as intended. The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference device. Perform the steps on each reference device that you used to define the AppLocker policy. Ensure that the reference device is joined to the domain and that it is receiving the AppLocker policy from the appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to simultaneously test all of your test GPOs. Use the following procedures to complete this step:
+You should test each set of rules to ensure that they perform as intended. The **Test-AppLockerPolicy** Windows PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on your reference device. Perform the steps on each reference device that you used to define the AppLocker policy. Ensure that the reference device is joined to the domain and that it's receiving the AppLocker policy from the appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to simultaneously test all of your test GPOs. Use the following procedures to complete this step:
- [Test an AppLocker Policy with Test-AppLockerPolicy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791772(v=ws.10))
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
@@ -77,17 +77,17 @@ You should test each set of rules to ensure that they perform as intended. The *
## Step 5: Export and import the policy into production
-When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into individual computers that are not managed by Group Policy) and checked for its intended effectiveness. To do this, perform the following procedures:
+When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into individual computers that aren't managed by Group Policy) and checked for its intended effectiveness. To do these tasks, perform the following procedures:
- [Export an AppLocker policy to an XML file](export-an-applocker-policy-to-an-xml-file.md)
- [Import an AppLocker policy into a GPO](import-an-applocker-policy-into-a-gpo.md) or
- [Discover the Effect of an AppLocker Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee791823(v=ws.10))
-If the AppLocker policy enforcement setting is **Audit only** and you are satisfied that the policy is fulfilling your intent, you can change it to **Enforce rules**. For info about how to change the enforcement setting, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
+If the AppLocker policy enforcement setting is **Audit only** and you're satisfied that the policy is fulfilling your intent, you can change it to **Enforce rules**. For info about how to change the enforcement setting, see [Configure an AppLocker policy for enforce rules](configure-an-applocker-policy-for-enforce-rules.md).
## Step 6: Monitor the effect of the policy in production
-If additional refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
+If more refinements or updates are necessary after a policy is deployed, use the appropriate following procedures to monitor and update the policy:
- [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md)
- [Edit an AppLocker policy](edit-an-applocker-policy.md)
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/use-applocker-and-software-restriction-policies-in-the-same-domain.md b/windows/security/threat-protection/windows-defender-application-control/applocker/use-applocker-and-software-restriction-policies-in-the-same-domain.md
index 40d68279fe..37a691a28f 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/use-applocker-and-software-restriction-policies-in-the-same-domain.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/use-applocker-and-software-restriction-policies-in-the-same-domain.md
@@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and procedures to help you ma
## Using AppLocker and Software Restriction Policies in the same domain
AppLocker is supported on systems running Windows 7 and above. Software Restriction Policies (SRP) is supported on systems running Windows Vista or earlier. You can continue to use SRP for application control on your pre-Windows 7 computers, but use AppLocker for computers running
-Windows Server 2008 R2, Windows 7 and later. It is recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to computers running Windows Server 2008 R2,
+Windows Server 2008 R2, Windows 7 and later. It's recommended that you author AppLocker and SRP rules in separate GPOs and target the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies are applied to computers running Windows Server 2008 R2,
Windows 7 and later, the SRP policies are ignored.
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
@@ -45,15 +45,15 @@ The following table compares the features and functions of Software Restriction
|Policy creation|SRP policies are maintained through Group Policy and only the administrator of the GPO can update the SRP policy. The administrator on the local computer can modify the SRP policies defined in the local GPO.|AppLocker policies are maintained through Group Policy and only the administrator of the GPO can update the policy. The administrator on the local computer can modify the AppLocker policies defined in the local GPO.
AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies must be updated by using the Local Security Policy snap-in (if the policies are created locally) or the Group Policy Management Console (GPMC).|AppLocker policies can be updated by using the Local Security Policy snap-in (if the policies are created locally), or the GPMC, or the Windows PowerShell AppLocker cmdlets.|
|Policy application|SRP policies are distributed through Group Policy.|AppLocker policies are distributed through Group Policy.|
-|Enforcement mode|SRP works in the “deny list mode” where administrators can create rules for files that they do not want to allow in this Enterprise whereas the rest of the file is allowed to run by default.
SRP can also be configured in the “allowlist mode” so that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|AppLocker by default works in the “allowlist mode” where only those files are allowed to run for which there is a matching allow rule.|
-|File types that can be controlled|SRP can control the following file types:ExecutablesDllsScriptsWindows Installers
SRP cannot control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:ExecutablesDllsScriptsWindows InstallersPackaged apps and installers
AppLocker maintains a separate rule collection for each of the five file types.|
+|Enforcement mode|SRP works in the “blocklist mode” where administrators can create rules for files that they don't want to allow in this Enterprise whereas the rest of the file is allowed to run by default.
SRP can also be configured in the “allowlist mode” so that by default all files are blocked and administrators need to create allow rules for files that they want to allow.|AppLocker by default works in the “allowlist mode” where only those files are allowed to run for which there's a matching allow rule.|
+|File types that can be controlled|SRP can control the following file types:ExecutablesDllsScriptsWindows Installers
SRP can't control each file type separately. All SRP rules are in a single rule collection.|AppLocker can control the following file types:ExecutablesDllsScriptsWindows InstallersPackaged apps and installers
AppLocker maintains a separate rule collection for each of the five file types.|
|Designated file types|SRP supports an extensible list of file types that are considered executable. Administrators can add extensions for files that should be considered executable.|AppLocker currently supports the following file extensions:Executables (.exe, .com)Dlls (.ocx, .dll)Scripts (.vbs, .js, .ps1, .cmd, .bat)Windows Installers (.msi, .mst, .msp)Packaged app installers (.appx)|
|Rule types|SRP supports four types of rules:HashPathSignatureInternet zone|AppLocker supports three types of rules:File hashPathPublisher|
-|Editing the hash value|In Windows XP, you could use SRP to provide custom hash values.
Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, not provide the hash value.|AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest.|
-|Support for different security levels|With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.
SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker does not support security levels.|
+|Editing the hash value|In Windows XP, you could use SRP to provide custom hash values.
Beginning with Windows 7 and Windows Server 2008 R2, you can only select the file to hash, and not provide the hash value.|AppLocker computes the hash value itself. Internally, it uses the SHA2 Authenticode hash for Portable Executables (exe and dll) and Windows Installers and an SHA2 flat file hash for the rest.|
+|Support for different security levels|With SRP, you can specify the permissions with which an app can run. So, you can configure a rule such that Notepad always runs with restricted permissions and never with administrative privileges.
SRP on Windows Vista and earlier supported multiple security levels. On Windows 7, that list was restricted to just two levels: Disallowed and Unrestricted (Basic User translates to Disallowed).|AppLocker doesn't support security levels.|
|Manage Packaged apps and Packaged app installers.|Not supported|.appx is a valid file type which AppLocker can manage.|
|Targeting a rule to a user or a group of users|SRP rules apply to all users on a particular computer.|AppLocker rules can be targeted to a specific user or a group of users.|
-|Support for rule exceptions|SRP does not support rule exceptions.|AppLocker rules can have exceptions, which allow you to create rules such as “Allow everything from Windows except for regedit.exe”.|
-|Support for audit mode|SRP does not support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you are satisfied with the results, you can start enforcing the policy.|
-|Support for exporting and importing policies|SRP does not support policy import/export.|AppLocker supports the importing and exporting of policies. This allows you to create AppLocker policy on a sample device, test it out and then export that policy and import it back into the desired GPO.|
+|Support for rule exceptions|SRP doesn't support rule exceptions.|AppLocker rules can have exceptions, which allow you to create rules such as “Allow everything from Windows except for regedit.exe”.|
+|Support for audit mode|SRP doesn't support audit mode. The only way to test SRP policies is to set up a test environment and run a few experiments.|AppLocker supports audit mode, which allows you to test the effect of their policy in the real production environment without impacting the user experience. Once you're satisfied with the results, you can start enforcing the policy.|
+|Support for exporting and importing policies|SRP doesn't support policy import/export.|AppLocker supports the importing and exporting of policies. This support by AppLocker allows you to create AppLocker policy on a sample device, test it out and then export that policy and import it back into the desired GPO.|
|Rule enforcement|Internally, SRP rules enforcement happens in the user-mode, which is less secure.|Internally, AppLocker rules for .exe and .dll files are enforced in the kernel-mode, which is more secure than enforcing them in the user-mode.|
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md b/windows/security/threat-protection/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md
index 636ea5f18b..2751109b02 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md
@@ -43,7 +43,7 @@ Local Security policy snap-in, you must be a member of the local **Administrator
The [Get-AppLockerFileInformation](/powershell/module/applocker/get-applockerfileinformation) cmdlet retrieves the AppLocker file information from a list of files or from an event log. File information that is retrieved can include publisher information, file hash information, and file path information.
-File information from an event log may not contain all of these fields. Files that are not signed do not have any publisher information.
+File information from an event log may not contain all of these fields. Files that aren't signed don't have any publisher information.
### Set AppLocker policy
@@ -62,6 +62,6 @@ list of file information.
The [Test-AppLockerPolicy](/powershell/module/applocker/test-applockerpolicy) cmdlet uses the specified AppLocker policy to test whether a specified list of files are allowed to run or not on the local device for a specific user.
-## Additional resources
+## Other resources
- For steps to perform other AppLocker policy tasks, see [Administer AppLocker](administer-applocker.md).
\ No newline at end of file
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
index 0274a768dd..c034755acb 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/using-event-viewer-with-applocker.md
@@ -39,7 +39,7 @@ The AppLocker log contains information about applications that are affected by A
- The rule name
- The security identifier (SID) for the user or group identified in the rule
-Review the entries in the Event Viewer to determine if any applications are not included in the rules that you automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as the root of the active drive (for example: %SystemDrive%).
+Review the entries in the Event Viewer to determine if any applications aren't included in the rules that you automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such as the root of the active drive (for example: %SystemDrive%).
For info about what to look for in the AppLocker event logs, see [Monitor app usage with AppLocker](monitor-application-usage-with-applocker.md).
@@ -52,14 +52,14 @@ The following table contains information about the events that you can use to de
| Event ID | Level | Event message | Description |
| - | - | - | - |
-| 8000 | Error| Application Identity Policy conversion failed. Status *<%1> *| Indicates that the policy was not applied correctly to the computer. The status message is provided for troubleshooting purposes.|
+| 8000 | Error| Application Identity Policy conversion failed. Status *<%1> *| Indicates that the policy wasn't applied correctly to the computer. The status message is provided for troubleshooting purposes.|
| 8001 | Information| The AppLocker policy was applied successfully to this computer.| Indicates that the AppLocker policy was successfully applied to the computer.|
| 8002 | Information| *<File name> * was allowed to run.| Specifies that the .exe or .dll file is allowed by an AppLocker rule.|
-| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
-| 8004 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file cannot run.|
+| 8003 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the .exe or .dll file would be blocked if the **Enforce rules** enforcement mode were enabled. |
+| 8004 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The .exe or .dll file can't run.|
| 8005| Information| *<File name> * was allowed to run.| Specifies that the script or .msi file is allowed by an AppLocker rule.|
-| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy were enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
-| 8007 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file cannot run.|
+| 8006 | Warning| *<File name> * was allowed to run but would have been prevented from running if the AppLocker policy was enforced.| Applied only when the **Audit only** enforcement mode is enabled. Specifies that the script or .msi file would be blocked if the **Enforce rules** enforcement mode were enabled. |
+| 8007 | Error| *<File name> * was not allowed to run.| Access to *<file name>* is restricted by the administrator. Applied only when the **Enforce rules** enforcement mode is set either directly or indirectly through Group Policy inheritance. The script or .msi file can't run.|
| 8008| Error| AppLocker disabled on the SKU.| Added in Windows Server 2012 and Windows 8.|
| 8020| Information| Packaged app allowed.| Added in Windows Server 2012 and Windows 8.|
| 8021| Information| Packaged app audited.| Added in Windows Server 2012 and Windows 8.|
@@ -68,12 +68,12 @@ The following table contains information about the events that you can use to de
| 8024 | Information| Packaged app installation audited.| Added in Windows Server 2012 and Windows 8.|
| 8025 | Warning| Packaged app installation disabled.| Added in Windows Server 2012 and Windows 8.|
| 8027 | Warning| No Packaged app rule configured.| Added in Windows Server 2012 and Windows 8.|
-| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy were enforced.| Added in Windows Server 2016 and Windows 10.|
+| 8028 | Warning | * was allowed to run but would have been prevented if the Config CI policy was enforced.| Added in Windows Server 2016 and Windows 10.|
| 8029 | Error | * was prevented from running due to Config CI policy.| Added in Windows Server 2016 and Windows 10.|
| 8030 | Information | ManagedInstaller check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8031 | Information | SmartlockerFilter detected file * being written by process * | Added in Windows Server 2016 and Windows 10.|
-| 8032 | Error | ManagedInstaller check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
-| 8033 | Warning | ManagedInstaller check FAILED during Appid verification of * . Allowed to run due to Audit Applocker Policy. | Added in Windows Server 2016 and Windows 10.|
+| 8032 | Esrror | ManagedInstaller check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
+| 8033 | Warning | ManagedInstaller check FAILED during Appid verification of * . Allowed to run due to Audit AppLocker Policy. | Added in Windows Server 2016 and Windows 10.|
| 8034 | Information | ManagedInstaller Script check FAILED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8035 | Error | ManagedInstaller Script check SUCCEEDED during Appid verification of * | Added in Windows Server 2016 and Windows 10.|
| 8036 | Error | * was prevented from running due to Config CI policy | Added in Windows Server 2016 and Windows 10.|
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/using-software-restriction-policies-and-applocker-policies.md b/windows/security/threat-protection/windows-defender-application-control/applocker/using-software-restriction-policies-and-applocker-policies.md
index 47f5faeacd..96c1644d3a 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/using-software-restriction-policies-and-applocker-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/using-software-restriction-policies-and-applocker-policies.md
@@ -37,7 +37,7 @@ You might want to deploy application control policies in Windows operating syste
## Use SRP and AppLocker in the same domain
-SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take precedence over policies generated by SRP on computers that are running an operating system that supports AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated by SRP, see [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md).
+SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP and AppLocker exist in the same domain, and they're applied through Group Policy, AppLocker policies take precedence over policies generated by SRP on computers that are running an operating system that supports AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated by SRP, see [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md).
>**Important:** As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker policies. To reduce troubleshooting issues, do not combine them in the same GPO.
@@ -45,15 +45,15 @@ The following scenario provides an example of how each type of policy would affe
| Operating system | Tellers GPO with AppLocker policy | Tellers GPO with SRP | Tellers GPO with AppLocker policy and SRP |
| - | - | - | - |
-| Windows 10, Windows 8.1, Windows 8,and Windows 7 | AppLocker policies in the GPO are applied, and they supersede any local AppLocker policies.| Local AppLocker policies supersede policies generated by SRP that are applied through the GPO. | AppLocker policies in the GPO are applied, and they supersede the policies generated by SRP in the GPO and local AppLocker policies or policies generated by SRP.|
-| Windows Vista| AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP.AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.|
-| Windows XP| AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies are not applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.|
+| Windows 10, Windows 8.1, Windows 8, and Windows 7 | AppLocker policies in the GPO are applied, and they supersede any local AppLocker policies.| Local AppLocker policies supersede policies generated by SRP that are applied through the GPO. | AppLocker policies in the GPO are applied, and they supersede the policies generated by SRP in the GPO and local AppLocker policies or policies generated by SRP.|
+| Windows Vista| AppLocker policies aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP.AppLocker policies aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.|
+| Windows XP| AppLocker policies aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies aren't applied.| Policies generated by SRP in the GPO are applied, and they supersede local policies generated by SRP. AppLocker policies not applied.|
>**Note:** For info about supported versions and editions of the Windows operating system, see [Requirements to use AppLocker](requirements-to-use-applocker.md).
## Test and validate SRPs and AppLocker policies that are deployed in the same environment
-Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO. This makes testing the result of the policy straightforward, which is critical to successfully controlling application usage in the organization. Configuring a testing and policy distribution system can help you understand the result of a policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using different tools.
+Because SRPs and AppLocker policies function differently, they shouldn't be implemented in the same GPO. This rule, when implemented, makes testing the result of the policy straightforward, which is critical to successfully controlling application usage in the organization. Configuring a testing and policy distribution system can help you understand the result of a policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately and by using different tools.
### Step 1: Test the effect of SRPs
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker.md
index 1196a83dee..dc46fa241d 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker.md
@@ -76,10 +76,10 @@ The following table compares the application control functions of Software Restr
|User support|SRP allows users to install applications as an administrator.|AppLocker policies are maintained through Group Policy, and only the administrator of the device can update an AppLocker policy.AppLocker permits customization of error messages to direct users to a Web page for help.|
|Policy maintenance|SRP policies are updated by using the Local Security Policy snap-in or the Group Policy Management Console (GPMC).|AppLocker policies are updated by using the Local Security Policy snap-in or the GPMC.
AppLocker supports a small set of PowerShell cmdlets to aid in administration and maintenance.|
|Policy management infrastructure|To manage SRP policies, SRP uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.|To manage AppLocker policies, AppLocker uses Group Policy within a domain and the Local Security Policy snap-in for a local computer.|
-|Block malicious scripts|Rules for blocking malicious scripts prevents all scripts associated with the Windows Script Host from running, except those that are digitally signed by your organization.|AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run.|
+|Block malicious scripts|Rules for blocking malicious scripts prevent all scripts associated with the Windows Script Host from running, except those scripts that are digitally signed by your organization.|AppLocker rules can control the following file formats: .ps1, .bat, .cmd, .vbs, and .js. In addition, you can set exceptions to allow specific files to run.|
|Manage software installation|SRP can prevent all Windows Installer packages from installing. It allows .msi files that are digitally signed by your organization to be installed.|The Windows Installer rule collection is a set of rules created for Windows Installer file types (.mst, .msi and .msp) to allow you to control the installation of files on client computers and servers.|
|Manage all software on the computer|All software is managed in one rule set. By default, the policy for managing all software on a device disallows all software on the user's device, except software that is installed in the Windows folder, Program Files folder, or subfolders.|Unlike SRP, each AppLocker rule collection functions as an allowed list of files. Only the files that are listed within the rule collection will be allowed to run. This configuration makes it easier for administrators to determine what will occur when an AppLocker rule is applied.|
-|Different policies for different users|Rules are applied uniformly to all users on a particular device.|On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. Using AppLocker, an administrator can specify the user to whom a specific rule should apply.|
+|Different policies for different users|Rules are applied uniformly to all users on a particular device.|On a device that is shared by multiple users, an administrator can specify the groups of users who can access the installed software. An administrator uses AppLocker to specify the user to whom a specific rule should apply.|
## Related topics
diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/working-with-applocker-rules.md b/windows/security/threat-protection/windows-defender-application-control/applocker/working-with-applocker-rules.md
index 4379162473..4ad45cf9e0 100644
--- a/windows/security/threat-protection/windows-defender-application-control/applocker/working-with-applocker-rules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/applocker/working-with-applocker-rules.md
@@ -37,7 +37,7 @@ This topic for IT professionals describes AppLocker rule types and how to work w
| [Create a rule that uses a path condition](create-a-rule-that-uses-a-path-condition.md) | This topic for IT professionals shows how to create an AppLocker rule with a path condition.|
| [Create a rule that uses a publisher condition](create-a-rule-that-uses-a-publisher-condition.md) | This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.|
| [Create AppLocker default rules](create-applocker-default-rules.md) | This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow Windows system files to run.|
-| [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md) | This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an AppLocker rule.|
+| [Add exceptions for an AppLocker rule](configure-exceptions-for-an-applocker-rule.md) | This topic for IT professionals describes the steps to specify which apps can or can't run as exceptions to an AppLocker rule.|
| [Create a rule for packaged apps](create-a-rule-for-packaged-apps.md) | This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.|
| [Delete an AppLocker rule](delete-an-applocker-rule.md) | This topic for IT professionals describes the steps to delete an AppLocker rule.|
| [Edit AppLocker rules](edit-applocker-rules.md) | This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in AppLocker.|
@@ -49,11 +49,11 @@ The three AppLocker enforcement modes are described in the following table. The
| Enforcement mode | Description |
| - | - |
-| **Not configured** | This is the default setting which means that the rules defined here will be enforced unless a linked GPO with a higher precedence has a different value for this setting.|
+| **Not configured** | This is the default setting, which means that the rules defined here will be enforced unless a linked GPO with a higher precedence has a different value for this setting.|
| **Enforce rules** | Rules are enforced.|
-| **Audit only** | Rules are audited but not enforced. When a user runs an app that is affected by an AppLocker rule, the app is allowed to run and the info about the app is added to the AppLocker event log. The Audit-only enforcement mode helps you determine which apps will be affected by the policy before the policy is enforced. When the AppLocker policy for a rule collection is set to **Audit only**, rules for that rule collection are not enforced|
+| **Audit only** | Rules are audited but not enforced. When a user runs an app that is affected by an AppLocker rule, the app is allowed to run and the info about the app is added to the AppLocker event log. The Audit-only enforcement mode helps you determine which apps will be affected by the policy before the policy is enforced. When the AppLocker policy for a rule collection is set to **Audit only**, rules for that rule collection aren't enforced|
-When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the enforcement mode setting of the winning GPO is applied.
+When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged, and the enforcement mode setting of the winning GPO is applied.
## Rule collections
The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer files, packaged apps and packaged app installers, and DLL files. These collections give you an easy way to differentiate the rules for different types of apps. The following table lists the file formats that are included in each rule collection.
@@ -70,9 +70,9 @@ The AppLocker console is organized into rule collections, which are executable f
When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may experience a reduction in performance if DLL rules are used.
-The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see [DLL rule collections](#bkmk-dllrulecollections).
+The DLL rule collection isn't enabled by default. To learn how to enable the DLL rule collection, see [DLL rule collections](#bkmk-dllrulecollections).
-EXE rules apply to portable executable (PE) files. AppLocker checks whether a file is a valid PE file, rather than just applying rules based on file extension, which attackers can easily change. Regardless of the file extension, the AppLocker EXE rule collection will work on a file as long as it is a valid PE file.
+EXE rules apply to portable executable (PE) files. AppLocker checks whether a file is a valid PE file, rather than just applying rules based on file extension, which attackers can easily change. Regardless of the file extension, the AppLocker EXE rule collection will work on a file as long as it's a valid PE file.
## Rule conditions
@@ -84,13 +84,13 @@ Rule conditions are criteria that help AppLocker identify the apps to which the
### Publisher
-This condition identifies an app based on its digital signature and extended attributes when available. The digital signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of the product that the file is a part of, the original name of the file as supplied by the publisher, and the version number of the file. In case of packaged apps and packaged app installers, these extended attributes contain the name and the version of the app package.
+This condition identifies an app based on its digital signature and extended attributes when available. The digital signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows installers, packaged apps and packaged app installers also have extended attributes, which are obtained from the binary resource. If there's executable files, dlls and Windows installers, these attributes contain the name of the product that the file is a part of, the original name of the file as supplied by the publisher, and the version number of the file. If there are packaged apps and packaged app installers, these extended attributes contain the name and the version of the app package.
> **Note:** Rules created in the packaged apps and packaged app installers rule collection can only have publisher conditions since Windows does not support unsigned packaged apps and packaged app installers.
>
> **Note:** Use a publisher rule condition when possible because they can survive app updates as well as a change in the location of files.
-When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving the slider up or by using a wildcard character (\*) in the product, file name, or version number fields.
+When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher, product, file name, and version number. You can make the rule more generic by moving up the slider or by using a wildcard character (\*) in the product, file name, or version number fields.
>**Note:** To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard, you must select the **Use custom values** check box. When this check box is selected, you cannot use the slider.
@@ -108,8 +108,8 @@ The following table describes how a publisher condition is applied.
| **All signed files** | All files that are signed by any publisher.|
| **Publisher only**| All files that are signed by the named publisher.|
| **Publisher and product name**| All files for the specified product that are signed by the named publisher.|
-| **Publisher and product name, and file name**| Any version of the named file or package for the named product that are signed by the publisher.|
-| **Publisher, product name, file name, and file version**| **Exactly**
The specified version of the named file or package for the named product that are signed by the publisher.|
+| **Publisher and product name, and file name**| Any version of the named file or package for the named product that is signed by the publisher.|
+| **Publisher, product name, file name, and file version**| **Exactly**
The specified version of the named file or package for the named product that is signed by the publisher.|
| **Publisher, product name, file name, and file version**| **And above**
The specified version of the named file or package and any new releases for the product that are signed by the publisher.|
| **Publisher, product name, file name, and file version**| **And below**
The specified version of the named file or package and any earlier versions for the product that are signed by the publisher.|
| **Custom**| You can edit the **Publisher**, **Product name**, **File name**, **Version** **Package name**, and **Package version** fields to create a custom rule.|
@@ -184,13 +184,13 @@ A rule can be configured to use allow or deny actions:
## Rule exceptions
-You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry Editor" allows everyone in the organization to run the Windows operating system, but it does not allow anyone to run Registry Editor.
+You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users, all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry Editor" allows everyone in the organization to run the Windows operating system, but it doesn't allow anyone to run Registry Editor.
-The effect of this rule would prevent users such as Help Desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk user group: "Allow Help Desk to run Registry Editor." If you create a deny rule that does not allow any users to run Registry Editor, the deny rule will override the second rule that allows the Help Desk user group to run Registry Editor.
+The effect of this rule would prevent users such as Help Desk personnel from running a program that is necessary for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk user group: "Allow Help Desk to run Registry Editor." If you create a deny rule that doesn't allow any users to run Registry Editor, the deny rule will override the second rule that allows the Help Desk user group to run Registry Editor.
## DLL rule collection
-Because the DLL rule collection is not enabled by default, you must perform the following procedure before you can create and enforce DLL rules.
+Because the DLL rule collection isn't enabled by default, you must perform the following procedure before you can create and enforce DLL rules.
Membership in the local **Administrators** group, or equivalent, is the minimum required to complete this procedure.
@@ -208,21 +208,21 @@ Membership in the local **Administrators** group, or equivalent, is the minimum
You can create rules by using two AppLocker wizards:
1. The Create Rules Wizard enables you to create one rule at a time.
-2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select a folder and let the wizard create rules for the relevant files within that folder or in case of packaged apps let the wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to which to apply the rules. This wizard automatically generates allow rules only.
+2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either select a folder and let the wizard create rules for the relevant files within that folder or if there are packaged apps let the wizard create rules for all packaged apps installed on the computer. You can also specify the user or group to which to apply the rules. This wizard automatically generates allow rules only.
-## Additional considerations
+## Other considerations
-- By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed. Administrators should maintain an up-to-date list of allowed applications.
-- There are two types of AppLocker conditions that do not persist following an update of an app:
+- By default, AppLocker rules don't allow users to open or run any files that aren't allowed. Administrators should maintain an up-to-date list of allowed applications.
+- There are two types of AppLocker conditions that don't persist following an update of an app:
- **A file hash condition** File hash rule conditions can be used with any app because a cryptographic hash value of the app is generated at the time the rule is created. However, the hash value is specific to that exact version of the app. If there are several versions of the application in use within the organization, you need to create file hash conditions for each version in use and for any new versions that are released.
- - **A publisher condition with a specific product version set** If you create a publisher rule condition that uses the **Exactly** version option, the rule cannot persist if a new version of the app is installed. A new publisher condition must be created, or the version must be edited in the rule to be made less specific.
+ - **A publisher condition with a specific product version set** If you create a publisher rule condition that uses the **Exactly** version option, the rule can't persist if a new version of the app is installed. A new publisher condition must be created, or the version must be edited in the rule to be made less specific.
-- If an app is not digitally signed, you cannot use a publisher rule condition for that app.
-- AppLocker rules cannot be used to manage computers running a Windows operating system earlier than Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs.
+- If an app isn't digitally signed, you can't use a publisher rule condition for that app.
+- AppLocker rules can't be used to manage computers running a Windows operating system earlier than Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules and AppLocker rules in different GPOs.
- The packaged apps and packaged apps installer rule collection is available on devices running at least Windows Server 2012 and Windows 8.
-- When the rules for the executable rule collection are enforced and the packaged apps and packaged app installers rule collection does not contain any rules, no packaged apps and packaged app installers are allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged apps and packaged app installers rule collection.
-- When an AppLocker rule collection is set to **Audit only**, the rules are not enforced. When a user runs an application that is included in the rule, the app is opened and runs normally, and information about that app is added to the AppLocker event log.
+- When the rules for the executable rule collection are enforced and the packaged apps and packaged app installers rule collection doesn't contain any rules, no packaged apps and packaged app installers are allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules for the packaged apps and packaged app installers rule collection.
+- When an AppLocker rule collection is set to **Audit only**, the rules aren't enforced. When a user runs an application that is included in the rule, the app is opened and runs normally, and information about that app is added to the AppLocker event log.
- A custom configured URL can be included in the message that is displayed when an app is blocked.
-- Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that they cannot run apps that are not allowed.
+- Expect an increase in the number of Help Desk calls initially because of blocked apps until users understand that they can't run apps that aren't allowed.
diff --git a/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md b/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
index 839aa3a791..ec6a1a8178 100644
--- a/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
+++ b/windows/security/threat-protection/windows-defender-application-control/configure-authorized-apps-deployed-with-a-managed-installer.md
@@ -33,7 +33,7 @@ Windows 10 (version 1703) introduced a new option for Windows Defender Applicati
## How does a managed installer work?
-Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they are tagged as originating from a managed installer.
+Managed installer uses a special rule collection in **AppLocker** to designate binaries that are trusted by your organization as an authorized source for application installation. When one of these trusted binaries runs, Windows monitors the binary's process (and processes it launches) and watches for files being written to disk. As files are written, they're tagged as originating from a managed installer.
You can then configure WDAC to trust files that are installed by a managed installer by adding the "Enabled:Managed Installer" option to your WDAC policy. When that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules for the binary, WDAC will allow it to run based purely on its managed installer origin.
@@ -45,7 +45,7 @@ Users with administrator privileges, or malware running as an administrator user
If a managed installer process runs in the context of a user with standard privileges, then it's possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
-Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
+Some application installers may automatically run the application at the end of the installation process. If this execution of the application happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files that are created during the first run of the application. This extension could result in unintentional authorization of an executable. To avoid that, ensure that the method of application deployment that is used as a managed installer limits running applications as part of installation.
## Known limitations with managed installer
@@ -66,11 +66,11 @@ To turn on managed installer tracking, you must:
### Create and deploy an AppLocker policy that defines your managed installer rules and enables services enforcement for executables and DLLs
-Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
+Currently, both the AppLocker policy creation UI in GPO Editor and the PowerShell cmdlets allow for directly specifying rules for the Managed Installer rule collection. However, you can use an XML or text editor to convert an EXE rule collection policy into a ManagedInstaller rule collection.
> [!NOTE]
> Only EXE file types can be designated as managed installers.
-1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you are designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.
+1. Use [New-AppLockerPolicy](/powershell/module/applocker/new-applockerpolicy?view=win10-ps&preserve-view=true) to make an EXE rule for the file you're designating as a managed installer. This example creates a rule for Microsoft's Intune Management Extension using the Publisher rule type, but any AppLocker rule type can be used. You may need to reformat the output for readability.
```powershell
Get-ChildItem ${env:ProgramFiles(x86)}'\Microsoft Intune Management Extension\Microsoft.Management.Services.IntuneWindowsAgent.exe' | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType Publisher -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
@@ -125,7 +125,7 @@ Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerS
```
-4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Configuration Manager and Microsoft Endpoint Manager Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This ensures the policy will merge successfully on devices which may already have an AppLocker policy in place.
+4. Verify your AppLocker policy. The following example shows a complete AppLocker policy that sets Configuration Manager and Microsoft Endpoint Manager Intune as managed installers. Only those AppLocker rule collections that have actual rules defined are included in the final XML. This condition-based inclusion ensures the policy will merge successfully on devices that may already have an AppLocker policy in place.
```xml
@@ -205,7 +205,7 @@ Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerS
## Enable the managed installer option in WDAC policy
In order to enable trust for the binaries laid down by managed installers, the "Enabled: Managed Installer" option must be specified in your WDAC policy.
-This can be done by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
+This setting can be defined by using the [Set-RuleOption cmdlet](/powershell/module/configci/set-ruleoption) with Option 13.
Below are steps to create a WDAC policy that allows Windows to boot and enables the managed installer option.
@@ -232,7 +232,7 @@ Below are steps to create a WDAC policy that allows Windows to boot and enables
## Remove Managed Installer feature
-To remove the Managed Installer feature from the device, you will need to remove the Managed Installer AppLocker policy from the device by following the instructions at [Delete an AppLocker rule: Clear AppLocker policies on a single system or remote systems](applocker/delete-an-applocker-rule.md#to-clear-applocker-policies-on-a-single-system-or-remote-systems).
+To remove the Managed Installer feature from the device, you'll need to remove the Managed Installer AppLocker policy from the device by following the instructions at [Delete an AppLocker rule: Clear AppLocker policies on a single system or remote systems](applocker/delete-an-applocker-rule.md#to-clear-applocker-policies-on-a-single-system-or-remote-systems).
## Related articles
From ce56a2f15015e07bf35cd05ce3299340d16e759a Mon Sep 17 00:00:00 2001
From: Siddarth Mandalika
Date: Mon, 4 Jul 2022 17:49:31 +0530
Subject: [PATCH 021/299] Acrolinx Enhancement effort
---
.../configure-wdac-managed-installer.md | 2 +-
...or-windows-defender-application-control.md | 10 ++---
.../create-initial-default-policy.md | 8 ++--
...e-wdac-policy-for-fully-managed-devices.md | 18 ++++-----
...wdac-policy-for-lightly-managed-devices.md | 18 ++++-----
...rt-windows-defender-application-control.md | 38 +++++++++----------
...s-defender-application-control-policies.md | 12 +++---
...plication-control-policies-using-intune.md | 12 +++---
.../deploy-wdac-policies-with-memcm.md | 2 +-
...s-defender-application-control-policies.md | 8 ++--
.../event-id-explanations.md | 2 +-
...th-windows-defender-application-control.md | 16 ++++----
.../microsoft-recommended-block-rules.md | 8 ++--
...icrosoft-recommended-driver-block-rules.md | 4 +-
...defender-application-control-management.md | 18 ++++-----
.../select-types-of-rules-to-create.md | 18 ++++-----
.../types-of-devices.md | 14 +++----
...ication-control-policy-design-decisions.md | 14 +++----
...ontrol-for-classic-windows-applications.md | 20 +++++-----
...r-application-control-against-tampering.md | 12 +++---
...l-specific-plug-ins-add-ins-and-modules.md | 4 +-
...tion-control-with-dynamic-code-security.md | 6 +--
...control-with-intelligent-security-graph.md | 12 +++---
.../wdac-and-applocker-overview.md | 12 +++---
.../wdac-wizard-create-base-policy.md | 22 +++++------
25 files changed, 155 insertions(+), 155 deletions(-)
diff --git a/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md b/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md
index 92f944b419..70a4c7cad7 100644
--- a/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md
+++ b/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md
@@ -31,7 +31,7 @@ ms.technology: windows-sec
## Using fsutil to query SmartLocker EA
-Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
+Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This verification can be done by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This EA's presence can be used in conjunction with enabling the MI and ISG logging events.
**Example:**
diff --git a/windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md b/windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md
index 26a241db0e..f983d739b8 100644
--- a/windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md
+++ b/windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md
@@ -1,6 +1,6 @@
---
title: Create a code signing cert for Windows Defender Application Control (Windows)
-description: Learn how to set up a publicly-issued code signing certificate, so you can sign catalog files or WDAC policies internally.
+description: Learn how to set up a publicly issued code signing certificate, so you can sign catalog files or WDAC policies internally.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
@@ -29,11 +29,11 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md).
+As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this signature, you'll either need a publicly issued code signing certificate or an internal CA. If you've purchased a code-signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md).
If you have an internal CA, complete these steps to create a code signing certificate.
Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded.
-ECDSA is not supported.
+ECDSA isn't supported.
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
@@ -75,7 +75,7 @@ When this certificate template has been created, you must publish it to the CA p
Figure 3. Select the new certificate template to issue
- A list of available templates to issue appears, including the template you just created.
+ A list of available templates to issue appears, including the template you created.
2. Select the WDAC Catalog signing certificate, and then click **OK**.
@@ -100,7 +100,7 @@ Now that the template is available to be issued, you must request one from the c
>[!NOTE]
>If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
-This certificate must be installed in the user's personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
+This certificate must be installed in the user's personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file won't be required because it already exists in your personal store. If you're signing on another computer, you'll need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
1. Right-click the certificate, point to **All Tasks**, and then click **Export**.
diff --git a/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md b/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md
index 3686f2ecb5..2d31e8f0f7 100644
--- a/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md
@@ -37,7 +37,7 @@ The policy file is converted to binary format when it gets created so that Windo
## Overview of the process of creating Windows Defender Application Control policies
-A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Windows Defender Application Control policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional WDAC policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
+A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone more company assets. Windows Defender Application Control policies follow a similar methodology that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of more WDAC policies based on what should be allowed to be installed and run and for whom. For more information on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md).
Optionally, WDAC can align with your software catalog and any IT department–approved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged, or serviced, and managed.
@@ -48,12 +48,12 @@ If you plan to use an internal CA to sign catalog files or WDAC policies, see th
Each installed software application should be validated as trustworthy before you create a policy.
We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable.
-Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want to run scripts.
+Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you don't want to run scripts.
You can remove or disable such software on the reference computer.
To create a Windows Defender Application Control policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
-1. Initialize variables that you will use.
+1. Initialize variables that you'll use.
```powershell
$PolicyPath=$env:userprofile+"\Desktop\"
@@ -83,7 +83,7 @@ To create a Windows Defender Application Control policy, copy each of the follow
ConvertFrom-CIPolicy $WDACPolicy $WDACPolicyBin
```
-After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for additional security.
+After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for more security.
> [!NOTE]
> We recommend that you keep the original .xml file of the policy for use when you need to merge the WDAC policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge WDAC policies, see [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md).
diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md
index c0296ea8e6..7cd08be428 100644
--- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md
+++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md
@@ -30,16 +30,16 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
+This section outlines the process to create a Windows Defender Application Control (WDAC) policy for **fully managed devices** within an organization. The key difference between this scenario and [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md) is that all software deployed to a fully managed device is managed by IT and users of the device can't install arbitrary apps. Ideally, all apps are deployed using a software distribution solution, such as Microsoft Endpoint Manager. Additionally, users on fully managed devices should ideally run as standard user and only authorized IT pros have administrative access.
> [!NOTE]
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
-As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we will use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
+As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
**Alice Pena** is the IT team lead tasked with the rollout of WDAC.
-Alice previously created a policy for the organization's lightly managed devices. Some devices, however, are more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such as administrative staff and firstline workers are not granted administrator level access to their devices. Similarly, shared kiosks are configured only with a managed set of apps and all users of the device except IT run as standard user. On these devices, all apps are deployed and installed by IT.
+Alice previously created a policy for the organization's lightly managed devices. Some devices, however, are more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such as administrative staff and firstline workers aren't granted administrator level access to their devices. Similarly, shared kiosks are configured only with a managed set of apps and all users of the device except IT run as standard user. On these devices, all apps are deployed and installed by IT.
## Define the "circle-of-trust" for fully managed devices
@@ -51,26 +51,26 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
- Sometimes, IT staff install apps directly to these devices without using Configuration Manager;
- All users except IT are standard users on these devices.
-Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an additional managed installer for WDAC and allows her to remove the need for filepath rules.
+Alice's team develops a simple console application, called *LamnaITInstaller.exe*, which will become the authorized way for IT staff to install apps directly to devices. *LamnaITInstaller.exe* allows the IT pro to launch another process, such as an app installer. Alice will configure *LamnaITInstaller.exe* as an extra managed installer for WDAC and allows her to remove the need for filepath rules.
Based on the above, Alice defines the pseudo-rules for the policy:
1. **“Windows works”** rules that authorize:
- Windows
- - WHQL (3rd party kernel drivers)
+ - WHQL (third-party kernel drivers)
- Windows Store signed apps
2. **"MEMCM works”** rules that include signer and hash rules for Configuration Manager components to properly function.
3. **Allow Managed Installer** (Configuration Manager and *LamnaITInstaller.exe* configured as a managed installer)
-The critical differences between this set of pseudo-rules and those defined for Lamna's [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md#define-the-circle-of-trust-for-lightly-managed-devices) are:
+The critical differences between this set of pseudo-rules and those pseudo-rules defined for Lamna's [lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md#define-the-circle-of-trust-for-lightly-managed-devices) are:
- Removal of the Intelligent Security Graph (ISG) option; and
- Removal of filepath rules.
## Create a custom base policy using an example WDAC base policy
-Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully-managed devices. She decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
+Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully managed devices and decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
Alice follows these steps to complete this task:
@@ -113,7 +113,7 @@ Alice follows these steps to complete this task:
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
```
-6. If appropriate, add additional signer or file rules to further customize the policy for your organization.
+6. If appropriate, add more signer or file rules to further customize the policy for your organization.
7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the Windows Defender Application Control policy to a binary format:
@@ -134,7 +134,7 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
Alice has defined a policy for Lamna's fully managed devices that makes some trade-offs between security and manageability for apps. Some of the trade-offs include:
- **Users with administrative access**
- Although applying to fewer users, Lamna still allows some IT staff to log in to its fully managed devices as administrator. This allows these admin users (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
+ Although applying to fewer users, Lamna still allows some IT staff to sign in to its fully managed devices as administrator. This privilege allows these users (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
index d03bb18a75..9cb8de44f4 100644
--- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
+++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-lightly-managed-devices.md
@@ -35,11 +35,11 @@ This section outlines the process to create a Windows Defender Application Contr
> [!NOTE]
> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs.
-As in the [previous topic](types-of-devices.md), we will use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
+As in the [previous topic](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices.
-**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she will need to take an incremental approach to application control and use different policies for different workloads.
+**Alice Pena** is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she'll need to take an incremental approach to application control and use different policies for different workloads.
-For the majority of users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
+For most users and devices, Alice wants to create an initial policy that is as relaxed as possible in order to minimize user productivity impact, while still providing security value.
## Define the "circle-of-trust" for lightly managed devices
@@ -49,16 +49,16 @@ Alice identifies the following key factors to arrive at the "circle-of-trust" fo
- All clients are managed by Microsoft Endpoint Manager either with Configuration Manager or with Intune.
- Some, but not all, apps are deployed using Configuration Manager;
- Most users are local administrators on their devices;
-- Some teams may need additional rules to authorize specific apps that don't apply generally to all other users.
+- Some teams may need more rules to authorize specific apps that don't apply generally to all other users.
Based on the above, Alice defines the pseudo-rules for the policy:
1. **“Windows works”** rules that authorize:
- Windows
- - WHQL (3rd party kernel drivers)
+ - WHQL (third-party kernel drivers)
- Windows Store signed apps
-2. **"MEMCM works”** rules which include signer and hash rules for Configuration Manager components to properly function.
+2. **"MEMCM works”** rules that include signer and hash rules for Configuration Manager components to properly function.
3. **Allow Managed Installer** (Configuration Manager configured as a managed installer)
4. **Allow Intelligent Security Graph (ISG)** (reputation-based authorization)
5. **Admin-only path rules** for the following locations:
@@ -68,7 +68,7 @@ Based on the above, Alice defines the pseudo-rules for the policy:
## Create a custom base policy using an example WDAC base policy
-Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. She decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
+Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly managed devices. Alice decides to use Configuration Manager to create the initial base policy and then customize it to meet Lamna's needs.
Alice follows these steps to complete this task:
@@ -121,7 +121,7 @@ Alice follows these steps to complete this task:
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
```
-7. If appropriate, add additional signer or file rules to further customize the policy for your organization.
+7. If appropriate, add more signer or file rules to further customize the policy for your organization.
8. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format:
@@ -142,7 +142,7 @@ At this point, Alice now has an initial policy that is ready to deploy in audit
In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between security and user app flexibility. Some of the trade-offs include:
- **Users with administrative access**
- By far the most impactful security trade-off, this allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
+ By far the most impactful security trade-off, this trade-off allows the device user (or malware running with the user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure any app they wish to operate as a managed installer that would allow them to gain persistent app authorization for whatever apps or binaries they wish.
Possible mitigations:
- Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
diff --git a/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md b/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md
index 348fbacaf2..65565ec200 100644
--- a/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md
+++ b/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md
@@ -40,9 +40,9 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
> [!NOTE]
> When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention.
-1. Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
+1. Be sure that a Windows Defender Application Control policy is currently deployed in audit mode on the computer on which you'll run Package Inspector.
- Package Inspector does not always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode.
+ Package Inspector doesn't always detect temporary installation files that are added and then removed from the computer during the installation process. To ensure that these binaries are also included in your catalog file, deploy a WDAC policy in audit mode.
> [!NOTE]
> This process should **not** be performed on a system with an enforced Windows Defender Application Control policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run the application unless the policy already allows it.
@@ -58,7 +58,7 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future WDAC policy may allow the application to run but not to be installed.
-4. Install the application. Install it to the same drive that the application installer is located on (the drive you are scanning). Also, while Package Inspector is running, do not run any installations or updates that you don't want to capture in the catalog.
+4. Install the application. Install it to the same drive that the application installer is located on (the drive you're scanning). Also, while Package Inspector is running, don't run any installations or updates that you don't want to capture in the catalog.
> [!IMPORTANT]
> Every binary that is run while Package Inspector is running will be captured in the catalog. Ensure that only trusted applications are run during this time.
@@ -71,9 +71,9 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
This step is necessary to ensure that the scan has captured all binaries.
-8. As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it is updated, and then close and reopen the application.
+8. As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it's updated, and then close and reopen the application.
-9. When you have confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate.
+9. When you've confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate.
For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have been scanning, for example, C:.
@@ -98,22 +98,22 @@ Packages can fail for the following reasons:
- Package is too large for default USN Journal or Event Log sizes
- To diagnose whether USN journal size is the issue, after running through Package Inspector, click Start > install app > PackageInspector stop
- - Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this was the most recent USN when you ran PackageInspector start)
+ - Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this USN was the most recent one when you ran PackageInspector start)
- `fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt`
- ReadJournal command should throw an error if the older USNs don't exist anymore due to overflow
- For USN Journal, log size can be expanded using: `fsutil usn createjournal` command with a new size and alloc delta. `Fsutil usn queryjournal` will give the current size and allocation delta, so using a multiple of that may help
- To diagnose whether Eventlog size is the issue, look at the Microsoft/Windows/CodeIntegrity/Operational log under Applications and Services logs in Event Viewer and ensure that there are entries present from when you began Package Inspector (You can use write time as a justification; if you started the install 2 hours ago and there are only entries from 30 minutes prior, the log is definitely too small)
- To increase Eventlog size, in Event Viewer you can right click the operational log, click properties, and then set new values (some multiple of what it was previously)
- Package files that change hash each time the package is installed
- - Package Inspector is completely incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077 block events when the package is failing in enforcement. If each time you attempt to run the package you get a new block event with a different hash, the package will not work with Package Inspector
+ - Package Inspector is incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this hash-change by looking at the hash field in the 3077 block events when the package is failing in enforcement. If each time you attempt to run the package you get a new block event with a different hash, the package won't work with Package Inspector
- Files with an invalid signature blob or otherwise "unhashable" files
- This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec.
- - Windows Defender Application Control uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it)
- - Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
+ - Windows Defender Application Control uses Authenticode Hashes to validate files when they're running. If the file is unhashable via the authenticode SIP, there's no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it)
+ - Recent versions of InstallShield packages that use custom actions can hit this condition. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
## Catalog signing with SignTool.exe
-To sign a catalog file you generated by using PackageInspector.exe, you need the following:
+To sign a catalog file you generated by using PackageInspector.exe, you need:
- SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
@@ -148,15 +148,15 @@ To sign the existing catalog file, copy each of the following commands into an e
5. Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
- For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, to copy the appropriate catalog files to all desired computers, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as Microsoft Endpoint Configuration Manager. Doing this also simplifies the management of catalog versions.
+ For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, to copy the appropriate catalog files to all desired computers, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as Microsoft Endpoint Configuration Manager, which also simplifies the management of catalog versions.
## Add a catalog signing certificate to a Windows Defender Application Control policy
After the catalog file is signed, add the signing certificate to a WDAC policy, as described in the following steps.
-1. If you have not already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
+1. If you haven't already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
-2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
+2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a Windows Defender Application Control policy that you'll later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
`New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs`
@@ -212,9 +212,9 @@ To simplify the management of catalog files, you can use Group Policy preference
**C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**
- For the catalog file name, use the name of the catalog you are deploying.
+ For the catalog file name, use the name of the catalog you're deploying.
-10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Doing this ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
+10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Enabling this option ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
11. Click **OK** to complete file creation.
@@ -224,7 +224,7 @@ Before you begin testing the deployed catalog file, make sure that the catalog s
## Deploy catalog files with Microsoft Endpoint Configuration Manager
-As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
+As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files and provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
>[!NOTE]
>The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
@@ -263,7 +263,7 @@ As an alternative to Group Policy, you can use Configuration Manager to deploy c
7. Accept the defaults for the rest of the wizard, and then close the wizard.
-After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you just created to a test collection:
+After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you created to a test collection:
1. In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
@@ -335,9 +335,9 @@ When catalog files have been deployed to the computers within your environment,
8. Click **OK**.
-9. Now that you have created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
+9. Now that you've created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
-At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you will be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
+At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you'll be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
diff --git a/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md b/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md
index 37126d5855..eef8622acd 100644
--- a/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md
@@ -29,7 +29,7 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-Prior to Windows 10 1903, Windows Defender Application Control only supported a single active policy on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
+Prior to Windows 10 1903, Windows Defender Application Control only supported a single active policy on a system at any given time. This limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
1. Enforce and Audit Side-by-Side
- To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy
@@ -49,11 +49,11 @@ Prior to Windows 10 1903, Windows Defender Application Control only supported a
- Multiple base policies: intersection
- Only applications allowed by both policies run without generating block events
- Base + supplemental policy: union
- - Files that are allowed by either the base policy or the supplemental policy are not blocked
+ - Files that are allowed by either the base policy or the supplemental policy aren't blocked
## Creating WDAC policies in Multiple Policy Format
-In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format.
+In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below example describes the process of creating a new policy in the multiple policy format.
```powershell
New-CIPolicy -MultiplePolicyFormat -ScanPath "" -UserPEs -FilePath ".\policy.xml" -Level Publisher -Fallback Hash
@@ -87,7 +87,7 @@ Set-CIPolicyIdInfo [-FilePath] [-PolicyName ] [-SupplementsBase
### Merging policies
-When merging, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy with ID \, then regardless of what the GUIDs and types are for any subsequent policies, the merged policy will be a base policy with ID \.
+When you're merging policies, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy with ID \, then regardless of what the GUIDs and types are for any subsequent policies, the merged policy will be a base policy with ID \.
## Deploying multiple policies
@@ -107,9 +107,9 @@ To deploy policies locally using the new multiple policy format, follow these st
Multiple Windows Defender Application Control policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.
-However, when policies are un-enrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
+However, when policies are unenrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
-See [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) for more information on deploying multiple policies, optionally using Microsoft Endpoint Manager Intune's Custom OMA-URI capability.
+For more information on deploying multiple policies, optionally using Microsoft Endpoint Manager Intune's Custom OMA-URI capability, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp).
> [!NOTE]
> WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format Windows Defender Application Control policies.
diff --git a/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md b/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md
index 143fbdcc2e..5f1acbe65d 100644
--- a/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md
+++ b/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md
@@ -29,14 +29,14 @@ ms.technology: windows-sec
>[!NOTE]
>Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
+You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
## Use Intune's built-in policies
Intune's built-in Windows Defender Application Control support allows you to configure Windows client computers to only run:
- Windows components
-- 3rd party hardware and software kernel drivers
+- Third-party hardware and software kernel drivers
- Microsoft Store-signed apps
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
@@ -68,7 +68,7 @@ The steps to use Intune's custom OMA-URI functionality are:
4. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
- **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy
- **Data type**: Base64
- - **Certificate file**: upload your binary format policy file. You do not need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
+ - **Certificate file**: upload your binary format policy file. You don't need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
> [!div class="mx-imgBorder"]
> 
@@ -78,13 +78,13 @@ The steps to use Intune's custom OMA-URI functionality are:
### Remove WDAC policies on Windows 10 1903+
-Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
+Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable Windows Defender Application Control enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This deletion will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
### For pre-1903 systems
#### Deploying policies
-The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
+The steps to use Intune's Custom OMA-URI functionality to apply the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
@@ -100,4 +100,4 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocke
#### Removing policies
-Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.
+Policies deployed through Intune via the AppLocker CSP can't be deleted through the Intune console. In order to disable Windows Defender Application Control policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.
diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md
index b8f3362555..f4cd7e89bf 100644
--- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md
+++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md
@@ -39,7 +39,7 @@ Microsoft Endpoint Configuration Manager includes native support for WDAC, which
- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
- [Optional] Apps and executables already installed in admin-definable folder locations that Configuration Manager will allow through a one-time scan during policy creation on managed endpoints.
-Note that Configuration Manager does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable Windows Defender Application Control (WDAC) altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot.
+Configuration Manager doesn't remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable Windows Defender Application Control (WDAC) altogether (including audit mode), you can deploy a script to delete the policy file from disk and either trigger a reboot or wait for the next reboot.
For more information on using Configuration Manager's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager).
diff --git a/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies.md b/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies.md
index 7f04db97e1..0c7726f27d 100644
--- a/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies.md
+++ b/windows/security/threat-protection/windows-defender-application-control/disable-windows-defender-application-control-policies.md
@@ -33,7 +33,7 @@ This topic covers how to disable unsigned or signed WDAC policies.
## Disable unsigned Windows Defender Application Control policies
-There may come a time when an administrator wants to disable a Windows Defender Application Control policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
+There may come a time when an administrator wants to disable a Windows Defender Application Control policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
- <EFI System Partition>\\Microsoft\\Boot\\
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
@@ -43,7 +43,7 @@ There may come a time when an administrator wants to disable a Windows Defender
## Disable signed Windows Defender Application Control policies within Windows
-Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed Windows Defender Application Control policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
+Signed policies protect Windows from administrative manipulation and malware that has gained administrative-level access to the system. For this reason, signed Windows Defender Application Control policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
> [!NOTE]
> For reference, signed WDAC policies should be replaced and removed from the following locations:
@@ -68,7 +68,7 @@ Signed policies protect Windows from administrative manipulation as well as malw
5. Restart the client computer.
-If the signed Windows Defender Application Control policy has been deployed using by using Group Policy, you must complete the following steps:
+If the signed Windows Defender Application Control policy has been deployed by using Group Policy, you must complete the following steps:
1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
@@ -90,7 +90,7 @@ If the signed Windows Defender Application Control policy has been deployed usin
## Disable signed Windows Defender Application Control policies within the BIOS
-There may be a time when signed Windows Defender Application Control policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
+There may be a time when signed Windows Defender Application Control policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it's important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
- <EFI System Partition>\\Microsoft\\Boot\\
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
index e96c186076..4caa7844ea 100644
--- a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
+++ b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
@@ -91,7 +91,7 @@ reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x
## Event ID 3099 Options
-The Application Control policy rule-option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
+The Application Control policy rule option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. To derive and parse these values, follow the below workflow.
- Access Event Viewer.
- Access the Code integrity 3099 event.
diff --git a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
index 71bcec1a37..c309371277 100644
--- a/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
+++ b/windows/security/threat-protection/windows-defender-application-control/manage-packaged-apps-with-windows-defender-application-control.md
@@ -34,7 +34,7 @@ This topic for IT professionals describes concepts and lists procedures to help
## Understanding Packaged Apps and Packaged App Installers
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an app package share the same identity. With classic Windows apps, each file within the app could have a unique identity.
-With packaged apps, it is possible to control the entire app by using a single Windows Defender Application Control rule.
+With packaged apps, it's possible to control the entire app by using a single Windows Defender Application Control rule.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such as the software’s publisher name, product name, and product version. Therefore, Windows Defender Application Control controls each of these components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In contrast, all the components of a packaged app share the same publisher name, package name, and package version attributes. Therefore, you can control an entire app with a single rule.
@@ -43,8 +43,8 @@ Typically, an app consists of multiple components: the installer that is used to
Windows Defender Application Control policies for packaged apps can only be applied to apps installed on computers running at least Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least Windows Server
2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be enforced in tandem. The differences between packaged apps and classic Windows apps that you should consider include:
-- **Installing the apps** All packaged apps can be installed by a standard user, whereas a number of classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
-- **Changing the system state** Classic Windows apps can be written to change the system state if they are run with administrative privileges. Most packaged apps cannot change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it is important to understand whether an app that you are allowing can make system-wide changes.
+- **Installing the apps** All packaged apps can be installed by a standard user, whereas many classic Windows apps require administrative privileges to install. In an environment where most of the users are standard users, you might not have numerous exe rules (because classic Windows apps require administrative privileges to install), but you might want to have more explicit policies for packaged apps.
+- **Changing the system state** Classic Windows apps can be written to change the system state if they're run with administrative privileges. Most packaged apps can't change the system state because they run with limited privileges. When you design your Windows Defender Application Control policies, it's important to understand whether an app that you're allowing can make system-wide changes.
- **Acquiring the apps** Packaged apps can be acquired through the Store, or by loading using Windows PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired through traditional means.
Windows Defender Application Control uses different rule collections to control packaged apps and classic Windows apps. You have the choice to control one type, the other type, or both.
@@ -57,7 +57,7 @@ Just as there are differences in managing each rule collection, you need to mana
2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see [Deploy Windows Defender Application Control policy (WDAC) rules and file rules](select-types-of-rules-to-create.md).
-3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do this, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
+3. Continue to update the WDAC policies as new package apps are introduced into your environment. For information on how to do this update, see [Merge WDAC policies](merge-windows-defender-application-control-policies.md).
## Blocking Packaged Apps
@@ -65,7 +65,7 @@ You can now use `New-CIPolicyRule -Package $Package -Deny` to block packaged app
### Blocking Packaged Apps Which Are Installed on the System
-Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you are using the WDAC PowerShell cmdlets on:
+Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on the system you're using the WDAC PowerShell cmdlets on:
1. Get the app identifier for an installed package
@@ -116,9 +116,9 @@ Below are the list of steps you can follow to block one or more packaged apps in
```powershell
Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"}
```
- ### Blocking Packaged Apps Which Are Not Installed on the System
+ ### Blocking Packaged Apps Which Aren't Installed on the System
-If the app you intend to block is not installed on the system you are using the WDAC PowerShell cmdlets on, then follow the steps below:
+If the app you intend to block isn't installed on the system you're using the WDAC PowerShell cmdlets on, then follow the steps below:
1. Create a dummy rule using Steps 1-5 in the Blocking Packaged Apps Which Are Installed on the System section above
@@ -148,4 +148,4 @@ The method for allowing specific packaged apps is similar to the method outlined
$Rule = New-CIPolicyRule -Package $package -allow
```
-Since a lot of system apps are packaged apps, it is generally advised that customers rely on the sample policies in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules.
+Since many system apps are packaged apps, it's recommended that customers rely on the sample policies in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` to help allow all inbox apps by the Store signature already included in the policies and control apps with deny rules.
diff --git a/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md b/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md
index 0fbd505f00..dcc0b464fd 100644
--- a/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-block-rules.md
@@ -75,9 +75,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
- wslconfig.exe
- wslhost.exe
-1 A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](/sysinternals/downloads/bginfo). Note that BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
+1 A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for security, make sure to download and run the latest version here [BGInfo 4.22](/sysinternals/downloads/bginfo). BGInfo versions earlier than 4.22 are still vulnerable and should be blocked.
-2 If you are using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that is not being used in a development context, we recommend that you block msbuild.exe.
+2 If you're using your reference system in a development context and use msbuild.exe to build managed applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your reference system is an end-user device that isn't being used in a development context, we recommend that you block msbuild.exe.
* Microsoft recognizes the efforts of people in the security community who help us protect customers through responsible vulnerability disclosure, and extends thanks to the following people:
@@ -107,9 +107,9 @@ Unless your use scenarios explicitly require them, Microsoft recommends that you
Certain software applications may allow other code to run by design. Such applications should be blocked by your Windows Defender Application Control policy. In addition, when an application version is upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should add *deny* rules to your application control policies for that application’s previous, less secure versions.
-Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control. These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes.
+Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control. These modules can't be blocked by name or version, and therefore must be blocked by their corresponding hashes.
-For October 2017, we are announcing an update to system.management.automation.dll in which we are revoking older versions by hash values, instead of version rules.
+For October 2017, we're announcing an update to system.management.automation.dll in which we're revoking older versions by hash values, instead of version rules.
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet. Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of the following files:
diff --git a/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md b/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md
index 1d88193ede..7c16581109 100644
--- a/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules.md
@@ -36,11 +36,11 @@ The vulnerable driver blocklist is designed to help harden systems against third
- Known security vulnerabilities that can be exploited by attackers to elevate privileges in the Windows kernel
- Malicious behaviors (malware) or certificates used to sign malware
-- Behaviors that are not malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel
+- Behaviors that aren't malicious but circumvent the Windows Security Model and can be exploited by attackers to elevate privileges in the Windows kernel
Drivers can be submitted to Microsoft for security analysis at the [Microsoft Security Intelligence Driver Submission page](https://www.microsoft.com/en-us/wdsi/driversubmission). To report an issue or request a change to the vulnerable driver blocklist, including updating a block rule once a driver vulnerability has been patched, visit the [Microsoft Security Intelligence portal](https://www.microsoft.com/wdsi) or submit feedback on this article.
-Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) or S mode to protect your devices against security threats. If this isn't possible, Microsoft recommends blocking this list of drivers within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](audit-windows-defender-application-control-policies.md) and review the audit block events.
+Microsoft recommends enabling [HVCI](/windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity) or S mode to protect your devices against security threats. If this setting isn't possible, Microsoft recommends blocking this list of drivers within your existing Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in devices or software to malfunction, and in rare cases, blue screen. It's recommended to first validate this policy in [audit mode](audit-windows-defender-application-control-policies.md) and review the audit block events.
```xml
diff --git a/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md b/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
index 7e7c459ff7..6691993b1b 100644
--- a/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
+++ b/windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md
@@ -37,11 +37,11 @@ The first step in implementing application control is to consider how your polic
Most Windows Defender Application Control policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
-1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing.
+1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files aren't prevented from executing.
2. Deploy the audit mode policy to intended devices.
3. Monitor audit block events from the intended devices and add/edit/delete rules as needed to address unexpected/unwanted blocks.
4. Repeat steps 2-3 until the remaining block events meet expectations.
-5. Generate the enforced mode version of the policy. In enforced mode, files that are not allowed by the policy are prevented from executing and corresponding block events are generated.
+5. Generate the enforced mode version of the policy. In enforced mode, files that aren't allowed by the policy are prevented from executing and corresponding block events are generated.
6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
@@ -59,11 +59,11 @@ Use the [Set-CIPolicyIDInfo](/powershell/module/configci/set-cipolicyidinfo) cmd
> PolicyID only applies to policies using the [multiple policy format](deploy-multiple-windows-defender-application-control-policies.md) on computers running Windows 10, version 1903 and above, or Windows 11. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and prevent it from running on those earlier versions of Windows 10.
> PolicyID should be set only once per policy and use different PolicyID's for the audit and enforced mode versions of each policy.
-In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion) cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (e.g. "1.0.0.0").
+In addition, we recommend using the [Set-CIPolicyVersion](/powershell/module/configci/set-cipolicyversion) cmdlet to increment the policy's internal version number when you make changes to the policy. The version must be defined as a standard four-part version string (for example, "1.0.0.0").
### Policy rule updates
-As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you leverage WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you are less likely to need policy updates.
+As new apps are deployed or existing apps are updated by the software publisher, you may need to make revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide the most resiliency against app changes while rules based on file attributes or hash are most likely to require updates when apps change. Alternatively, if you use WDAC [managed installer](configure-authorized-apps-deployed-with-a-managed-installer.md) functionality and consistently deploy all apps and their updates through your managed installer, then you're less likely to need policy updates.
## WDAC event management
@@ -84,16 +84,16 @@ Considerations include:
### Help desk support
-If your organization has an established help desk support department in place, consider the following when deploying Windows Defender Application Control policies:
+If your organization has an established help desk support department in place, consider the following points when deploying Windows Defender Application Control policies:
- What documentation does your support department require for new policy deployments?
- What are the critical processes in each business group both in work flow and timing that will be affected by application control policies and how could they affect your support department's workload?
- Who are the contacts in the support department?
-- How will the support department resolve application control issues between the end user and those who maintain the Windows Defender Application Control rules?
+- How will the support department resolve application control issues between the end user and those resources who maintain the Windows Defender Application Control rules?
### End-user support
-Because Windows Defender Application Control is preventing unapproved apps from running, it is important that your organization carefully plan how to provide end-user support. Considerations include:
+Because Windows Defender Application Control is preventing unapproved apps from running, it's important that your organization carefully plan how to provide end-user support. Considerations include:
- Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
- How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily allow access to a blocked app?
@@ -102,6 +102,6 @@ Because Windows Defender Application Control is preventing unapproved apps from
After deciding how your organization will manage your Windows Defender Application Control policy, record your findings.
-- **End-user support policy.** Document the process that you will use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
+- **End-user support policy.** Document the process that you'll use for handling calls from users who have attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the administrator can update the Windows Defender Application Control policy, if necessary.
- **Event processing.** Document whether events will be collected in a central location called a store, how that store will be archived, and whether the events will be processed for analysis.
-- **Policy management.** Detail what policies are planned, how they will be managed, and how rules will be maintained over time.
+- **Policy management.** Detail what policies are planned, how they'll be managed, and how rules will be maintained over time.
diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
index 1b68313de8..474a39e5dd 100644
--- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
+++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
@@ -88,13 +88,13 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
| Rule level | Description |
|----------- | ----------- |
-| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
+| **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This level is the most specific level, and requires more effort to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level, but it doesn't typically require a policy update when any binary is modified. |
| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. More information about FilePath level rules can be found below. |
| **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. |
| **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (such as Intel, for device drivers). |
| **FilePublisher** | This level combines the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
-| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. |
+| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than other certificate levels, so the Windows Defender Application Control policy must be updated whenever these certificates change. |
| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level is typically one certificate below the root certificate because the scan doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). |
| **RootCertificate** | Currently unsupported. |
| **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. |
@@ -112,13 +112,13 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
-To create the Windows Defender Application Control policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
+To create the Windows Defender Application Control policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. With the help of the audit data, they update their WDAC policies to include any other software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
As part of normal operations, they'll eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they won't need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
## File rule precedence order
-Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
+Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these sets exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md).
## More information about filepath rules
@@ -132,7 +132,7 @@ WDAC's list of well-known admin SIDs are:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
-When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
+When filepath rules are being generated using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards, using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\*` would include `C:\foo\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path aren't supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`).
@@ -146,16 +146,16 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE%
## More information about hashes
-WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file does not change when the file is re-signed or timestamped, or the digital signature is removed from the file. By using the Authenticode hash, WDAC provides added security and less management overhead so customers do not need to revise the policy hash rules when the digital signature on the file is updated.
+WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file doesn't change when the file is re-signed or timestamped, or the digital signature is removed from the file. With the help of the Authenticode hash, WDAC provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated.
-The Authenticode/PE image hash can be calculated for digitally-signed and unsigned files.
+The Authenticode/PE image hash can be calculated for digitally signed and unsigned files.
### Why does scan create four hash rules per XML file?
The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash.
-During validation CI will choose which hashes to calculate, depending on how the file is signed. For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
+During validation, CI will choose which hashes to calculate, depending on how the file is signed. For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash.
-In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
+In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn’t result in a different hash than what was in the policy being used by CI.
### Why does scan create eight hash rules for certain XML files?
diff --git a/windows/security/threat-protection/windows-defender-application-control/types-of-devices.md b/windows/security/threat-protection/windows-defender-application-control/types-of-devices.md
index 6ff71e34a5..287c4058d0 100644
--- a/windows/security/threat-protection/windows-defender-application-control/types-of-devices.md
+++ b/windows/security/threat-protection/windows-defender-application-control/types-of-devices.md
@@ -29,27 +29,27 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control (WDAC) are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It is common for organizations to have device use cases across each of the categories described.
+Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying WDAC in your organization. It's common for organizations to have device use cases across each of the categories described.
## Types of devices
| **Type of device** | **How WDAC relates to this type of device** |
|------------------------------------|------------------------------------------------------|
| **Lightly managed devices**: Company-owned, but users are free to install software.
Devices are required to run organization's antivirus solution and client management tools. | Windows Defender Application Control can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. |
-| **Fully managed devices**: Allowed software is restricted by IT department.
Users can request additional software, or install from a list of applications provided by IT department.
Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves additional applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.
WDAC policies are supported by the HVCI service. |
-| **Fixed-workload devices**: Perform same tasks every day.
Lists of approved applications rarely change.
Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.
After Windows Defender Application Control deployment, only approved applications can run. This is because of protections offered by WDAC. |
-| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. |
+| **Fully managed devices**: Allowed software is restricted by IT department.
Users can request for more software, or install from a list of applications provided by IT department.
Examples: locked-down, company-owned desktops and laptops. | An initial baseline Windows Defender Application Control policy can be established and enforced. Whenever the IT department approves more applications, it will update the WDAC policy and (for unsigned LOB applications) the catalog.
WDAC policies are supported by the HVCI service. |
+| **Fixed-workload devices**: Perform same tasks every day.
Lists of approved applications rarely change.
Examples: kiosks, point-of-sale systems, call center computers. | Windows Defender Application Control can be deployed fully, and deployment and ongoing administration are relatively straightforward.
After Windows Defender Application Control deployment, only approved applications can run. This rule is because of protections offered by WDAC. |
+| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | In most cases, Windows Defender Application Control doesn't apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. However, you may choose to deploy an audit-mode policy to these devices or employ a blocklist only policy to prevent specific apps or binaries that are considered malicious or vulnerable by your organization. |
## An introduction to Lamna Healthcare Company
-In the next set of topics, we will explore each of the above scenarios using a fictional organization called Lamna Healthcare Company.
+In the next set of topics, we'll explore each of the above scenarios using a fictional organization called Lamna Healthcare Company.
Lamna Healthcare Company (Lamna) is a large healthcare provider operating in the United States. Lamna employs thousands of people, from doctors and nurses to accountants, in-house lawyers, and IT technicians. Their device use cases are varied and include single-user workstations for their professional staff, shared kiosks used by doctors and nurses to access patient records, dedicated medical devices such as MRI scanners, and many others. Additionally, Lamna has a relaxed, bring-your-own-device policy for many of their professional staff.
Lamna uses [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) in hybrid mode with both Configuration Manager and Intune. Although they use Microsoft Endpoint Manager to deploy many applications, Lamna has always had relaxed application usage practices: individual teams and employees have been able to install and use any applications they deem necessary for their role on their own workstations. Lamna also recently started to use [Microsoft Defender for Endpoint](https://www.microsoft.com/microsoft-365/windows/microsoft-defender-atp) for better endpoint detection and response.
-Recently, Lamna experienced a ransomware event that required an expensive recovery process and may have included data exfiltration by the unknown attacker. Part of the attack included installing and running malicious binaries that evaded detection by Lamna's antivirus solution but would have been blocked by an application control policy. In response, Lamna's executive board has authorized a number of new security IT responses, including tightening policies for application use and introducing application control.
+Recently, Lamna experienced a ransomware event that required an expensive recovery process and may have included data exfiltration by the unknown attacker. Part of the attack included installing and running malicious binaries that evaded detection by Lamna's antivirus solution but would have been blocked by an application control policy. In response, Lamna's executive board has authorized many new security IT responses, including tightening policies for application use and introducing application control.
## Up next
-- [Create a Windows Defender Application Control policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md)
+- [Create a Windows Defender Application Control policy for lightly managed devices](create-wdac-policy-for-lightly-managed-devices.md)
diff --git a/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md b/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
index 9729e7515d..406209261e 100644
--- a/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
+++ b/windows/security/threat-protection/windows-defender-application-control/understand-windows-defender-application-control-policy-design-decisions.md
@@ -44,15 +44,15 @@ You should consider using Windows Defender Application Control as part of your o
## Decide what policies to create
-Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
+Beginning with Windows 10, version 1903, Windows Defender Application Control allows [multiple simultaneous policies](deploy-multiple-windows-defender-application-control-policies.md) to be applied to each device. This concurrent application opens up many new use cases for organizations, but your policy management can easily become unwieldy without a well-thought-out plan for the number and types of policies to create.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust," we mean a description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will guide you as you create the actual policy rules for your policy XML.
For example, the DefaultWindows policy, which can be found under %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
-Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
+Configuration Manager uses the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a one-time scan of folder paths specified by the Configuration Manager administrator, which adds rules for any apps found in the specified paths on the managed endpoint. This process establishes the "circle-of-trust" for Configuration Manager's native WDAC integration.
-The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They are not in priority or sequential order, and are not meant to be an exhaustive set of design considerations.
+The following questions can help you plan your Windows Defender Application Control deployment and determine the right "circle-of-trust" for your policies. They aren't in priority or sequential order, and aren't meant to be an exhaustive set of design considerations.
## WDAC design considerations
@@ -74,11 +74,11 @@ Traditional Win32 apps on Windows can run without being digitally signed. This p
| Possible answers | Design considerations |
| - | - |
| All apps used in your organization must be signed. | Organizations that enforce [codesigning](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md) for all executable code are best-positioned to protect their Windows computers from malicious code execution. Windows Defender Application Control rules can be created to authorize apps and binaries from the organization's internal development teams and from trusted independent software vendors (ISV). |
-| Apps used in your organization do not need to meet any codesigning requirements. | Organizations can [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. |
+| Apps used in your organization don't need to meet any codesigning requirements. | Organizations can [use built-in Windows tools](deploy-catalog-files-to-support-windows-defender-application-control.md) to add organization-specific App Catalog signatures to existing apps as a part of the app deployment process, which can be used to authorize code execution. Solutions like Microsoft Endpoint Manager offer multiple ways to distribute signed App Catalogs. |
### Are there specific groups in your organization that need customized application control policies?
-Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. Consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There is overhead in managing policies that might lead you to choose between broad, organization-wide policies and multiple team-specific policies.
+Most business teams or departments have specific security requirements that pertain to data access and the applications used to access that data. Consider the scope of the project for each group and the group’s priorities before you deploy application control policies for the entire organization. There's overhead in managing policies that might lead you to choose between broad, organization-wide policies and multiple team-specific policies.
| Possible answers | Design considerations |
| - | - |
@@ -91,12 +91,12 @@ The time and resources that are available to you to perform the research and ana
| Possible answers | Design considerations |
| - | - |
-| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are constructed as simply as possible.|
+| Yes | Invest the time to analyze your organization's application control requirements, and plan a complete deployment that uses rules that are constructed as possible.|
| No | Consider a focused and phased deployment for specific groups by using few rules. As you apply controls to applications in a specific group, learn from that deployment to plan your next deployment. Alternatively, you can create a policy with a broad trust profile to authorize as many apps as possible. |
### Does your organization have Help Desk support?
-Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow is not hampered.
+Preventing your users from accessing known, deployed, or personal applications will initially cause an increase in end-user support. It will be necessary to address the various support issues in your organization so security policies are followed and business workflow isn't hampered.
| Possible answers | Design considerations |
| - | - |
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md b/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md
index fcb3a32077..b84336abab 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md
@@ -1,6 +1,6 @@
---
title: Use code signing to simplify application control for classic Windows applications (Windows)
-description: With embedded signing, your WDAC policies typically do not have to be updated when an app is updated. To set this up, you can choose from a variety of methods.
+description: With embedded signing, your WDAC policies typically don't have to be updated when an app is updated. To set up this embedded signing, you can choose from various methods.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
@@ -33,13 +33,13 @@ This topic covers guidelines for using code signing control classic Windows apps
## Reviewing your applications: application signing and catalog files
-Typically, Windows Defender Application Control (WDAC) policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
+Typically, Windows Defender Application Control (WDAC) policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This purpose means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
-Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your Windows Defender Application Control policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
+Catalog files can be useful for unsigned LOB applications that can't easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your Windows Defender Application Control policies typically don't have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
-To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
+To obtain signed applications or embed signatures in your in-house applications, you can choose from various methods:
-- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
+- Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll up to our certificate authority (CA) or to your own.
- Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
@@ -53,11 +53,11 @@ To use catalog signing, you can choose from the following options:
### Catalog files
-Catalog files (which you can create in Windows 10 and Windows 11 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by Windows Defender Application Control in the same way as any other signed application.
+Catalog files (which you can create in Windows 10 and Windows 11 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you don't want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by Windows Defender Application Control in the same way as any other signed application.
-Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also.
+Catalog files are Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also.
-After you have created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
+After you've created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
> [!NOTE]
> Package Inspector only works on operating systems that support Windows Defender, such as Windows 10 and Windows 11 Enterprise, Windows 10 and Windows 11 Education, Windows 2016 Server, or Windows Enterprise IoT.
@@ -66,8 +66,8 @@ For procedures for working with catalog files, see [Deploy catalog files to supp
## Windows Defender Application Control policy formats and signing
-When you generate a Windows Defender Application Control policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **<Rules>** section of the file.
+When you generate a Windows Defender Application Control policy, you're generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 and Windows 11 Enterprise, along with restrictions on Windows 10 and Windows 11 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **<Rules>** section of the file.
We recommend that you keep the original XML file for use when you need to merge the WDAC policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
-When the Windows Defender Application Control policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy.
+When the Windows Defender Application Control policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add more protection against administrative users changing or removing the policy.
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md b/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
index 1b87884a5e..a8e73a9c67 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-signed-policies-to-protect-windows-defender-application-control-against-tampering.md
@@ -29,20 +29,20 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
+Signed Windows Defender Application Control (WDAC) policies give organizations the highest level of malware protection available in Windows—must be signed with [PKCS #7](https://datatracker.ietf.org/doc/html/rfc5652). In addition to their enforced policy rules, signed policies can't be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this idea of the policies in mind, it's much more difficult to remove signed WDAC policies. SecureBoot must be enabled in order to restrict users from updating or removing signed WDAC policies.
Before you sign with PKCS #7 and deploy a signed WDAC policy, we recommend that you [audit the policy](audit-windows-defender-application-control-policies.md) to discover any blocked applications that should be allowed to run.
Signing WDAC policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward.
-If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA.
+If you don't currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) to create one with your on-premises CA.
-Before PKCS #7-signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
+Before PKCS #7-signing WDAC policies for the first time, ensure you enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath -Option 9`, even if you're not sure whether the option is already enabled. If so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Windows Defender Application Control policy rules](select-types-of-rules-to-create.md).
To sign a Windows Defender Application Control policy with SignTool.exe, you need the following components:
- SignTool.exe, found in the [Windows SDK](https://developer.microsoft.com/windows/downloads/windows-10-sdk/) (Windows 7 or later)
-- The binary format of the WDAC policy that you generated in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) or another WDAC policy that you have created
+- The binary format of the WDAC policy that you generated in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) or another WDAC policy that you've created
- An internal CA code signing certificate or a purchased code signing certificate
@@ -52,7 +52,7 @@ To sign a Windows Defender Application Control policy with SignTool.exe, you nee
>Certificate fields, like 'subject common name' and 'issuer common name,' cannot be UTF-8 encoded, otherwise, blue screens may occur. These strings must be encoded as PRINTABLE_STRING, IA5STRING or BMPSTRING.
-If you do not have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (WDAC) policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session:
+If you don't have a code signing certificate, see [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md) for instructions on how to create one. If you use an alternate certificate or Windows Defender Application Control (WDAC) policy, ensure you update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated Windows PowerShell session:
1. Initialize the variables that will be used:
@@ -64,7 +64,7 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
> [!NOTE]
> This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are signing another policy, be sure to update the **$CIPolicyPath** variable with the correct information.
-2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
+2. Import the .pfx code signing certificate. Import the code signing certificate that you'll use to sign the WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md).
3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md
index 869d7f489a..b3e830a04b 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md
@@ -29,7 +29,7 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-As of Windows 10, version 1703, you can use Windows Defender Application Control (WDAC) policies not only to control applications, but also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
+As of Windows 10, version 1703, you can use Windows Defender Application Control (WDAC) policies to control applications and also to control whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business application or a browser):
| Approach (as of Windows 10, version 1703) | Guideline |
|---|---|
@@ -38,7 +38,7 @@ As of Windows 10, version 1703, you can use Windows Defender Application Control
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your 'master' policy (merging is described in the next section).
-For example, to create a Windows Defender Application Control policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
+For example, to create a Windows Defender Application Control policy allowing **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. In the second command, **+=** is used to add a second rule to the **$rule** variable:
```powershell
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md
index 19f39c1525..337a1853f6 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md
@@ -20,15 +20,15 @@ ms.technology: windows-sec
# Windows Defender Application Control and .NET hardening
-Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those approved by an organization.
+Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those sets approved by an organization.
Security researchers have found that some .NET applications may be used to circumvent those controls by using .NET’s capabilities to load libraries from external sources or generate new code on the fly.
Beginning with Windows 10, version 1803, or Windows 11, Windows Defender Application Control features a new capability, called *Dynamic Code Security* to verify code loaded by .NET at runtime.
When the Dynamic Code Security option is enabled, Windows Defender Application Control policy is applied to libraries that .NET loads from external sources.
Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with.
-Dynamic Code Security is not enabled by default because existing policies may not account for externally loaded libraries.
-Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, are not currently supported with Dynamic Code Security enabled.
+Dynamic Code Security isn't enabled by default because existing policies may not account for externally loaded libraries.
+Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled.
Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy.
Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/precompiling-your-website-cs) document for how to fix that.
diff --git a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md
index 4e1abd6929..251e30f962 100644
--- a/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md
+++ b/windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md
@@ -36,7 +36,7 @@ Beginning with Windows 10, version 1709, you can set an option to automatically
The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having "known good," "known bad," or "unknown" reputation. When a binary runs on a system, with Windows Defender Application Control (WDAC) enabled with the ISG option, WDAC checks the file's reputation, by sending its hash and signing information to the cloud. If the ISG reports that the file has a "known good" reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file.
-If your WDAC policy does not have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC will not make a call to the cloud.
+If your WDAC policy doesn't have an explicit rule to allow or deny a binary to run, then WDAC will make a call to the cloud to determine whether the binary is familiar and safe. However, if your policy already authorizes or denies the binary, then WDAC won't make a call to the cloud.
If the file with good reputation is an application installer, its reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer.
@@ -54,7 +54,7 @@ Setting up the ISG is easy using any management solution you wish. Configuring t
### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
-To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set.
+To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the Windows Defender Application Control policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option isn't recommended for devices that don't have regular access to the internet. The following example shows both options being set.
```xml
@@ -84,7 +84,7 @@ To allow apps and binaries based on the Microsoft Intelligent Security Graph, th
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
-In order for the heuristics used by the ISG to function properly, a number of components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
+In order for the heuristics used by the ISG to function properly, many components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
```console
appidtel start
@@ -99,7 +99,7 @@ Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, i
Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation. Also, since the ISG option passes along reputation from application installers to the binaries they write to disk, it can over-authorize files in some cases where the installer launches the application upon completion.
## Using fsutil to query SmartLocker EA
-Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This can be achieved by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This can be used in conjunction with enabling the MI and ISG logging events.
+Customers using Windows Defender Application Control (WDAC) with Managed Installer (MI) or Intelligent Security Graph enabled can use fsutil to determine whether a file was allowed to run by one of these features. This verification can be done by querying the EAs on a file using fsutil and looking for the KERNEL.SMARTLOCKER.ORIGINCLAIM EA. The presence of this EA indicates that either MI or ISG allowed the file to run. This EA's presence can be used in conjunction with enabling the MI and ISG logging events.
#### Example
@@ -123,9 +123,9 @@ Ea Value Length: 7e
## Known limitations with using the Intelligent Security Graph
-Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom.
+Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by Windows Defender Application Control (WDAC). In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, and self-updating applications, may exhibit this symptom.
-Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy.
+Packaged apps aren't supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it's straightforward to authorize these apps with your WDAC policy.
The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.
diff --git a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md
index 6737ed1fd8..696ab59fea 100644
--- a/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md
+++ b/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview.md
@@ -45,19 +45,19 @@ Windows Defender Application Control policies apply to the managed computer as a
- The [path from which the app or file is launched](select-types-of-rules-to-create.md#more-information-about-filepath-rules) (beginning with Windows 10 version 1903)
- The process that launched the app or binary
-Note that prior to Windows 10 version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). WDAC was also one of the features that comprised the now-defunct term "Device Guard."
+Prior to Windows 10 version 1709, Windows Defender Application Control was known as configurable code integrity (CCI). WDAC was also one of the features that comprised the now-defunct term "Device Guard."
### WDAC System Requirements
Windows Defender Application Control (WDAC) policies can be created on any client edition of Windows 10 build 1903+, or Windows 11, or on Windows Server 2016 and above.
-WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but cannot deploy policies to devices running non-Enterprise SKUs of Windows 10.
+WDAC policies can be applied to devices running any edition of Windows 10, Windows 11, or Windows Server 2016 and above, via a Mobile Device Management (MDM) solution, for example, Intune; a management interface such as Configuration Manager; or a script host such as PowerShell. Group Policy can also be used to deploy WDAC policies to Windows 10 and Windows 11 Enterprise edition, or Windows Server 2016 and above, but can't deploy policies to devices running non-Enterprise SKUs of Windows 10.
For more information on which individual WDAC features are available on specific WDAC builds, see [WDAC feature availability](feature-availability.md).
## AppLocker
-AppLocker was introduced with Windows 7, and allows organizations to control which applications are allowed to run on their Windows clients. AppLocker helps to prevent end-users from running unapproved software on their computers but does not meet the servicing criteria for being a security feature.
+AppLocker was introduced with Windows 7, and allows organizations to control which applications are allowed to run on their Windows clients. AppLocker helps to prevent end-users from running unapproved software on their computers but doesn't meet the servicing criteria for being a security feature.
AppLocker policies can apply to all users on a computer, or to individual users and groups. AppLocker rules can be defined based on:
@@ -72,13 +72,13 @@ AppLocker policies can be deployed using Group Policy or MDM.
## Choose when to use WDAC or AppLocker
-Generally, it is recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
+Generally, it's recommended that customers, who are able to implement application control using Windows Defender Application Control rather than AppLocker, do so. WDAC is undergoing continual improvements, and will be getting added support from Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo new feature improvements.
However, in some cases, AppLocker may be the more appropriate technology for your organization. AppLocker is best when:
- You have a mixed Windows operating system (OS) environment and need to apply the same policy controls to Windows 10 and earlier versions of the OS.
- You need to apply different policies for different users or groups on shared computers.
-- You do not want to enforce application control on application files such as DLLs or drivers.
+- You don't want to enforce application control on application files such as DLLs or drivers.
-AppLocker can also be deployed as a complement to Windows Defender Application Control (WDAC) to add user or group-specific rules for shared device scenarios, where it is important to prevent some users from running specific apps.
+AppLocker can also be deployed as a complement to Windows Defender Application Control (WDAC) to add user or group-specific rules for shared device scenarios, where it's important to prevent some users from running specific apps.
As a best practice, you should enforce WDAC at the most restrictive level possible for your organization, and then you can use AppLocker to further fine-tune the restrictions.
diff --git a/windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-base-policy.md b/windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-base-policy.md
index 9d8ec5a0c7..e1353dfcf7 100644
--- a/windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-base-policy.md
+++ b/windows/security/threat-protection/windows-defender-application-control/wdac-wizard-create-base-policy.md
@@ -30,12 +30,12 @@ ms.technology: windows-sec
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md).
-When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start with a template policy and then add or remove rules to suit your application control scenario. For this reason, the WDAC Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules.
+When creating policies for use with Windows Defender Application Control (WDAC), it's recommended to start with a template policy, and then add or remove rules to suit your application control scenario. For this reason, the WDAC Wizard offers three template policies to start from and customize during the base policy creation workflow. Prerequisite information about application control can be accessed through the [WDAC design guide](windows-defender-application-control-design-guide.md). This page outlines the steps to create a new application control policy from a template, configure the policy options, and the signer and file rules.
## Template Base Policies
-Each of the template policies has a unique set of policy allow list rules that will affect the circle-of-trust and security model of the policy. The following table lists the policies in increasing order of trust and freedom. For instance, the Default Windows mode policy trusts fewer application publishers and signers than the Signed and Reputable mode policy. The Default Windows policy will have a smaller circle-of-trust with better security than the Signed and Reputable policy, but at the expense of compatibility.
+Each of the template policies has a unique set of policy allowlist rules that will affect the circle-of-trust and security model of the policy. The following table lists the policies in increasing order of trust and freedom. For instance, the Default Windows mode policy trusts fewer application publishers and signers than the Signed and Reputable mode policy. The Default Windows policy will have a smaller circle-of-trust with better security than the Signed and Reputable policy, but at the expense of compatibility.
| Template Base Policy | Description |
@@ -64,11 +64,11 @@ A description of each policy rule, beginning with the left-most column, is provi
|------------ | ----------- |
| **Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all Windows Defender Application Control policies. Setting this rule option allows the F8 menu to appear to physically present users. |
| **Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. |
-| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 is not supported and may have unintended results. |
+| **Disable Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is required to run HTA files, and is only supported with the Windows 10 May 2019 Update (1903) and higher. Using it on earlier versions of Windows 10 isn't supported and may have unintended results. |
|**[Hypervisor-protected code integrity (HVCI)](../device-guard/enable-virtualization-based-protection-of-code-integrity.md)**| When enabled, policy enforcement uses virtualization-based security to run the code integrity service inside a secure environment. HVCI provides stronger protections against kernel malware.|
| **Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by the Microsoft Intelligent Security Graph (ISG). |
| **Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. |
-| **Require WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windows–compatible driver must be WHQL certified. |
+| **Require WHQL** | By default, legacy drivers that aren't Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Henceforth, every new Windows–compatible driver must be WHQL certified. |
| **Update Policy without Rebooting** | Use this option to allow future Windows Defender Application Control policy updates to apply without requiring a system reboot. |
| **Unsigned System Integrity Policy** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
| **User Mode Code Integrity** | Windows Defender Application Control policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
@@ -83,7 +83,7 @@ Selecting the **+ Advanced Options** label will show another column of policy ru
| Rule option | Description |
|------------ | ----------- |
| **Boot Audit on Failure** | Used when the Windows Defender Application Control (WDAC) policy is in enforcement mode. When a driver fails during startup, the WDAC policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
-| **Disable Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
+| **Disable Flight Signing** | If enabled, WDAC policies won't trust flightroot-signed binaries. This option would be used in the scenario in which organizations only want to run released binaries, not flight/preview-signed builds. |
| **Disable Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that's only writable by an administrator) for any FileRule that allows a file based on FilePath. |
| **Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries (DLLs). |
| **Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.|
@@ -104,17 +104,17 @@ The Publisher file rule type uses properties in the code signing certificate cha
| Rule Condition | WDAC Rule Level | Description |
|------------ | ----------- | ----------- |
-| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate will be affected. |
-| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example a device driver corp, is affected. |
+| **Issuing CA** | PCACertificate | Highest available certificate is added to the signers. This certificate is typically the PCA certificate, one level below the root certificate. Any file signed by this certificate will be affected. |
+| **Publisher** | Publisher | This rule is a combination of the PCACertificate rule and the common name (CN) of the leaf certificate. Any file signed by a major CA but with a leaf from a specific company, for example, a device driver corp, is affected. |
| **File version** | SignedVersion | This rule is a combination of PCACertificate, publisher, and a version number. Anything from the specified publisher with a version at or above the one specified is affected. |
-| **File name** | FilePublisher | Most specific. Combination of the file name, publisher, and PCA certificate as well as a minimum version number. Files from the publisher with the specified name and greater or equal to the specified version are affected. |
+| **File name** | FilePublisher | Most specific. Combination of the file name, publisher, and PCA certificate and a minimum version number. Files from the publisher with the specified name and greater or equal to the specified version are affected. |

### Filepath Rules
-Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button.
+Filepath rules don't provide the same security guarantees that explicit signer rules do, as they're based on mutable access permissions. To create a filepath rule, select the file using the *Browse* button.
### File Attribute Rules
@@ -132,11 +132,11 @@ The Wizard supports the creation of [file name rules](select-types-of-rules-to-c
### File Hash Rules
-Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause additional administrative overhead to maintain the current product version's hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule cannot be created using the specified file rule level.
+Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can cause extra administrative overhead to maintain the current product version's hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as the fallback in case a file rule can't be created using the specified file rule level.
#### Deleting Signing Rules
-The policy signing rules list table on the left of the page will document the allow and deny rules in the template, as well as any custom rules you create. Template signing rules and custom rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. you will be prompted for additional confirmation. Select `Yes` to remove the rule from the policy and the rules table.
+The policy signing rules list table on the left of the page will document the allow and deny rules in the template, and any custom rules you create. Template signing rules and custom rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath the table. You'll be prompted for another confirmation. Select `Yes` to remove the rule from the policy and the rules table.
## Up next
From fb92d632fe0231a24caafb01e3b2e793478aebbc Mon Sep 17 00:00:00 2001
From: Scott Breen <39719539+scottbreenmsft@users.noreply.github.com>
Date: Tue, 5 Jul 2022 12:52:08 +1000
Subject: [PATCH 022/299] Add files via upload
---
education/windows/change-home-to-edu.md | 221 ++++++++++++++++++++++++
1 file changed, 221 insertions(+)
create mode 100644 education/windows/change-home-to-edu.md
diff --git a/education/windows/change-home-to-edu.md b/education/windows/change-home-to-edu.md
new file mode 100644
index 0000000000..a785c5737c
--- /dev/null
+++ b/education/windows/change-home-to-edu.md
@@ -0,0 +1,221 @@
+---
+title: Upgrade Windows Home to Windows Education on personal devices using volume licensing
+description: Learn how IT Pros can upgrade personal devices from Windows Home to Windows Education using Mobile Device Management and qualifying subscriptions.
+keywords: upgrade, Windows Home to Windows Education, education customers, Windows 10 Home, Windows 11 Home, Windows 11 Education, Windows 10 Education, Intune, Mobile Device Management
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: edu
+ms.localizationpriority: medium
+author: scottbreenmsft
+ms.author: scbree
+ms.date: 07/05/2021
+ms.reviewer: aczechowski
+manager: aczechowski
+---
+
+# Upgrade Windows Home to Windows Education on personal devices using volume licensing
+
+## Overview
+
+Customers with qualifying subscriptions can upgrade students personal (or institution-owned) devices from Windows Home to Windows Education, which is designed for both the classroom and remote learning.
+
+> [!NOTE]
+> To be qualified for this process, customers must have a Windows Education subscription that includes the student use benefit and must have access to the Volume Licensing Service Center (VLSC) or the Microsoft 365 Admin Center.
+
+IT staff can upgrade student devices using a multiple activation key (MAK). Alternatively, student devices can be upgraded by contacting [Kivuto OnTheHub](http://onthehub.com) to obtain a product key for their device. The table below provides the recommended approach depending on the scenario.
+
+|Method|MAK source|Device ownership|Best for|
+|-|-|-|-|
+|Mobile Device Management|Volume License Service Center|Personal|IT admin initiated as part of enrolment into device management|
+|Kivuto|Kivuto|Personal|Initiated on device by student, parent or guardian|
+|Provisioning package|Volume license center|Personal or Corporate|IT admin initiated before performing Autopilot|
+
+Devices can be upgraded from Windows Professional or Windows Pro Edu to Windows Education or Windows Enterprise using [Windows 10/11 Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-subscription-activation).
+
+## Why upgrade personal devices from Windows Home to Windows Education?
+
+Some configuration service providers (CSPs) are not available on Windows Home which can limit the management capabilities. Some key CSPs that can affect mobile device management are:
+
+- [EnterpriseDesktopAppManagement](/client-management/mdm/enterprisemodernappmanagement-csp) - which enables deployment of Windows installer or Win32 applications
+- [DeliveryOptimization](/client-management/mdm/policy-csp-deliveryoptimization) - which enables configuration of Delivery Optimization
+
+A full list is available at [Configuration service provider reference](/client-management/mdm/configuration-service-provider-reference).
+
+## Requirements for using a MAK to upgrade from Windows Home to Windows Education
+
+- Access to Volume Licensing Service Center (VLSC) or the Microsoft 365 Admin Center.
+- A qualifying Windows subscription such as:
+ - Windows A3, or;
+ - Windows A5.
+- A pre-installed and activated instance of Windows 10 Home or Windows 11 Home.
+
+You can find more information in the [Microsoft Product Terms](https://www.microsoft.com/licensing/terms/productoffering).
+
+## How the upgrade process works
+
+IT admins with access to the VLSC or the Microsoft 365 Admin Center, can find their MAK for Windows Education and trigger an upgrade via Mobile Device Management or manually on devices.
+
+> [!WARNING]
+> The MAK key is highly sensitive and should always be protected. Only authorized staff should be given access to the key and it should never be distributed to students or broadly to your organization in documentation or emails.
+
+### Recommended methods for using a MAK
+
+It’s critical that MAKs are protected whenever they are used. The following processes provide the best protection for a MAK being applied to a device:
+
+- Provisioning package by institution approved staff;
+- Manual entry by institution approved staff (do not distribute the key via email);
+- Mobile Device Management (like Microsoft Intune) via [WindowsLicensing CSP](https://docs.microsoft.com/windows/client-management/mdm/windowslicensing-csp);
+ > [!IMPORTANT]
+ > If you are using a Mobile Device Management product other than Microsoft Intune, ensure the key is not accessible by students.
+- Operating System Deployment processes with tools such as Microsoft Deployment Toolkit or Microsoft Endpoint Configuration Manager.
+
+ For a full list of methods to perform a Windows edition upgrade and more details, see [Windows 10 edition upgrade](https://docs.microsoft.com/windows/deployment/upgrade/windows-10-edition-upgrades).
+
+## Downgrading, resetting, reinstalling and graduation rights
+
+After upgrading from Windows Home to Windows Education there are some considerations for what happens during downgrade, reset or re-install of the operating system.
+
+The table below highlights the differences by upgrade product key type:
+
+|MAK Type|Downgrade|Reset|Student re-install|
+|-|-|-|-|
+|MAK from VLC|No|Yes|No|
+|MAK from Kivuto|No|Yes|Yes|
+
+### Downgrade
+
+It is not possible to downgrade to Windows Home from Windows Education without reinstalling Windows.
+
+### Reset
+
+If the computer is reset, Windows Education will be retained.
+
+### Re-install
+
+If a device upgraded by VLSC MAK has Windows reinstalled by the student, it would need to be reinstalled with Windows Home or whatever edition was installed originally on the device to activate successfully using the key provided with the device at purchase.
+
+If students require a Windows Education key that can work on a new install of Windows, they should use [Kivuto OnTheHub](http://onthehub.com) to request a key prior to graduation.
+
+For details on product keys and reinstalling Windows, see [Find your Windows product key](https://support.microsoft.com/windows/find-your-windows-product-key-aaa2bf69-7b2b-9f13-f581-a806abf0a886).
+
+### Re-sale
+
+The license will remain installed on the device if resold and the same conditions above apply for downgrade (in-place) reset or reinstall.
+
+## User Notifications
+
+Users are not prompted or notified that their device has been or will be upgraded to Windows Education when using MDM. It is the responsibility of the institution to notify their users that enrolling in MDM will result in the device being upgraded to Windows Education and that this will give the institution extra capabilities such as installing applications.
+
+As always, device users can unenroll from within Settings to prevent further actions from being taken on their personal device.
+
+## Step by step process for customers to upgrade personal devices using Microsoft Intune
+
+These steps will configure a Windows edition upgrade policy and target all Windows Home devices that are managed by Microsoft Intune for the upgrade to Windows Education edition using your MAK.
+
+### Step 1: Create a Windows Home edition filter
+
+Filters allow you to target the all devices group but to a subset of devices using a filter. In this case the filter will be based on the operating system SKU. This will ensure we only upgrade devices that are running Windows Home edition and avoid upgrading devices that are running Windows Pro/Pro EDU edition which can upgrade using [Windows 10/11 Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-subscription-activation).
+
+- Start in the **Microsoft Endpoint Manager admin console**
+- Go to **Tenant Administration** > **Filters**
+- Click **Create**
+ - Create a name for the filter (for example *Windows Home edition*)
+ - Select the **platform** as **Windows 10 and later**
+ - Click **Next**
+- On the **Rules** screen, configure the following rules:
+ - **operatingSystemSKU** equals **Core (Windows 10/11 Home (101))**
+ - OR
+ - **operatingSystemSKU** equals **CoreN (Windows 10/11 Home N (98))**
+ - OR
+ - **operatingSystemSKU** equals **CoreSingleLanguage (Windows 10/11 Home single language (100))**
+
+ > [!NOTE]
+ > Ensure you’ve selected OR as the operator in the right And/Or column
+
+ :::image type="content" source="/images/change-home-to-edu/windows-home-edition-intune-filter.png" alt-text="Example of configuring the Windows Home filter":::
+
+- Optionally select scope tags as required
+- Save the filter by clicking **Create**
+
+### Step 2: Create a Windows edition upgrade policy
+
+- Start in the **Microsoft Endpoint Manager admin console**
+- Select **Devices** > **Configuration profiles**
+- Select **Create profile**
+ - Select the **Platform** as **Windows 10 or later**
+ - Select the **Profile type** as **Templates**
+ - Select the **Template** as **Edition upgrade and mode switch**
+ - Click **Create**
+- Create a name for the filter (for example *Windows Education edition upgrade*), click **Next**
+- On the **Configuration settings** screen
+ - Expand **Edition Upgrade**
+ - Change **Edition to upgrade** to **Windows 10/11 Education**
+ - In the **Product Key**, enter your *Windows 10/11 Education MAK*
+ - Click **Next**
+- Optionally select scope tags as required and click **Next**
+- On the **assignments** screen;
+ - Select **Add all devices**
+ - Next to **All devices**, select **Edit filter**
+ - Select to **Include filtered devices in assignment**
+ - Select the *Windows Home edition* filter you created earlier
+ - Click **Select** to save the filter selection
+ - Click **Next** to progress to the next screen
+
+ :::image type="content" source="/images/change-home-to-edu/windows-edition-upgrade-policy.png" alt-text="Example of configuring the Windows upgrade policy in Microsoft Intune":::
+- Do not configure any applicability rules and click **next**
+- Review your settings and click **Create**
+
+The edition upgrade policy will now apply to all existing and new Windows Home edition devices in your tenant. You can verify they’ve upgraded by checking the Operating System SKU field on the device > hardware screen.
+
+### Step 3: Report on device edition
+
+- Start in the **Microsoft Endpoint Manager admin console**
+- Select **Devices** > **Windows**
+- Select the **Columns** button
+- Select **Sku Family**
+- Click **Export**
+- Select **Only include the selected columns in the exported file** and click **Yes**
+- Open the file in Excel and filter on the Sku Family column to identify which devices are running the Home SKU
+
+## Frequently asked questions (FAQ)
+
+### My MAK key has run out of activations, how do I request a new one?
+
+- Increases to MAK Activation quantity can be requested via Web Form and may be granted by exception.
+- To do this you must have VLSC Administrator, Key Administrator, or Key Viewer permissions and provide the following information:
+ - Agreement/Enrollment Number or License ID and Authorization.
+ - Product Name (includes version and edition).
+ - Last 5 characters of the product key.
+ - The number of host activations required.
+ - Business Justification or Reason for Deployment.
+
+### What is a firmware-embedded activation key?
+A firmware-embedded activation key is a Windows product key that is installed into the firmware of your device to allow for easy activation of Windows. To determine if the computer has a firmware-embedded activation key, type the following command at an elevated Windows PowerShell prompt:
+
+```powershell
+(Get-CimInstance -query ‘select * from SoftwareLicensingService’).OA3xOriginalProductKey
+```
+
+If the device has a firmware-embedded activation key, it will be displayed in the output. If the output is blank, the device does not have a firmware embedded activation key. Most OEM-provided devices designed to run Windows 8 or later will have a firmware-embedded key.
+
+A firmware embedded key is only required to upgrade using Subscription Activation, a MAK upgrade does not require the firmware embedded key.
+
+### What is a multiple activation key and how does it differ from using KMS, Active Directory based activation or Subscription Activation?
+
+A multiple activation key activates either individual computers or a group of computers by connecting directly to servers over the internet or by telephone. KMS, Active Directory based activation and subscription activation are bulk activation methods that work based on network proximity or joining to Active Directory or Azure Active Directory. The table below shows which methods can be used for each scenario.
+
+| Scenario | Ownership | MAK | KMS | AD based activation | Subscription Activation |
+|-|-|-|-|-|-|
+| Workplace join (add work or school account) | Personal | X | | | |
+Azure Active Directory Join | Organization | X | X | | X |
+Hybrid Azure AD Join | Organization | X | X | X | X |
+
+
+## Related links
+
+- [Windows 10 edition upgrade (Windows 10)](https://docs.microsoft.com/windows/deployment/upgrade/windows-10-edition-upgrades)
+- [Windows 10/11 Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-subscription-activation)
+- [Equip Your Students with Windows 11 Education – Kivuto](https://kivuto.com/windows-11-student-use-benefit/)
+- [Upgrade Windows Home to Windows Pro (microsoft.com)](https://support.microsoft.com/windows/upgrade-windows-home-to-windows-pro-ef34d520-e73f-3198-c525-d1a218cc2818)
+- [Partner Center: Upgrade Education customers from Windows 10 Home to Windows 10 Education](https://docs.microsoft.com/partner-center/upgrade-windows-to-education)
From cf0ea5ae8133b125ea8c0d6ea3d59c4294006990 Mon Sep 17 00:00:00 2001
From: Scott Breen <39719539+scottbreenmsft@users.noreply.github.com>
Date: Tue, 5 Jul 2022 12:53:07 +1000
Subject: [PATCH 023/299] Add files via upload
---
.../images/windows-edition-upgrade-policy.png | Bin 0 -> 45890 bytes
.../windows-home-edition-intune-filter.png | Bin 0 -> 40112 bytes
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 education/windows/images/windows-edition-upgrade-policy.png
create mode 100644 education/windows/images/windows-home-edition-intune-filter.png
diff --git a/education/windows/images/windows-edition-upgrade-policy.png b/education/windows/images/windows-edition-upgrade-policy.png
new file mode 100644
index 0000000000000000000000000000000000000000..f9c4fc3a128310e500be82ccfaa19de52549b613
GIT binary patch
literal 45890
zcmbTdby!r<*DpSbf})5>w}424bc0GtcZbq2bT^73-QC^I3|&fh49&pM-9yK~@A!S+
zd!PGz|GCd|&-1{Ub9S74&R%=1&-$#jgOwDdurNt5K_C#;7in=75D1M11bQs<>@jes
zN*D_YoE|x;NPPxXjF9aB7f;MT$$tWYsv}?AeR~RAKew0Gb^?K3b^iN%)N5B{0s_^{
zd=dYo=5DaR_~K)%`UA#sVCZ*h#+=8iSP*d^iEdrQKueq%gC8doq;GNvHUO=!k@K#F
zUdor34NZn{v9NSD=dWUM+7%_$a|9ATk$56u`_txO$zx>h!rHnj9LwHUwA^FFW5j6=
z5-8lB?v!CpF*i3C^KQpkpj<;&NhvBmK0YxqF*Q|JPfuQl*QyQfU@t%>^??e;q)Bl(Xz5KU=-QhFaC9@O<#jNImxCUG(5uBqSDb$i`o!9Zl0?x!f6~8{PHk>(dfr{Y?LK|_lv7rt
z>@2~>;d}I)y5P~mt92$%;qB5FKJipSOa+fXf5_i+azZdAbc8Ax85v6qT0Jc+irU-T
z>+9>2(Cu&OSy>C%*b~_dS?TGEG|EZ*SwPNOO5_z46@BacorAZ`BZa|94qIK8ta=Kv
zmn!*;w!%$0@dUv4N5#Mm$U6j7JOTudIPF=&2Lq
zD30n7vpurM{+&zmmjLu#qS^Jp^Zt5EFyVvMBz?*|M)e>m3Xk=nWKQbbj{#g?O!hU^
z50M|q5O2s)7|X00Wm;6g(sBE4*N(c_t85q1>)>7T#w8@A0~$6uZ7F03%`wmBFyq7C
zMc3nY^HAv4Sr;3&x6xN=D<~*fTknsg3rZkj5UpOS=^T}`dEr@XD3b7ks;cA7;Z)S^
zB_Xc0QdzvgtznC^U;X!jZz*?=!wcPl3e8lE+3XhR-jw_<*R7u}Q6HR{nHd}$oS2wM
z&`pBz^4|pE5Cg-~90)Y%_M;$KElFU}O&Ah*OGDH77a^wOu=9-|8xzkmSWbK2W(;Pf
zjr!?lh+<#KO!rbCySz|fJd>t5Fhh!7vgmGLL-;Ug
zSV)bBIC85UZ_fWTTKzb8jLc+}89b+_KW=du6k|GQ9SQ6{W;B&~I4Rymr#vLg_vAV+
zrkv2WdI+4780b^co-+2vQjlb8?|Q{VN5_WL(i?SiH6SDgL!a`7a0UGWXrJXlw#fD4&$ncPuGVukrqsDov}&vzAW%IO
z&*p-F^7FL6C(?UWLs3;hGtL4CmxhOX6Ysaw1Xf;aJL4e&AS#K%*i_$|Jlid$Pekd!1vJQO34C
z8=)#%5JdfSLx?N1ttKEbhaOTREjFc67e7r^2~%Q@(bQyYID24%9n~L
zOS?YO4o;k%^q%@r3wAqPNREq3VAD)2Gi`}HfEW{
zc#Zgfmcuz<$g?wgW|%d9O2HJqYz89Zkqf2m3{=s_PO)95$w>dCd_g$z#gtBZVY%kp
z9#O)PQ8cvJG#+agbdy9*%9h@LZ%P^Qahmu$F5Zqkw@ygL1Ix
z2iiKnhrpH5+CojmP1zHIO1IaiV@95unO${JF)$|w=Epf$+bk!Ia|FKzzeR6IB-EAP
zuAOmK9U=;bb0Q0>`gfXF^S5&a=Qt|&4cNGCnKj?Lc**JTHHifl7N9N{Gs53799$_9
zl8A8Sxg8;tm9wWdNSajqQpR3ehf|6o8oy14;4_KKwmyyzjeBg10)Y-o^qXC&)jyk<
z%q+n(h%^>~xA(8(001q{=4AFW1z+E)-kmV%FFui{P}m9@_xL5>gJVYjqNsWW!wVBW@j$AT$@HR>@~|drW&gXrdsUiW6-jhk&%&PI02lbB$O*7gCspr
z^IYHZ)%`DO!Cp;TsPOo3N=TR~9<|Rx7)GezhIIEX_(KGW?j}h}!-$wbd6G^=!Pq5w
zx?bJZHQ!f(630sqG)V3G191!$A~Q|r}B2ZWX$o}TNawe9!G*$f(lvIdP<
zG!+>2I}dB&xA$&Bf~cm%b!D|YhBg=QXn?=JQUB&EaT-^|rjNdfUz+w&wyAvTmzKiF
zY>&L{TdZ>V>0ex6O16|Xm|Hi~&6ABoHtGb`i;Jp;5+6>FfLo6^6Ay|yNwMPOn8B(d
zu$?il#Z4roZlwi|%|~lH_9&SQ;W{@>rch=ZU48=FgE-yp^~BUS^{P4f%lUv$ov1-u|c+KNBX1%bZi!fWK2PLB2no!((9DyD1b(wquO
zsA?jGIJw$(5-YtdTvDjh74(xbj$E!vbcU4BJNZ~VvNZZ|Pv>6K%#E1QdSPo@yp`$2jdL9cWoIrdJIKbY?APronAmUWg9+&`#bGEu
zzloAE`$kOQ;xlplneNNDtEA3*(m&{R{VeJUgxUjjyUqL?`tR8MKbHfBCrg4;rHEG8
z)9`~V>69fgZ7|Ns{pEsa*5Qibuw<96DbEwc2eTJ|RR_&>{54$LDQf@JM)gg3N0t8`
zEY#iIZB;wpW4PvVTG-x>$lOqmQ!P6!TGPKnbsggRww{<5xSi{69o=iH_Crz<6-rM_
zg}KU(!&zM~an%_^s9Y~t4=M~yH9&NNuKQY!jx}?$%$N{r8X8&RZp%M@;l02Chm*GV
zpn>cQ9qwk_w@p4S?Mw88NQ4rcA1>;eq-|w}-5p`;v&0CU(qX|`q>%Ty6`$N8KD>pYh1crnuL(>|i{f+f<#=v=
zJyNKBA&6l)KQpw4r#B2Ay#Jx29+3?hnq5P;Efdmg0D(TLuYEnr#^oRL(uz@_n;T<6
zQyM4R7JdSl%oX>eZ|Xl!2?5Nd_R02*B`_A?N6zK7Z7DtdbRYipf@j~39#Va{JqY0_%$0Qho9w$F+U
z0QAx>-0vEtQx;qS0RfGTjpaJEREg_vPHfTNY{|F7Yu@02efkmpcq%=
zA)Sfsa=Ny3Cy_0^-Q6HQ!Se*U5gI4m>Yjmldg>@a%j+*a_#Wuf&l(s6iTAyr@~2Pt
z@zBXs-WuqM4$bTGl^a?uUnBS*;ZUMQV%XMdr_R945!#ALm)
z{XQilLm`%af6Ya&q^fFpGra81|FOWQJ*ZBll>zhuKp7~HyHT~d%znQ^M6KYO6}rS%
zM|>M)-u7jauH`e?Q;6L9V*}&`cTimPZOFjb4@^gDvODsDnJh!t2Tz1Ez
z5B?Z(`^^MP=4J;3!5oQrZOOW|05>wO&HZF`q0wn)k391UXgLA+)H0)h(^9xKn8-FE
zb)xUKD6z!JfCA>GUp;MSkga`xvKW^ZaCvyWuj~!Bi3EPSdw6&Z4EWJW+-yDo_)^J#
zL<--jB5y3DqwG2E`B+-
zWi}k}@nI49V^VBMXYS5@FM!zbPp*K6c`
ziwd-eDDl!suDswVpm@zHNwV2A?bC()>A#qK_Z0Jx~3}
z*<$I?9rD~7zCVjz_;v3cPucWtM(J1NE7hVu!U^=a#9wX>n~#7=7iU-c`t>b#M_N!$
zeOVcE2(&L4myVw0y;|M+x(TK&J&by9rjj?z+JPYidU3S$0JKU8(9W}*C^*~S9qt=!
z-B?o%&)lK^l_R~E>GV)EW!0(w?Kv&|5F;~l-WR+Xl>`wqC#Tbv)|Q2@-@~1#St!g}
z?~sFM1|d0^;!^!hE_?J}2|ZM)sHmn&HLY}y!XoM>Hp+>
zusB}+i}xe`_C+BMixs@irsX8;Y=16Rof0vBdaH|NN}lFS9QB_`F0e055#8$pelZ?)EvayR+=!
z{<6JA0=hc>SEjVi^<92p;lvVAZ*xA=AfSp!ad9Dim?`3v7&%t)uB&7H(`fkS&{Dcr
zvS{cU23Z@nDk{^jET`p67~^&Xz0R#9QRs2}4)kKgnwoDk!#6Eo^LYCV04g(#%&T^th>5wR7w(a&%
z@aC=0=`iosP_h`ErOx|I@n{0m;;8q^PfH}@uk$cJX6~MGPY=mv6I#Ok~zP3Vo{6
z!+ApKw9ZD?HTLTrFCFTyU{_F0aF3SPh=Ow0?a1aGmFL*(yY81gDyCa0)qe+8n`Y$}
z5ed^G_*MuSa~1szlUeFco$wdtFDE3hJa(}ivmH!53AQ*17!&dh)B6iXynAWRifdu;
z#juHRyuER@>bP{(9`O3hBW6J@go#w7_p!H|iii~+#-q#;Eo*;vijM=G1AMVLQS1sI
zbkpXdrya7irQc#0p``|;wHSm3vKy8OxdiIz6t!>~t
zqwh98hsyN3&qj(q+{F?Km`#knX_
zC9GT=9F!d#*z>hz<25wPb+|oM>2q?hsY3GIxn-0RFu{{We=9$(59?U*csW%69zJx&
z6EZO;B^{!-nU40{pJk6`%mhT?EJMG+{;$1e0IZSz>k`CV5unw?3z+k}1nO&Jm&kX!
zn$dL3t*;||#s-!&_GHVok0j+tr)!bcV1z@~kx@3}SJIb5@#VrGT!$soAVfevnrxj(
z+%|)n>+u*vOKR6mYhRmJrsueQo#E{y*^aD6N}XdLe6j1ffwo}z95$XRQS0J?gb3R3
zi4-pmkJ3Awf!iq}olh3QS3l$Q2=_n>yt*Vc9P)?JxaUuN&Y|&dUf8)_OpglmR-L22
z*KJW*+J{~g<9QU+AJ#Sn_zmq`VCV{d@d_R7O~_~CY?F?aPrnd>zqaJjrC`zfQN9&O
z*FAKbF-fQm=jUma>=qn+Mc@kU>m7lVOW3J~xz8y2UZ!`wAA7{{cC9&v?i@F;%j8;X
zJsYPR!wK6BFI@wT&6@q}nt`sWn|LiQ#s_vzNi=(tmyJ<9DFVh6I3xWMI)!0OtjpTh
zE7k9>yNd^)0wO@XspXY~_
z*3Hx#0x*Nl!(Jf!mm`$GbOHuT;k8p3&FP~$GfgFsH7Aa)_csz$iC!9dxNLv$xtKFo
zXp9^9hGz+|iwY*|W;`2wlpFlf1OG^04uza?ywkp5*nX^(5svy=Pq+t!Ab&%L`qKm{
zucfuLs{g2#npzhl|5T0XAT>2L`b(le5Ike$Dh1l#v!NF+yLkrmx2pchNRN{99pI{j
zL^Y^Y?6s)=&d<-X!XpfkGZl2&48z4RtM%3J7OE%a%ku3Bc*(DiE+D%tIx(mB`>6J2
zjuiS02QU3`7$u6<6EmJ%$Zy}rKvicU_Z>C(e%1FPi6i4PN+eZRk?uOR%89dD#a#9mBRMoL^w-;`~ahBY0|xNTNNYu63F(b6UyEw!F93}alMKZH`0VDS
zmvUlUZWIqj%v11K=yZq^&sz9u`6q$b#?=QSG(v94;~&Rn<=p5MB6KQHlWnFvuI#Gf
zZ(5zrIt%JbN=ju6W-EybntFPAT3YS^)KYCw)l(Y+BOCQXq#P?W5YnNqa@9*UuqZ{+
zI>eOKR<=LXRD+XC;#;nAYKBsIk9sNn@RDVE+hzvnt2{M~%(Z0oU+!OJXTd3>ubRK)fowSCYjaZkOpY|fv~;zb`w@3AyDGDoRnx1ez1ZQk1Urb;
zqRVR2tn4Z+B-EZqaD20znX7XuYnR**95e#^s7|jxI^QrOU@{(Nd8KMZu16*T<_JM&
z#
z)(n9-xHH_63+D4bw4z&DS|w!OXOe5}PhA*3?7p7Lc0HH}{5e3Cm#P-NGS#iO%pbRS
zhi$A&D1|RR;IZw)54axy%pZWrr}E@?{*-x%6=gn>cD)uU`f_b|pz}G+D!djf1;6Pb
zwNulmGQDMo`l38bm^tDP&Swn$R)gup3t-iXy296Tw=3%rfma1@Or{z
znQTh&PKC&&U`2ST;HtQDzTJkA&ld+r;py-BLaoVe#|v<;x^J%mf86?bvOb4rFL{k&
zgwKCFl7A7Afg;$uGg{OS*%-w2)WzN?Gp6aVLCDceoEJVEiv>$)!9RPttZr1j{UUj5
zRqpVXw7L4{naL4{$kt1^jle0TXw_J`o?!1?x@mP3+2@INS{=bKv3!LtA5H4zY*5eZ
zpfMv4e{$K7IUc)l41TP6=Q!pt2F7Y(OdEk(k;eS9*^d-!Hbh7lm)=*W7q}3TyMVsR
z`mPnWODz&!<$Kxc`J_#8W`fB}P|a{G?sRo)4$-<9)AZey{_i%YxQ(tvrf$Pls*NDO
z`)fMGHnHNqK>%>DHn|A0@PGKAWMXlOA8syGvMj?>(nyk?ErXEDHuA)N9^iQRD_glh!l4lT5|O3N`d2LUv%|ErsEUG{#O}Z
zOGaYN+VCp5vp8)Wq)AKlMJP(o|=ExwI=3OTrOi|GuY&
zXHPhgLx+*HX@rpfvP!My`9R)pp@g({gBOAA{dJI)TLM9q;rnT_Z#6;a*h1jh=mByw
z`Bb9rJqFaSm?fzi_^ldzqm#pQzo`A=Jju2#IS
z`i+kHSy>-ha>YGw@EP;IsQoB8xdGT!Zm@cGbA({enkbtvvS(q6TGJN#^B<)EXg&2i
zK>_cp;}?Xi0N0+su15T
zu4p&zo06u+;EmYd5;>ZE?nbq4k9dqV$MaiErLsU9Dy!+`Ch9g`S!8CT8UJVpbvB1D
zZzb>nHi+HlT}Vr;iK(g2^+qCe7LZ?afLW{rD4HCJ(3hX^1GMqx+x>~APNg-q(
z^>F+uK9s~0>cy}Ngz0w{@|}L7W6>+?m02#F)je=iL=J}*UQq0;Lj<4hkE&fA)NV(v
zpe~mR)kSajA!h->e$fKHcYNe?nE(U>2qppxqx#_s|J8rPkJq)R`?yPGp0Dxx;uM1ZUk3Vs4_eH(rjb>B5reUG@%55_rM{wT$
zfEpcZP-p0gAcvP}a|%#}v~-kdLt88qC3bUGjV?F^p_&XsCEA>C%apYW
z74)0Vx4%re`|w7^#H>~Wq!0#$`$xR*v}Hc3w$nM=@Z+^C5Xhdc!C?*EZsK#^hMt6k
zghyi|AgS_O(ZYXh07m!ck
z$;Y5w;22tcZ5cm&Y%V!!RhvTi7zlXhj(T@)i7J9-UqmOAZ`%z`Oh6hM_;`5}Gp?%u
zZrxt=?77_)wD+SsJzdyDO}vm+==iRm`gcNPF$lCw;jY)6QiX@M@;npsYa+Rz>swe&
zJQb8f7Kk6Dvj5T;_$Bo8k4O-7-|QJAP8;Zr^mi5}J3$;JH46sSpT{73ub}FzJMlbq
zWZ?9_7(`YYAUN82=f{WdbAU?_D9vQThfrwg{ye1bU-@@c4;dmyAc6r}ek_naa{4pS
zU*gq&>S106{Y$^G#~0W6cU|HCAHw<%E&73F$bbD*2Lux+X}|=g88|dQ<^4;BT4wwo
zQIEHn(zziUu6tYa{$aXI5ev(aN27Q_FiaJe
zDuGr`3Tkt8ROSPDv}kSEcZQZP`mtj?MFyEl(JjUS8kaeXdvuQYB|~UHy3Ilu#E4Sf
z^#>lJ3}F#Xdk;yumf`Q-p=SCb#meKiC4L^sMi=BQfxIY{99R7dvttv!Slk$8xVKnV
z?QMoC6};V=o+xEK>HW3Xm;?3CbIWw?FxD8*i>@uuDgDTH(Ns3bIwt*t`@I{UHmtDS
zkExhXSjyx`PL&|z%>CARNj$n-+LXc_czZJ;9@_;z3q{pvr#@f`!YT}t>_?gvofZo+
zM_vjrC%Rgv@RXVP${2iwkiZ(x{&XkDOdhZA|Ir}UrZ{DVV19CG_p7<@#A@ABsw$k?
zmlay{f#^|jy2YA@2ciipkc*7p&}HKMBpKOVr(~@cHCgJr^>y0)Wn8Ar*rLCEi3WBn
zJ&@S(Us%wFs2~c}a+{X0!5^S)3+@_a{4VcLcQ%NnJb4C5)(rz$zW0kH#!i07ip>6$
z`_^sX64J+_E)psLfgU
zZ~fueO@Qo@h@d3qyohjKWSk&xKlrTGcRzlUpkmf_Wk>W%uU3>~{;M-5Wg7;JZ6WDS
zbsn=$fjzP1n|I-2TI$-RBPXS&KJ>0oR1t1+pEFdSa8BWRChWq>3vKlKn>?7kWY(Ym
zgS3#xTPwYOv|W<7+S~H1s@bge1nb1O@WH=qVRWWYj$h&n(_TJ<8}ICu#iGb3q{6h7
z0(rB5#gq%aZo_C0Rk-NUx@NB~fi6xju$hTz=KunpnThmmN@qJzuNxLEGNd4v3&btIoD4qu#57wFQtwFfqE5z3
zSAOztyD@6q?Yc&@aH?1#kH^sAXZug@2kED~ztAjwc$YX@e0~qp_cfg#!cLtyHylsV
z6h%6kuL5tY(u-yKGphK~T{)IYXv{-8jxI`bSsj8NgZ>=+RKOX@mKjh?Y`JwV8HMD+
zZvvzPo)3$xjWv8Mc@sLe!1V{W^Lp17yxOs0MG!iFr5d|M)cR8W`u#Ec^m6ZY-
zUX3({II9_V53RMx*{tH5CG2weuwm@+?bLHYyONfc&JF&0Q9=RgS4iCbQqhY~_;sE-mNFm)4`JaC}C6H&07+;Z#~79l;hpyPZnQqX|JA
zy<3`YCM>&6r}Y^>A-PUwBS0GF;lB5|so*yeivsFz$9W#^bnM++4nx*Fc61^&Y<`+0
zW6|Oi+P{;B_?5o!re9t?%1Yc->-l8}xxm-hb26Nj6g$n1e3-E2
zw6$)^IeAgW4<@oP{nU>ZNxAYv`;4QKwKeO74FxnVLhEm-n5yMYNxSfCAojj6l159VNP!P}=#`C)4;z{B8&NvCJIf1?jD4
zXY+EQt;sGafyX!-O>;N{%G@QKiA|MR;f=>m=;`u4O>S8qauA((clr8}H&-n!h&`zx
z5^3&=S!CL
zPi|h}t1_1-zANB*SkC;k$EmU3ayM&urqbHE@oYPt{y{+Hq~NN31LbtFgWFvecXA!}
z-tt8Pt48>o2WoMHkZ0WC&Awd&E0y5Jjj?t2CbOMZvX`z(<+b+tY{_Z4-)L^~9nz^#
zX&ApGl0GHTTL6k5KcwZZ8!zxn!SaySbkRG^puwBI?w&_AX6f%4r=|{D`_1*p;G$ol
z{yO^P2Ur}I`=#7R${8pPy)Q4r*h4GE2VYvMfu9)q
zze^Wza0prO2kdP<+m?im${|eFS*7x1HdjRDA%)!A`BovnKV61E&Q?o4hO0fZ!7BT6
zgw6w2nAE&T
zUXs&5*yHC&iUAe19py&QmAs}n6^o%ua4*-cD!=pQ#c^&CTUYa|^pXkAZg9VxV$L}u
zJ|1eMx%J%+N>0GRb259v!JT`)N;MIyd3*Xu8~U+Q;4ih^swCAODQ)mBm*+*@n!YSw
zT4jt-6N-sT&+0=_w$$Hzvd;T;0cX1g)J8MJ3_9XxI9}hat!JlnpiR@M*oGf1ntR^(
z>i6%`EPGGorvcAfj*<{%ai2XQCXdP=?|eM<^1zJLJEHiM9a9*Xy~oKi==}4H*)9po
zOK``IKe{rvsNgM=UvXM$Dy@`n!ev^1z4{L8g;}vmMb(HZ+BNx0%Q+?Sbu?}Bip5a>nxVIszTc03yx6rD0+CwpUK0Q!M5_W?pV}
zReZ{8i@%|v4L)JiJxq!m4ZlWB7we5`45NvX&KL!67*O>xNOlztZxjxx;9FqPNo4L$
zyIHxBvSgK&B+hmPvv*=n1AOQVq=QtD>Q$R9u7HYwaI6%S8!eVr^Mo}@T}$#61%
z9DdL~{r0rL@wsAU{|Bxk08^9No8{4(7SQTt$9gVre`U~*XGsxb*6t)BYRS=w_swK%
zWPe+9V}7H9&0DM?6;tC_G)X5^^mXUvv|N;re_OnI{Q%yYu4T4IaPy7z6PC_Q!n@j@
z&yZxN#j!E;0E|5hilc&R@$Gu@qQn8)n|hr6K9ad@}-=F1YKfkpJH1g78ZVB
zK9ZAhtoUPnhgV=gaiCw{YF<+yC!7+jBk15dRsy|bbH8Hf(a=_|SFFMakf&s6;@h0r
zoAP$Y`ihhbNswmWHK^Yl^OcfnY$9Br-kWi=x8kSi
z5gAnWh^&P+Rd1&0mn$K0D7Gh1{tnNXBDR|Df}VoDW3Eq1%f=MkC2KD4tZZqgIqNNj
zng?4+X?(6wEA+6RACzyWL~L(4xINgCk(osCUy6VGQMfdSt7A=u*uLG;@m`vi8W=`-
zgDc)m!KDKtrzyt;ogJUOP@;ET0oE|Fr>)-FQ6TTVk98|B$Ev-Y%;?^ZbkUk>%{`)`
z@Uhi!In-k-*ze$8vHXmodcb^}HM(#5JMvY&61$si
z&O2IzTYfRRfN6Qp@Pi-WmE0sG^rq>}_Z3(N=AKB8`O%{toN(S(Mdv~8vv<-eMTu_Q?~A
zw(+BGp8wwdQJuv907~5oDg=s}u<<$Yhn{SBW~@xwQ|Rr#ZZc
z=CEzMwHeUkDJi6vUpuwGL|+nBtB-6qTcWfyrgt4@<809`$04_JIn75-eiB_=4dvkE
zJ?X*0JSUkVneRhl72oYbuy7-Je!rk$86d;;LrGUiJu9!*ciEXde=?6I^RyAn>Lt2R
zaWQ6w*!O?HC)`*Osqg8^uWV2o(mb<|a^CHlY70H@jI@s7=PiD#yEm0>Q(lyk(-#t!
z$u|Dn0Cj6{daQY_db5?t<@@PAS8)1yyXS=WAWI(^WGzAFU@BW|d3zH!T1emY=8bRD
z*&(sZ4{R?8MTP!ZqYwjAB8zhE$?CQ!5*F&yR9k-QcsY;FdnPT*Vk|$+TUOS3@aBe>
zY0QtF9NW!8fo{+`2dGsu8g=C
z9_lqKW^Jx}7~lY|)Gyq_!l%;=M`12fC&@x}*HXj6m$Yg72AlT6fTMY-{z#wA-kfNf
zdT(i^EHlyNw@T7R_wN9zAwZD`l2WtS$LvWwohpU+B3{)}RxS((>j;}R0hv!Z=>NL6
z0Ryo^^&I)Z&Q7sB;09HCITvSCQk9MYPgyskVJ^<@vj!Izr%m~
z=Kq)T>bx`<2$1vh^8?hT%xOo=SiwJ6-L}6rTH^@Ox;2t6`%UBHN06y3x~_K=0nUH*
z4zvn=T-F~;clvd2T#7RP4diPmHjMh;?h(+kq@IXE>Co3uzIu7^QV4D&?ZRtfZO;zN
zNcoOSdVoRdH+P8hw
zHg_#@2K=5ybmgN35sdEhrRT)!XeSOq!+%u7hm48{N8s25vZXwb>)*eF5Gmcdb$lW~
zK41%}$8q+fV6O|lH|djhH>dkq+Px4>lOX?+KPQR6h9LXG9Qwgp8=d?>?O#~qF~Qyv
z4b?^&*_nq>s+1Msuv?8|q~FEKo5qwHHkeZ1UYu>$1Pyt(!si?4)Sb6pS$&txoUGE>
zhg}HWz493aqd`I27_6tTolRz_Sx=U+cMzDK2C+sS*gTNfhz+4%&neSRGF?97Dd*N@
z+Y!UOc(z!AgR6Dtu(K2Oc3hFSW`5!n@6p7`&@b1ryUV(#i%TLWHF%6OC%TYxl1i~?
zneFjiOJs{BDzphc_IJzP`3=Qt?R(+OHwhX#&5B-?Zjn1PzN_;SD#PP8;tD+mo1+J$
z)dz)%6B+p03s*i&9I-d2R^bItAXfQez}_LySHc-d9XuW7B#Gyqbp&QOh4q$L_~Sp_
z^Ug2d;BwUXjU3_l7BM7Wx#
z!naPyB*ne$3pKJrl1fdoTE^s8(bv>@$9Kh^?mm@AhP*uS
zJ7!X0MQjD}M*XXm)YLlX`%|*(Hqj3EG&rK#`j+*szGY}9;)l&PsOEl7;$KfRV_`4k
zY3TL_iT~DE9-NBVyr?7d_|KzCfJZfifG0`}x2kWR_ME8G-S7A=R7UncD^!_0oG|e8
zO!na|(>XyQi;5yHx@oPy-j)|dyY-*Mp2ydnWV#4lqKuzH=9B9Ta8lwN_DoUFE`6SJ
zHFs|;XjOlXt6CmHk7ywSERUcTpcoh{QiS%*cGv4|I=AL2mAGg_2R&m
zz`QT2(e1;HbN}iVfdJLn(Ai_Do`pe4vaH|`oZ9+t$RQ4a;S>KTz@m?C^L+oP!tWuf
z{m}{DY%G%N|DLfBH0bxO$r(xXzpkH3@DUaM7nk@y&+%lI{l-wD=>JfYH2aG%^=qCBe{&V8S(iR%7jL}6!CtFcL$hq0
zU>u?W=WD>hhvh9l2N$O#{l)x0Uf~_g=-afQZjJ4RYgmvq9$7)ObGHDwFnHZuhWFL;
zP%Gju_(eL&e+fRN{>wCPplzmM;UAh$OHYNf)POtDzu{?CqqE!(Q93q#v)8)ptI%%5
zv$mYV9WJ8A;e4-LOJA+v0r!Jq;sKgn|w;?Q9I7}Zl+I;h$}DxZNR0D>ZuxEPe(3Y*?p9P=-&fN={r32?k11ZyzE}*t$Yq9^%}`5K+lulTh%^w
z6jz5UUb>T7YJqo7ruQ2aT*%o9w>ZS;|4W)w^SxppftGoY9Swx#Pj!L4J($!-|5}rz
zv$kugDwXxmSnR6JL|E^2Q$+74*R-TDS_}vn5Bytmm0wfRICVE$Pt@9Nt*h>QI^VPL
zTR61bjeB^1L^18Hk2l<<)coMQ7{JYMAlgtXP2{%Zh@J7dACVRF8dMd$Aii0Jj@GC3
za1RD3}}iAep^gaMmsX4g{ni=hIvD@=9NvE
zc~1YpX0%YYcD4k@NtN$<+0t%uw4N=Y4ZcbsTPo`pBDx$26+1F^@w^~4b?|!Ws9<+(
zGVrYJMEEv5NvN`mwN^YfcOJDC7@JAb!^)7~+lnp1ZF)}-j~q~m)ugKo&^#1&9)O85
zzZ^(dDl4Se*VZ8qmD7mx_<9W`@}LTFOFQyz6T5lovliQ>7Oq!eGBHkT-0W7e=XS)g
z(G!*=M7KiCVsk6lVsiLMS+(G1g+YVpyiaALcR88%Cw_n#2I;5>QEDGY4D`;!quOky
zdF(`zbkvZ+OSPvJasv$r4U}KfgLDGA@FS2kx;2t&$T7S6jR2V2oIY+c+X)!HmGe^)
z&uN0>9@V&w4Yf~T-Dm3jHaaPjEUFmcNlnZvas_vDDY^3}*P)T}cZYU_-Y^4%$mxl1
zu2G`(wHWP)+FZ#`(!`ciwFjIRu`CsATiY$lit_qxKW7Nxb=~(b=mwSU6z|sWX^i~j
z+NhU;f7V%@hvA47SSuUIR(>&c*`HVDhl`ML9EL8IwFxL1IBsrgqW28xwOnWYn}<^a
zG9%ALUjrl|4Myu#|K?AIeHX8FL&buF;N*JYP(_|>kw%lrKZS^3xbJT}Z-dQb@c)-+t>2X2ED-TL;43#ujEm_Q;)EwEk_)Wj${uwOuV1rUv$QxW3|z1okem%j
z#(rdUS&NgJOLY-YrGV1y-r0}bysBB(yJHgT8D2_aX6rhRD2){j{U&ILpn^`kS$+R1
zwG7*UA0Ej%u_)^`blt4!<9V$$-+CHH>SWd%*=rGs)^xVZmbfpi;XQ9k0Uu=Bkr#ID
zxvEi7Br_>39xrryVepmGQ_6GVe@)se>p34Clb13rje~`N9O)DHVuKc3Wzco;0gx34
zhvv0V%Nta`uMBd*3sE69_23uQMDmpb@uIl)5faJ}LDKZ#)TPx$73$Zbpk~`tvU#T7$5YrE>X8O3&yZ|}=r2g!k%q?;
zW*Q!gGj`Q`#Q7bZp@vCRcE5|&Ro}m>^AfZrXYn{4;JwADs%hzBn~wKMecqhsjmk_W
zL~px3N56P8-P6j?mlkhkmw7Vh+Q~B>klLF?Nve_XKsZpic74sl(@@n1V1i0fs`vl@ZYR)w^!F&4;LEi
zQiSQcMrl?Jmw233pq4Q9kF`iI-*{0W1x4=r9UNfC*t146J}AdXk}|E<+f#S3BBS1M
z(>5;&dCO#6H@n^Wxzk7(qqoX2;E`mp{cR-i0;m751*^p$4Co2d{bGQ5px=9+{
ze8@`3cp(pm(!*9a&h*Su3I1cqI*PEn{K}1j&Di{!uQn)#{U7f>dBVMS4O@-3tBYrf
z>lh4V#F#w6H{SCB_s@L?F&Q7I@{Z__DEw*@Hq!LvuQPZ5P)as^A8aWrN;0C57N9F~
zJ)ZX|mSO+y#@{kh>i4+OPnzF~4{!fJ!p=G>%C>9!C@KO1N=hq;G)PMg(hbtxIdpfZ
zNDbxCjdXXn5<_=McXu*B-dY%ZRky%hm+%P=8@nmqQDT`V&nUF!bO
zlGOBA6O)WhFx3gjo$9%>F}=b%)Xfeot9t0ja;X!5lOt4?r$i9
z?nTF+hj@8iOTf)hA$zpG1*9L{ggTUW*8H^cE|$zyTW;bZU8RXiU3top8J;xEmnugF
z#CoLx@moqECfmOkJ`Zf0RQehp8iu8gsdknN%cbH@0{Kfdltgbr#YK+oB&<}ZtEl?g
zDY?w1tc`n@GE?3D(RyE;o|^#!|LI3#IWiFIQ5
z(=x6B%Scm#$PwBuuiMXLDdp^*`yE&1h)u*$IO(~sw+z0t*SBvL5<4NeST^wE5P!#o
z*YNS6uMq=l)}U*Gn1p1S!~8N9O7}6SZdj@}LjK*k9JzMaw`Zq#6Ty3L#cjRwR>UXay>%1aHfFaAb;c8S5(VwV;~Q?DY%lS1b~cCIz*
zyJt7nI(>A5kgxKX2~af-MLuKh*pql3wAHVc!Nm0AzIt`5Aby^BA+qaRF!_*rh1#N{
z*?5tT9-I?H3zKy9?f$m#aU|}@W<9mKyKdX>N{8*~HPXGbuPKy_D4N;a_1?j^9+Z0C
z^bJM4#b<6sdUeMG6I}I#i`r)N>wbfxXy9P%KE^Mze
z&rex*D>2KZR5~3;pi;{hW(DAS(q^ZwBPX}hzGPk9WyEfaam-!6lE3yzmOQi@r=;*0
z>;C!;FJH?nbZgA^&nb?XPlYiYhHNIMTR7Ffb5NqzI_}z5MupMdzw0jPLMoXvr5Tu=w3?^wKA92hhx!=!5{*nx;
ztNv{9r&gzOj586Z)z!ob)meY#
zDy&%oE0r_p2@;dx7CXBWB?OgeLmzPIlvs>?12WVV_Y7t#8?pIA1NW4HVaC_`>kZ%M
zZ!pQGYu%5fNjugcSs(c9K{gMJXotc>j0fBN>674`
zqQ33HeK5+GS@oW`M|k*F3ehS()|ys9u`+A)QlCV4LE7#USV=Mma?!5(V?>*}tE7_!
zg|{QV?mezrvM9A{R4`x0(n9N@n!&3RvX>M#Us_l5RWma6mBaVmrgZk%9t
zFvrpFmX=`EHIfR@N$=6z!Dd%>xXD^3PL_#j8ofSzjob0B-5~Hy(M6m-ippC*xo~s$
zs)D)}s(Kxr?8sUz)sV6(iC(R?2e$W(qqtHBWi@X}tf)OJLfA+3=<}Zc#yBo%)%x=H
z#!U4s&s!FVsc#;WH}x3(X1osJ_G&ouO1^7cAI@pE`jO!CLDjA?wHRE9gIU5|=BL`*
zfU8m7>@`!hN`UjutNLR-A2AlvL56XBr;2)+3Y7S@GS`_R^z1i(Uzld#P%=zFv-5>t21G%-`yzi=eu
z+9dE?gw=^m;I%j86d9U*I~q|!$a`Th=fP
zHoN{O?kco>VqwW`oB<23YUEcoeGNUxS&{14ysEeQA`S4n{1^+~oRln2u2#u0d2VLg
zGbeNmjhk9(li)Iiy?+_*88(nD_Sb{J?Q>X>-#G&1ZLPs#8?Y>4>9${Qy_gav`SMuCb_An4C#
z%Yv}s#y#oXhFf82Uf0#sO)BD66uvI-(P>4|h58-s&wCVGOjh=ar=qQQj}{fUwKfS|
zm7}(64rs7%k8mRTZs^v#)B>FL|J3jL3FneE`Ch*x^Cff>dd%xsBW@VX>)&!BvK-Ncu&c*G#OfbCxETbI3%bb9Wp?MOQtQGzzzJX$?)
zsz=;=7&El61$A6&6g^AkOfP*NVjgiE-WHX+tz`_@bziJ|J&&UkrIKvH5-Dfu9DV9^
zKrf!4xU)m+w~gfEqZFXMz-s#Y{wifzv8FOC-Szu^6k*?xCTTYol1;y6eCM&gw6XRB
zA>kp1;U#ME@yORwt%ZDyOB<8Y>l-CXQ-gW?+}4Kalz|4`@aBBX7+J&`!SKl5D~z+;
zDr_%JzT?(vOOUs-{$}h7ned|lit7%Ud(+cIaBm}bwAR%sIxuC(ko!>Sg#GO9$}J7@
zY>r!2R#iM|A5cWDjaZTl^X8E$&n1aEF47cgaEHDDI4E`wJ)gX#4muOs|FK18aPz
zR@L|Aa{AVU;llT6c}ru6bvyy$n!pR}*;L#2BAOmgL5yh;H`ePYnJCWb7*SYnXAnW4
zh}QG%#PaO`wbQaW{FIaPBW0-7FFzK7BWgWkS}~IU3t|`kqVs`N5phT!XWXm78bP5znLa2%0Iq4X4T!;8-F-yIPh{s=bzixzajcdLrdLA+ww+A?1r-
z3@gugK*^=D>J+LnDj;jGZ8e1tRq{%l2hCq>>!S>T%vyYmJIwMU#~q1M#Qj9y0%^zB
zMOw9k#a-a9=-Fhmon4&%fx*0XK!W!RcP&}&Q>Li;^;3A4M%!jj>b}$*8{nx$s^fJ_
z#{cu)u`k&bA9l!3tEbY%RK(kCa$MJyV-s7t9Gc9Y9P#@h*NaZaJvzD_%%?24GtL-d
z*2JpVQV_1AemTyIj#Y;K(NZK-`-5$rFc&|N9jg=8PsWda`*RG(7G&L2B5N-=-7Cp&
z#|XeVK7sA_A5Qg)beSa<8|&3Pf)3?j_5Md%bDJ#H(|bqn$0ru@uLNf3dbqsERq83>
z!X;RphexA`22>m$2nl}^K72S#-B;(`$!Sus?A4tbw4%#wo*bL@smYgY8Opz&SFWXQ
z{*~gee29(9P$Q`aJG#Dr8|P1j)8k^ElatXd{lA%P=GrV#BLcElU`eUjkFrqN#jAxs
z{*n$Umz-I_ZKK0`ht@I#gqxC@A64t2R-PYC(%VNlo6IhDq#ocJpE}EUM@M_yD1Igm
z@mKGhIFXXKzR|m|Eb+347r24ztEz~BLpqE%!^R*x*fCCDGH5kCMiEZ5j4I^DSvnHC
z;~bEkP_5fEaUoHI&Pcz4J4I?J749>}Xc+T*w#=~>{jd7|8C#AsVj>2>w=u0;-Bs;e
ztEA1tzoxzoqupO#R+#O&-1p;Ebf}2IQ0C-R&_A2W#R
z;|BKhNC^urtaPq6LP#W~XP8B?ptW?ypPh2E?gq^#ACj7MZBR}|1c^rNZwzMx7X^~&AqWaHE6**Qspso>v6Gk&ZOAILpj+x0Lv(5*YkB0
zez;D&lX1HHP)dvO9)&0}&aOMIo2(I6c8gME*)zIwuxU)M
zFcGY{CwEXp-s!k6uN;pOFvzfoh!(9gypy#FF~m^D?a#Ijk|#bPuRrm9mQXqZN{={N
zXFv@7sB*hgFRZFQ9_=e)(1b+9O*Puj2;C7i>Z;QhXbcM;rXO~Wr6+PgwoOEYJIt7&Mb
zI(}vEFr*V$qOi?CmT58iJn&bO1{!4PjG
z_(yZ0PQ@pqe5bh@9I#RHxtt|kK?h?ujEq?Dr7XR?`-HmFNt_aae$9M@Ns5
zLRhn_!1jaIV=K#jhn8IfsvL14VAm{i>w8Gz%tSA?b4BE24)6<~ZQuaxO+6Mm+}_
z#>=*uJ8bl&j0Vn`Ry)~5^~_M6Wtv)_;3gBRw?&i@S+=19xDzUbi)AmRLRVOIKWkun
zer+O#4sU2^Q4-_8T!m)R@2Kd?ZB)ytfRkK$2i!%VVge{@n)f5t@WRC#JEJI86)sn@
zS11o(VGIk9>gcCB64Vq~OY!q(2E!CI7y>>UOXIPc-~M1{vAO+(GvfK0bxQykeWyOP
z<>=XQ9b5EheWRF?e4M}}WufkG@cPE{rg4Y&ya>(P*z1hS-QSAlk6TnMJ={X1h2dF)*0^Z2HT13U{yMP&N0N+Yw@o=4UHIpSeyX62ihs6jM
z^qBb8;cE3cO1Jrk5teyTB
z^XIj`-!F9%s;%Dsv)X=w#?G%+u`3GN*ynVAL>1Mf_^Tm{?b(dY*jXTIDy0*r!iY#X
zPxq!PGpZN>VH=0`DOy>-X646!ZX~f?mMj3^q!wtr>W61WgUpfunAM59^vdu5JOV@4
zq{(3E)?8x}+u5s@_vf0y6ygeBI*H3)pki7-cyX4Vk$}f6#`11{Vy^a*o6@HL^$*QO
z&O;}^j&lg4y15R)41M);7WodpN39owYoRaR7pfHioWw%#bB{iB83^g|_f4L7#S8eA8<
z8}YZu86YJ7oDZVAol$sbkSz)B^7gU{;zI~dX4MC|hjnZYIuDI?-2N|nQRlxWt@u9!
zBLCmu`yWO9*aIl226zS{C2hyRi=J?Ce!i}xLw63#r_3jgQshc*Xt>!acARMPvV>0%
zj2%c2xjf2S3(h0h%T+COG=an6zyxwO-vdy4Wso<2`#h`LPX>9AC5)n%
zvqYy@%`NQJz6BQK`4S$I6f`xpL@|G>NUzpro`}QZv!t%>!ujr0p-Le>Kt;pGZYvbz
zHV{Cb%UM}nEfmQTjRwbwX-Z$T*6kmPQW#0LHg<(=UuSpMRYw@P5-ct!IL~^7DvPax_H9tOD*{ERh{V-+=dTH;JJY6ggvEms}AEY~6nz
z>rFBw9OLjhg^mimhnYbfh^dAmc0Szabt}IMQ@xyS*`;Vdw~FOx3=8MiWOyYiraYZv
zTAVzl1xjEwTxzzmJ=^12X$@B8eJ`Ec!&m3F;>Qmz9h4rF*1aCBgL{%{M^e)Hgk?+3
ze{}9xBUd4U7E=J+oN=J|lAN3z8kZG9z-$w}KV2zatQw+72uT0zA>CSn3T;x&DZH+b
zQC_W{yZ+;5*&zz%N_zpvsz5H=1*;3WnBa{zE###yye7$$<$YQry^%ME9yaZilnA<}|IEo$ak5Zxx7}OCQ5X)HZ7wzL
z6^N5l0(a-Z6JT6a-vkePE8kqn!{K$LmF82vHRjt@bvjUfsHDwIZEz5RjwL3e4xcSS
zg>vV2MMmUTkZMJSDb~smb6MF}bgOg_$*#X+PPrZDB|b-qkW@`^Up^z8s7|KC2b&lh
z$Ls7(0#%EEh0u9_hJ%^;us4Q2Lpg$Oi~$&}ii)E^9r*blqX>Q~bTqUIuIDsZnw}Fc
z-bfvoF)=dAX350Vr`4aGo!#DgNolv*T!$4hG@DQ;O>e0@AmAp8D?o`z1%K~K=bnJ5
zR3r~qIN9RBAKeLtvb##sO{JCL&gvvN-+uI9huDfI=R1pzr8^f})_l4Zi$}T9Ex{CE
zsJ})udx46rylmcSe_WDUivXyht69h6h0n$Spm_vZ)hKLk4r`5XehvDGL{96rlpE~p
z#nW9*HBECm4nr>BgXaI>NbKcxwdw*JF_=W22a~jJ93{q44iIzfZOjRj0myJmg6E#@
z?kc6aI>u*ttOFFRv2#uCY#%@V8Fm{3Ub;vOZr3*3RdegT)AZ+#*aMX2Y_;67>Go8PTUsNs
zH6$j7pRk85VfQ_e2Oh?qAEeFQ;Rbcri~WL(EX9md`h=Ro(zn%^&<0=K=B>twhXi?R
zTN;6udQ!E<_tn;ZfdkMI0Wj24uC3-zJBAi>1WPKT_|+2Eqwg1_1v|22WGPd-p?X
zmgYS)*4W|(`!$5F-#vh4T;D!Ut@JHj_>Eee&jT|?R5o2X@X
zj_&waQmYHf5Yyp~t2n0o6S7PSxmIZc?li?E0O|p&rDpGiHEI%wGwr!t_RoTq2ld2Ab25*DJo(!
zzm49Qc$k3z@TAh#uf7-^BX)v;zCMg|40AYu`;e5D&djfRNvFV+7WcAUNVQbg`}WFS
z*b;E
za_P;nhnQ1?w=T94mpoRSv{*_C6FzGLcj-Dq^{teT7>ae;f~nJ|gXr3!@K;pt83qia
z-37B_d1_zO4nI!^@z~DQ4Kcf>-tNy>3wR&-j=~5jb8PTgpzla;_fCy;1g_i%P(~(j
zHt%m5*&=bdT`nQMuFxzd+mg9v$D$zZ`sCtrO2gIcE`r-C_w_9N;J#LZb(1SZqY;*O
zH8c28GcR{;!~_xR<>vSKT~K&QwdaCkNL025R%=?B{zny0hu?$W=b4ihe$Y72uf0;j
zvE)A=kx%0CVrxmUSgy0zqarr^8cAFl9reL;oI00RezuIwp#A>(X6>_bTpWNes-sGz
z#%
z4B^mtj3(>yxXcj{c*tIRv)*hhx$9^gFXiPZmiD;%KR;FMoi7r&7$I`S9}1H#=f=HXzegUw2_q3i2wPK$Ag
zHCbTRMm=OHqCdU3;B-1C<8jJ+z#Ix~RZo=;`7mZ02Y;<5Z5t5-Fo^k99`Q7R!wReyTlhbIj4x#Yx-c9KDw50r06@CK(QI_QQJY*>2xd(p
zhvn$#7OB%Y@uS+5v0V9m*||yw{~q_1nQBX1Q-v~7RE2k$7J$=wn1SN(v1{+gVwiJi
zoaEv4rj~HoME>zhsn78-ktQG>9qtg0YkN&`Sl)Fx=j-=0*AwOoaNO}~+lc1PGe)ce
z$6K~y?<~nDZ%ts#I-DoFQ=$fTPVD4O*=a0!-dT=~6*JG`uF5kFzIxxH#SKa%(4TBD
z^czO?f47axpOH)C@X_ys2`*nY-);l)L1XJ|D#iOLUyD)c%YdgG#2+1u3ARtlm8yI#
zo{Sd?zDkOaPx*r6LT=^P-%QL^IGy1UfD$MQLR@5Zb$(}k;pQINlFw-VYd7-{9jgH6
zrOVTQvZ)t6PLG*Rh;my6Kr+>CV}jnl
z3=LKpk1?L_@*&P2ooDrvhQ#HbrI6i-^y$xhiPIzcTxVjG(e$Wg@99+D5a+Khb}iPH
z{o_4LKgw@J;^97tEA0baTQW`#H<7rD%lAH>Zk{vosm#q>`Pq3EOT@!wY|ap7i`v&rlzK1VgUJq7Y!YqHgBMh&B>FkX3q@Gk_MKc
zCP-7HfLXY?o8f?vVvM!R-g{~2=C`G@#QRx84j^pM{#p?pHh+t&tU!wPDE|at5()cP
z$w#$B=3!QDjtGX0=9<3~$XxuFO~uKG`~7v89=A`2!n93*cP
zS1aw*P?ts<*m*-
zLYCTvOv)*7?e~x0Ks5)z3z2yBrL@#G1fNkPpG<|*61O~PuoM{uGZX@uskJ3f;n@Bz
zwP{O-8@2w~Pc9FDEK@K`0(+Z{O)zvS(~(i&aX3{{EK|$}vr`LEji_o5mgU}(xUhIWfURQtW)^~Jm2k&;0Fo<&q7hltVYooA`K#{*UQlG1)r^^>}
zb4&_1pXn1!>0-LFo;tw8(ImZH^Jm5^XxBW8&iZ<2`=^;r@cwFP`J|TZDaX&N!=J}j
zJxw{bELmV3G2bR@y|!LSMyx^d`}%Z_l3QSl932^%!G{jO@e(PJgwnrEqs9YXXG>CD
zs;4L@ND_w9gLU5;ps{
z3S6cY#|pUQKkNrMB@hO%g?JxmQJ5fAwfW%C&xD)WkesN@)3Xu0P8B|bUnN@F2tM-j
zele#`@)*{s0h|#PJ4a5dzG>47+au;#o+tT4D)@w!UJaoMgrqI5gG-22kaja1(DE-z
zZf;Yili0FR28<@CEOw^#%kVd>wY#H;)F&kOD^HF+Bp+I8Jf|H*lVWW#Aj_EVa!DjO
z>)Tz77dP7{1p482=Z_|0#@Ti^nkqkV+`%n1$K-?B
z8Lhnnj(sa8Jp^E!$2(7FUz5#11}9zTou>d2u1L#6wgK2)+V*@!Mxo(c0Yjc`Rq0fk
z%7T7u4W|n?-JWfaIa%aZf>Na1O+0d{-Y#_y4sP7ZD(?fxCIbV5s+R?6F)=1L`D)Xe
z!f&5ry#aha61%Jn$wDluDwus&k@-H`%)=~li$iDF=7BWr1T&sh?T!u(Kr}N%Nez+R
zt}iPaE)waP!KB6VXbgcs5VvC&^eti9cVd8jo)U`RDX*Clh%ksmfPI(S7EcIl2JTJt
z5Dmz1Nr1g(c}sm~TwR~~P_uR@B|O_Q+dLgbp+pBPC89aX*RPIA{~%qcO@A)@`P)dm
zm!M+AC_su_)t^%>IPnhq+Lo;`Om%qaX=`V}T1y)yDT+;;Q1;LF*o{}=F&z?ml_PV5
z>+9RccTr(PQ%tKAyovGAcjs6|MSN<;7tcqnJjD(fHVI4Xo9+vF!W8SDc
z&qQVp@`q`mD5&FY#0@w*tq#URy(oj;e~QaoRb=g;Dd(9M@iJu17~nvJ-QoQK$H#
z+@Y7jaovO8;dI>BMbd!pn+fsc`o>Ov`}>Ycg+$Y7R=88b+5Xw`qa@RCFRO92scRV%
zqhZGE_P2Kd-d-CkUuVT_?gTCb=?rwmI
z#B89&`(|Tv^VA_mN|Z`LK>?sTuE%V11JQHD(p!MCozA0-00{6(RU#buKVrv8kTMr`tDM=#si=RV&qf^yrZ(Rqs{*!vNC+6|djIPpf3Y
zQRF9wIfungEV1a9!jNdNBJ_OVR6IPIYgS9V`)e&~nxDsJa-?0Bc}F7em}3!?V|NE+TsgaO6swbp6_EEu(v=sKV}2Bm
z0S4a;Ls_VKk%PH%pHaYI>E&-*a$d)uwZxwfQ%Clz2QpU?Zarr_QUu&Sw{CKBn4;8F
zhkJJWGeCQl>ySZz>si%~oMDXwRbUQfePaiOXcMS8UsQ_XwF)EIP#zy2>&k=R#vwNC}5rQAfA=XzJ+TUUb!0*Nnvv4VMb(bFfpgj9$gtsH2=F5jwC3zs623EtMtJ
z3JTFtdi+{IO*
zvkz5$R7s8&zCZPa?kG{E?bw9Pb@Tf;+F3VG&GOhKNUEP4WMX>%UImO!FTN2gubO<0
z{^G2!vCeT?YfMc$*ljh19iO-`fjoU8B)=bzX5H?le{sWUAMQ$165*N?Z7^b*s#v$$n|FaJzv=Dx95z
z%PBVkykH?G=`J4gzOQn%PQ9A~wtJhKYCtfai07HzES;pXHDNv9Fmbdx0D#BWbfWM|
zM=#mboL!!Onjj!2Ka|L-K3#7V&H1i}xt`M8M#-2GxRxGK6cP3LE>Hntyj&`UzFjCdB?&5P+h%>JKHbjaq
zgu6H|-VzH?kC5o%DWR$*nsJ4bnqEu{llj#%6k)Lf1lwbVa`gWx6F#ulG^iZ#k)9H1
z-{H7roL4v5e1d-Ybn`C2&@T4zUmXb$!;D3|wh_%tYzkCN5(?LMD(IJ5Y5^L(?0@lK
zcF36FLCm61Rkgg4Sg)WSRluVGe0v=gbuGBLX=7)w5*`^i{wuB1PR()swKR3gm8(+h
z2Y=3DspaDuS%J)F2jX0fVL(0fCx3lwP282BWHwxd?zNtS*LniKGQ}$`Rt}Dp4gGJE
z0zqCXJ0F0%2z)JVJHt1<_=oy$
zuFony21I|gwqJ|}fA7ne!jGe#A8kZkQZ=iDM8CV$qUB%ojd-O}-A}b#=bvSaZFlnR
z98J9cB8Z%uLXRi#Fk5F2nxNVTgHSt>xCpTM*#m!TbDa_cw4agx9Uq
zvj3i;3989`lVTnN@X*>GYN|`69E>R*#=gFQI7P9}rh{v0pUF@`lTjS{pjp0qVw}>&
z*7{>^#<;wb4y)L|5`EzdNI9(eLoAsbMvZzc>7l%r$vn3L%oA1P@NE(go!kuZY$@fT
z4KI)Uh-W&z459wD~E0v*jY4}WWiy~Sj*_=gQDUk`-i3oV(dF|hg($P%fnzP>~w9$si7g;2e|zFZR!cXQW*W4^--CV$R-4mlMp_GN9DzrYDm8eV(f
zw~WP<1wU#NN^xSb2*3nNH!7%e1F6>X&Q9>Gc~7)qQu?hFP;P&D149B1cf+-C^4DbK
zujFJbmN+%@VPg~y)~g5WRs07PKLftJw
zB{9CM4%=Gdm<_dxr)uXND}kMPjyC-26%3AMz68G1(F)Y{V#O4Ir*otELC~iNY+4tA0>5tRT*wmh#5vq#>qR=rp&S7q@kXH#Cj=26w7wMHd&Vvegs5$gb2#5Ovv
z5#*%!UlK#oVpM-I%czko+^Lz)nHq5b=l9v}2>4?Vik8S)I-OMN{cQ!=o#zAX1gVSw
z2L3AAOPpPyA_q=6f(?6sq%xP62c1f-vxVJ7k~%M*bQnBU~3K9{Rg}
zz6$+Y0&j=+?`I5f7yeyDvHzEI1nqzQELBfY3@lJ%lbd{J6EX4Y(}zWU=|%DS|6P>-
zVKn2XMbAQ$nOg3>>wWg3^3=O9Ct58w&sjz~KJU(OxBps+_YfSZo2^4U4*Rj1h0S)9
z_p0du1R&y9fC8HuIjD5<;~mhvi#e@m0KGUJDdhe({O#}MDFAkf1S}0FmVEj3JDJ;D
z^198yYa8vPDM=UW)T!743pb_v*FSS|wVj(r=DEiLt^6&lr(-bhpOae0JKpa1_&qec
zN{u68of27e0d3OKd?xY19PtyaVd2UK`WUGWP};6)CAd4ltsiuLj^N^2qC+^I62a@$
zwTi0q6Ce-I=2h~(}tN*!Fv7$jejmvkO1Wfe*zzP)>`8=T=PHK0k_|Tu_AC1xV?4?&m(l{3Z@&b!}Lp&ffl?sS6AQt{Y6DYj`B@k
zjKr|^QvjZ(f;S;)phc3w)Fu{w`o%VWy}2(Zkrsg01UUP<%jF*mq`RMIwgF#Gb6~UP
zRaM@q8RrLSnJE6xr`Uj4{1ND?x;>U_yTA@UsCW*CXHge>4^0H8SUeh$0R5HLA
zYA1imnJ<`TO0jC?QVWIx<0{j)#e;=6t>swZ$J$$W?WP#{b-{(Fl*san`$?oTXQ}BC
zXAhYqQB5ENq0`_529n!pYQY;+8E>T@0VW-lADxHpWVUHP&F1$w9TGfQJG5SZMq4V0
zCO3&$%n_v!YTD#eX3opOYIRoqDpmy^cn)Y%;5d
zXOU+}^J@iQ;-GwViwo3c^a7FMl8`JFPFkRIXzJEAmF3zFG(>-N*^6K1=Hv6~k7u!}
zaIU*}2|W6_$kofS4E^2NE+JmdqHL%WNH>+A2nFG4S9m0bVUFFYp5}|-j;Qi7IU!N~
z_uY$Jh2n4j$(kw1^-HrR=4U5IupDL2_h;5VOtV+YXL%q(sm(?gWAl|rxIMm5Y
zTk=u(A}FV!!qL)=&E+ZFfPdtd^>-l}le$kMem#qABkp{bw>WuLR_LHO0B&r6*S&U$&qKIW{Ap6y+E(Gc8`nfBfTuVuJ{WR?lDtJT;JxAiIDP)|hl0wH}|T$`d!;dT@=W=PLh7B{B*
z4A`a)e%NaU9Cno!N#ltI9NwMnJ1&Jbk5(vHS>%92aCuRJN?Wg)C#@9H-c{NVsOqkG
zR!)yT*ZQd*w2kVQsq&immw9;;MvoI?Zva*M`vK`3=i}nYT5esRu%aBpFc=|*KhA1c
zYgw1)%-HTD%MtGVU%Vf}nnb9grzOZdG
zd~rS*3isokhOpG~O
zzeR4QuxwKoggrKhFCG=&LZqpKU#skKBF-;~C67CKm`rc(ijHd4!5a)?n9onMsfNfu
zQr=o3NIkUDitj?x=1oRR{qgfWQhgB>vXLF5*Vei6j+rK?iVQLG7R)9G0#kv$miN~Q
z>qDmzZZo0#8Am!`NvjOLke*Z)_pdKf?rUUs--cyP^yuAfdwtm1bJB$$O^wn_oi}~K
z`R;$IUXwy@C0@%IvCXxOFpE8mjPR%T#J&KH)i(1<8rbd`ZtK7$f;2d#MDSv>YlDyl=c*554qdRppA`4bsv@2k`Uh)~C{!HXJ@tHe$D~6)nsER8|$3=?9S)HOtVe
z|FO7j4>b+$mNYCPp51h4s~81gSRo`H^zmH-7#(=%w_qn6CQD}2#R%+eJDA7~+?m6}chlf~{e(wKw0Fk9
zXj|d~liozGrPJc;a;EwuRvHh%!od+a4oBwTkOf{IF$f-
z5yCmTBcLuO&uZ(NZ&~QY2V&rQt{$$(t&GF_+H-fRIMWKCnmt*qq6=kx|KYAdn`eFV
zjrZK8xy|lo`8P>ng_-(hPJgKlMHNH+Fo&ouVZAJw&+*kCwUeb+UaWqLN%{>FM~963
zKBF=E@`2ZNC*k7o6P^f=X7V0VSnw5x1CJ~F`(4i&tf#%l+Hk$B-0j^~9CIlXLvm@~
zux!sWqmf6n!9GW;4U<&uhuxg2a$pqPvj3jOqUY
z(|n!V`Amqm1Rr-x%T3$ON}wf=YI#4(k%(gw%)a5m6MLZU{@HKS$`^(AsfQEx@%XiWh!ZOw%8Qo
z89+wm;c_+$3*>9{=umeDpDx<@d&P8#X-h)z8S2e?!*6)ixvh%GQ1_BP8Gei)QxDP1
zcqjBy*wv-=J7QMq7FB%|;e1CIS{Wba@A~DobM*G~_qATvAE-Tx14rj#;t8|Ik_&D0
zMZmHWh3bURV$KA}G_j**am}`1PaYYGOYqTTKv)tTe?JA8z}?vxU`l-NfENO?ukz@1
z0vZvEVB{%hNN0>UN-3rgDi#$Vlg|y7aJ6V<89Os0WQYDIIBRUgzVBrK^Q?Fx)n?w(
zR9g5|SsW^Uld2OfPofqy*qeDf(=vlf|!-+1c){E4K1jYY^w>BqFzT}pKA5idEnN)>-
zw0BCfHFd~VXZ9xbmqn8Zco~CsSlXk)6by|GDh3j_pVt$-uYnj7wU->s4WjU|E@5ZY
z@whRU>$^uxm}MUaR{8W9VO1PjiRq@xdZYa(BK3n#f~(K=WodI_t1Le?`;TDU-)>Ik
zirbz@YL(!Xz)yRjr&GMz18$)15Q12_K*4k%kX;HV39Sk*%$@`($_wOwP1_97LB0{c
zD(3ZBZxHj?9@@K)Itl!)oaQrjBjz(QsI(1WD*h)jeT70sZcRH
z#55+{ADF{H8MK`SdLyYH2r{4(V>ADYyA07(c%!S1SlFPP@F(Zi@Sy5
zgBMM43sBq%1P|^S+;uONnfbom{b%>t=h?sRa|6je=bn4cJ@5PegvaF^{r6^jn99dh
z?!lVOqd_CoAEjEKB_Z1HiNy$$%rxqPWaNU-Kd2XPr9<|pHr!KU+eR`EH5n_CLEo?h
zhyB;z3x++|(5(Vc4~C6C{@2Nc$_04na%GJ70H~OHo*~U_O%2jwh})*sVybs@PFhSt
z>e^KlL<2-t(*$a`;c&^CsY{39Z04wnI`yp{C#qR*6R~*EH|R~kre*vC(=OGvtTf7W
zyXn}nQpk{oLl*Bx5}A_!2^!kEa9y|K-ka?&csN#?HB!NoHII%o$7EzR^JQ`q
zmgioOz9t3CK)!gfc$~PGO-BOv#P^fWju;?krtAvFD2e9BJ=<276%_4qmaZhtRe
zjBD)d?g0Ao->@Mft-8a!1^@}hx9~f$1D+$1{wrVxbO8%>%-eqwIe*j^-siqf&`^h8
zMKeOD(P=pg<8h^X_pY+3UkT<)bU#q16Hun@g(^iz+TNH`{jx{WpgzswOFr#@D$t}5|MsW;IA87De0gfRpXG9brFV^uW{ECiQq_2Uk30|>k
zoE&@2q6nt7NrK`1!7t3*85J=i7V0Nfs05WQYXLu?C^6N14S(PJ_kD+
z>R_3dz{5&C%eqcz>#;DypV}PPHgIBt!3>X(TXps#)3|bMHqK5MAMSA5(nf<2(%l6^
zaaYVqr(Hx@J?*(}haL&<-
z{r(o1i-aPkoNdg}tJDG>W4=UCUUbjiF~75i(%R%>J>^4@ZWfOr{-9Krpnkj3zn1$@
z>*|G|zkobDvWP9IlwKhSl`drIc^|8f$TPa73nbZ3#CT&^TxwG@0^nSiUu23~mkEeFOr%3jCcNh4`is_-9_2F!CVlROFJDZ=dr=ufM&?
z8-4MNn~;{3;&ieFA1`~k2H!mIrBR>MP{0eV8z0A00oxrKJOzx9vGQDtG-ZHkK8rMn
z4M`+?@rOqYqW4dBX*tU|b4hb@PzxWKXzfQ`3V_~rkI{pbdGg4`eOYcUZ60z8g0ysS
zW)RG^I>`o@;?uvxtCI=zaJgsjWx-*z@}50i4v%rh)3G`>;QfSM=%~Me)sBG*)`NNe
zegYD93a&-n0d{x;lOy)9?{Zv}67~JxNM{Tl@ym~UqAkxFVcx`laci9OElLUfBRu`Bdo0q-ik{AAq)YP(>cjo~H7T3Wss*^nLRbD5+bLmi?9;0oil1MZSuTK`|FsnY*13rJx;;6A2
z_@?Ze8%Q`C5Wmhot9E`wTflRkxg
z^>&%Cx^OpChU}j;Cx>c!VPlO2>o3Dj4rW#N2l(tQe7qgvcRj}Z*>6der00Fcd94i=
zvI(KKl2K4O1GhVS04!Ektdi_fZ13`ufJmn-v*U3P*&vTvtfE{rO+LXK3995>gb|*+
ztVPorxwpuDN(Tl;s7#6ZyL$p=W@_jZ?#TW7@gxnH$>&B$Gm}^qwY__cE3eE-v>*5Z
zPfYDS-UL6@AP_Lm0tM?EX^daI8wgKl=C%F`JTw@Ba!dM=+IxbIVwFx6T^+yO(E3|q
zbwYZ!>jP4gP3q*tPb8JIk48v7UB+ye$`sXpO%e6BU({la6O~w6Q$*X`bPmde;A>K|
z2L|>ziL|i9s4W%90L2Gcox@j&UFTyN7d2hr7I%wV@8Y=vlUDk+6ZuxO<#E2UaJxRW
ztbs^$N|=4wJ|iN-FkrK44jeW4
zM7G>IMSRT^ju;RIvBq^8
zDx`KCl_%ve)g1Pw+l_kt#(tF99CVwwUL$k_>Q1xJdVQ#tm_j(S`9N4xYuGTk095t(
zS_eIAxAUyLTs0A<>A(grBN7!j*BbojQbi3-*31|gnw4V5K_UH`e&@+twh+Lv=1btj
z>iUs(b`B8Yq}p*b`4$5W1VMUaOH~{jrb!Ga4rgDRPhe<#P=;3@+wlOc2bNLOsjBZY
zy#Y6TXi_IG21Vj18a;(Io;=$1cC+J#cy*5#D&*b;#^Jy(u#eCxMi5_{kY)|3Q>!K+
zmgl6TD5IiPVR$sq=aM!%e-m+reE2P?l5Ns>y^1&-L1kDE7wSpmF=%dqBMmg?&u4H&
zo9Ie91Qo=xwulhF0W
z=qC=!-s0=r&!GmRp=X^nYujhA=!iq0k3<3aPk69JW`?w
zM)R4H;4v)NPy3^6)q+VTrS?(Mac{}dA@H7`oW6MqYOt4r=R(WN9%RNBSiV(5YZk_{
zJvwG`{1}su$6=#hRD`&{K8ic!SP|{Ll@QMCR1uB8$d8jN1Yn+ptwx@O7xza~Pc(Wi
z1l~R6Y`XrGiZ?%Wi*T2bCMdERe^jruYamBmZs2`KxR9uY&J-=j5Y_wYtC~c_V9gPq
z@a1OXs15R%m;J*S1&nIy1La*DubKX?S<}QukCT-wyHay#w~FPRJEJsp?~?)-d=psD
zu;340)R?X^+P+MW?I$477i2Gi`o`m~>u>#m%yG7h1vF(P?XOpgMEV`-fwH{crkvED
zOttOR=fkpeswe?%4V;l&-Ea*(!o=~+X0nobQ}NWV1zD8cYG(a8OkQcC3bT9~SKBsv
z2F-K_Pd!m+idmBiw`JkdF#R2_s-^bE3{udPxI4kEAfoU>{i
z<_~cp>)par@N=UlZ$Y=7-vkwW^vTX*#yzjwwPC-l~?aTDD_
zl&wRaWf{0F0}{_^eG0W>|EdN}-6j;~eXvK>S9__uTXI60X)b}_f_6zd<+Z}tXL>)F~CR4s4i&u)Qh_eNmFennM~?nBKx5Oz2$?e>+p
z%}>SZuL_o!$^-{eA{pgR>1j)frAT_d?3WAn?DJGr*}PG8eFL7xeuF970BWKl_%jT3
z1E=DFnqs_$#fPUNJkq&r=$yf`<8P(NpazI5MFl*UWm99ow61;2Lja-j-Sn-seeJ`k#P5S94Di41Rf1{lcy6#oE$J-{4enW(+Lx
zeFu(QtfS<21I1VM3}`##;j3>qS?;drV5^R$$DC-<$cLp%5TYn2}vtr^nn2%Hg@?9d~v;|Ll2U
zbh%*eTP4}a&&llNr}N2|I*u~{NG*U=_E$W0r3jtBVKtOLi*&~q-oXo4d6I=#%DpT;
zUqy>+x3ApVrnd)Cw%zB7y7Png4hJ#-UNE6XhVc&ezn*pWW=i_M5lI^BSqzYkDB0iC
zG3U>~pPaqI1^lQk12Mlv5|t8Po^p+hUP6qG^B(@5e;#(XSC|J7iXsDQfSW4A->zUS
zKOQfjL9|sbUmx~@^(7^dJj|(OQ#1-|ym>Rb?ycY8`><@U@~qbPZr4{&-F8nhUi<_)
z0aw`{Z4SMNt{cue@N|=QA4zK-Ki#NY+jzREdq@UjF&$@*p%Hhlg9%x^TM{T7D`-jX
z`eRq?U(;lbb8s`;dZJC!a&Xn?7&EkQQI@yn`8ZH7;B)%mk@Ud0o5-d?eXZa{dpBEe
z5I8X|g3kIk<@^5#HH=W2FA%MX2*qc#8x51A?Hi(X1o9nC-+1)oyX)T{X*-qT2?f$g
zXATMq`-~$26OPd+o&WrLbJl|K6jLt|kpE80bZ=o2g&-^28FqtV21-h3`!G#!rx$c?F`o-conMn$8-AYNmK9w^Fn
z%Ypd4({=@<96o!h&0E>gT@VKb+Wl6Rm^@OkK7agO?HwpQ05or8(T2_O=tF2HqQTe^
zT&nv4WI099hgv2hz(OsnIqWAS;+<^x3n#3he3)G}0JRVaC?h5Q^_Og)yCkX=G5(A>
zWogR5JSTp_N7S*lSN^9+`(*Imatatib%s{BG(gDlcT0AyKq{*8GZl30lA~hVr8+4bL3;pri@
zf?(T#8_aWmK-{3NOeT_@u$^iDSn9)|@|Nt?OXOHKI#RX8B*H}FS+P@YDq%E5a6F?h
zSCMa9W!n5EB*R>(=rhfimlZ_i3R7Vbm8O=EP^y5DwT`4uHK@Is?i+by()VuFb~>eK
zesi2UN!Hj;WdVvY{l
zB*MpSuZ9OxP(EO@-%eDXfIR<@~vBJ3h-!(~1gvqgC5n+XwA*+rttA1{jCrjM+W@QblTm01gQ`R_-fu
z08!B8IG@*eY*bD%^>ApA4k0!w+4gjMUol9OzQY*g_}5F(xT3kP-WXFY@9kzV#KBG8
ziIamRmcts26i)Tys?9o)Y>%%})Q|IK~ww
z1Oq7wGmV_L;QX?R3axw%5+b7crKP3C#l`t~fNLl&U+@;7-@EVlVm<5WC#Ea>xF2
zzSC}f?%=_&em`X_InPXtC6eJh#-DPLs$cKaMC{Z>dj5VK#;}2X#SYA7TKuea(V=%Z
zyfbYih&msUrWF!iv^ByZ`;hNFyL8?L27~L)ALVzVrO&IAZD@2dg;v?35{+?
zHw8%rWN<*}?}5pfvnrdIf+C5=y58_1-!}IcF8EBebr1)ZmfTPu0PHSmOmUZJs%gco|DgD}O__^8&b2+Du05>;3&|nabPq+C&H$
zZ8r9)uWzLalNCCy;rs=86=mWS54XS4$e3qV2Pk}+fiZbn+cnyqAd~E{r^>gKjnfX!
zr8XvNrL7$R-ii+qc^XA$B+^nlbY#SA@;dD;$xsieJ>DXC$_gqV2}qJSWd&YHRklLA
zrXTY+uIj84s_0F#l7)wt+$_7cG*4Bn7R?O8>U2)92|XDd?<)r;bnoS9&%Wvce>E$hX2FKH~=$s*jon@F58L~
z-MS%OncUbwJO-dCh%mD=EQy**;3BA}
z)_mzewo{7KH7dzKgL()zK>uq#YRJPXXSpkNcdZC3JsPVsSf{ynZueH|kNEV>xndUe
z(sEPhFKy2ik<_jkv!#I}f!804(;JQEL4yV<8E)|r#>_s2
z5IrlU-IQuAz+tG2#Fw>-pmI|>>~RjOvsI>~3Q_=Iq_0%`jlP9EZy!-^)8Em8(E^yY
z=qu5}E6AE{$Lm~oLr^1_X11&up`$ySKr(>zPBE82NZSwX^wW;heu7+s2T}V|^?S+*
z*o|yyy(;4WG>gN#Le3}^a--?h^1L1sXsu*Znmke-ujFAnDgWe!;r$mk4_C!)Cj}&5
z)87_%JFsE5yb;yK>m$j{xsJk^tbJqB=D?
zM*s>=crwCd`k5}R_@XHGgn1`Q>xPn5-i3TJsi>vTKpjb-sMd4HLs>)x$IZk)Gf26*
zHYrk~gbX}q3GqnIHS9Dovvj5|dE(@0;G%)`o4OGc$-;<7-ati7U-TRD9o_5=7yd%7
zAX{R*>uR_<4>~b8bf8)m1B-`QkN8w?CJi|~PA+k<6~n9iBM@7TmD{7tj9pvw*Y=8!
z*G+uQj3+qyUiP4+h4f%7;(1c)NC-sNZKL>G6)bp@r`k!1v^z}J4z+{!m+K)rVRjj|
zceXFFxrU?m9B|?ex~;Q7Q2dbha|^_jbgku%Y0POMRfY%dc{!}3b>XJ8XO&CUs*64q
zbMR1TKSY7icBas-F8YkYc98&2l)RB%xT18^208etnbhCs9xaP5#`5^!j-7PY1*Q=|
z@_GcS`zLjL7^5Q}6C;{KKL@$JjG!(^9qGjUrbT?b8g2t#uAX$<=K>m1bz_tk6Vddx
zP@h-C3L&C`Ye8Kn&np+Sw}1UqaF_*aEF5{xD@SJZFpEx7k+U{ykD-{A)lMa1yXFmZ
zQLl%2;@J+qjX_)ACA%=^OSb0Oz@_Zj`$N
z723QDV46X`HoQ&Yz^nc=TWadS3Gf-Lz@F{(D*>C$9wP4Nj+oJhBo|lqUJ$d#Xf^(`;S7-m2inM9wy|okyh2-`h%HntPmD>-zI;j&os6&C)n&_AJBqHk
z^9w?#1qcazHEfjVc~c2q*|tAMzLZV9)Jh|2)~Pb(LH9!~0p_0z6oxroPkr+NP|B^9
z?o#!lNWuMC4_)GSSdIGb_BN8Io~uD^QkU#;(q1pK<{IvJ)XoAj*}mN09wH3i7jv)q
zA||V$eB^nV+SD5Qsp(ywYHKKQT=)_fATw6*U1to3>7gW;;DBlGgRDlI;bD{mG+;=DTzRu--v8bZE2BYvO{xek$AF$
zxvSeV#T?3^(9&uZ?wH~sWQhNL*xsL}Fm%@Q=IiFat90!?r6J?FyS2N!_j|tjdAKJ}
zHmTYAz93LgWyybkUs}I%ZJF6=Tg>torzBh^up!Spwkn#x%G2GVYXielVAJG#==11s
zI~k@|{#Xa&!gd&06HDkGEyfdnOT*H@;^V(PqiDj1f(E=)wewoPPHSA$l3V0Uxp8Ot
zq1B33EH)Av`Si!ada4Ojivnte6S|j*{I2ZZeuUSBf@lH9+~v1#3Iq@@JmxPQc>r&0
zG*^a;Vc$e8RP3yl6vSI&bDrstQ);8t@|e}@XUq(MGRe_)BS%i>b9O`dO_nZ~#&JX;
zo?kZXDc70~EW>sdg)DgU|kR{#o_1#e2xk7(k43&529@^=aao)O`Tqd98L!gs_+
z)xKA8EU^_3h5`^tev*G;55O#tF0>EwGZqBSerbC}n5z5P{TPZ3->VV~02jvj8|(Xj
zfcgFJ3H$5(3JXl4c56>7S&wChjz#3%Mp})hf6(8A5A7rdQ|kv)6v1oKxjKj7WCY{+iznc{^oWB=dT(u@F4c%
zyO)x6m)P@n_U~BdXn)S=H)~C(eHnRyw40ll3PHG3oz{6-?sjC%{SyEK6b&5qP&!u2
z!Cv#yW-_QPho^``@!RpfT-3$a%b0LstGmU&|1*+6Pr`rq+?=W&Fd!zaU@F=W_Mj37
z*2wBR^N{P$)~xpQ9wB=}`operJmOtgUSt*rj#
z>p3o>@032W3-}(dm0(h-6RVc9?1v`>++Pl`;r-MS1lR@2pZ9ySaHUbjLoCq3p{X&;
zUAdZUp*$bdPEz+7Pjj4?81&DXRj!rG3mR{fionk$*p3z*hg{w2i(&~VEFshDwwSD|
z-Fac0Cg85J_Kl4BWO5GCZ-zIxrv+QxQ8GpByafHLslXsghf0^?W@j*>hxQII0@+H{
zQXe2*c@BD)(S)VhDXc?8M7?tmje^gwasOjf2D4|1&x1XLH*@NsvUQHZ3Joj;3N>-L
zzm*>jo3CuYE-vzny!|srA_Ne?_K)U51OHbRpup@U(05z@*F9GOUX=f65d&wSUwH{&
zCkEgEu3nsU|C_1%YYP8=d;IqjCXlG16x&nlp)hc@kX1mjqRth-&e`O>$*b@3)4+$*
zWu>nB7XQ`Re{m92=%m3rHUC>@z#j>-X{P_zN2*+neAlz>R>=a$wud+r_j@LA9nit3
zQW8CW&de+~ziIX1!v_TN1T$U#QF5~C3JX-k1`r#VcQ$e}Lzl8Xic34>(OhLH*@^++
z2;eIzVU;n+)W6_gaHvOz-p!ojr>83biGqmF
zn*2Pw`ubq123-^Dn49+e)fgy#v<1K6oTGPKen=+@Sgr90>POQ*eV)2CKG_`jpl8u<
zoicrqcx*Y7FP_DY*JY^^uC0oV2ljt|$pYXwxg=dc_35w*)xs~6dFfX1y06cp$w)0bvz7}VNtD9JP0nY52cTd^g
z3}C*lW*Umk^s1!U94siMw49*{rKl=l$V3=3WIQT}e>31HP
zl8nNXV9N?-LnC=VSwTrkE#w-lhOe96Tj7;~t7z%C
z-u7*^yVrZ#;aJ=zG>6iGgWeVH6Htz*8twq0*X+L1op
z2X~S*x4jrBWr4MI);3ffiV9RL#mI%$R%{=CWP&U3jg;)uvz_(_vnH3+mhrJTRF!`D@|GZ)i@HOze0`Ys`vt916H`xg1u=;GCMlXr9QW$wfub?`y0ftnTU-C(Hv|2xWS-wK+W8
z!Nz)z0@T1Kbbp{k2hVfs{GonN_JmulgRV}UYx{t3QwN~d6j&%+aFHl1K1g{D(Q5|}
zgxMsGEpbi2mY~sm+OC4PnJySHRX#!|xM?XDfGW8#2RYw0oLzDUa7C7C0os7XQPq!d4%$Qb
z-N6!r>Q_?PeVrM;d+2-~x}=l+p6U%xJEz0JsCiUXJ(mgV#S5@qcU+*GAAdIJNnWTr
zd9`mYqVMur$_3}1nnQ>`5v$R7-EQ|EbARICK&XH=LDZT&_qOTtZG=nhP6E&le4S16
zXM-to^q7HG8@YK^a6vJ5_KKObn_MwN&1FyapK=7+akL@l)tWpo04E?6?f9etMtboM
zfbYX>#V=4!loscma>tjLGTRvCO5$SIskPkmP%StNrth`7vZLVF{sN|uwW7Um>z20e
zI51&ITx*MftCcOrZAIeXGzqMhur+`2E6=6NTY)deWIb|+>hzm_6hR;mu)_~Z!PeNZ
z9>}(#-nnl!v1Dg(Qee@J=jT4X^6m`66~Ud;lN)^MM2i-XnQqdT4THS{Yn1CAr~4B*
zcAe)^P`PALhCIjW+UW;tUUhF1EfY)F?7uidHNROZvW$J5uS|&AcL}_xI&P7D5-`Nh
zQWUy*sP8dzqO6?encX1=&qTzI-)jeY`3~~^E9dWb^n0~
zG<+4MuWomsTJF4@BrjL7l-jjJiHOqCQ@3lQVNYOlHIX)f-?fA11;pXYO|a*=yq!oc
zjd-;5DOsU7aZP{U!hB|qBt;swtqGk(3}!}l_BqbgPDhWic3
zPwdt339WKnygfp7N;d9KX*kEmEsj1u$xF
z0YD%4y-doL9Pne6H~i)+(U9K;0sgWd&A?T3E+LB?H0P%XK?y7Y>v_QoMel@rgB8^A
zy!86GeH;i6ZJclGaSN(c1C<1kk*Wy9Vw5kC_r%#6o$;03|J$Nb+h(!P{_nItI94p^dSz#3FNSQI|&U;LO{S^7354K4La>gc><;
zUk^%4O92Io)oS0Tk&JY7CeF@BTQiNt6-61qVBkPvGIUFKm-Kz`
z{r-G@-|s*7u66HP_YW4&^UOJCpR?nf*WPFEU}Z&VTr3JKG&D3^Ss4jcG_?D4XlUpP
zkI;cH#r(oJz`uJRRi(wyN(QJlfR_j6?-bslp_NBqUwyy;-XGh`=zK&&!~1#ncdyef
z&jbxESyEQwow}RBPSayAjn0&{Ue7e27`~J~`Xe)sxg_^e!JX7>!IW$pSw(#MHkWOA
z#?Ve`W7qm7`Zg$&3lm|v@eGu=lk%Q*XIPMA8pQSe3G@q~47bx1~7ATG?Id2+t9NX77Gzba`4yL^|R8vz^
zQ7Jd>43D5I=lM8^v)Iarh9>iTxevq0SWdlbl&>mklZm^*Wrr5S`Rb2@s#jmC;?dB)Q?|Fao0^(tXI0zH8)#`s_k>)6!o!qVCn#MEzEz~yNOw0`1%5i^z`&JG@M66
zgFeF5r}!=%PLA?Etfr(S21pVR`^9=z#4OultapA+vK~^v^os$;O64Ls
zhHueiWHXf^F-%Hu4uCqkjEZdBebx6U7=eFgMKEYwbWfrbDMRADr8^&8@%jO=UuO4%
zj3L-qz4O*G`bt>yjbC7z&cS~8YA0o>!kf9X!g{|oMZL{0yXY+UaiJ6wS*noZZ5c8&
zG?RND7@OJ#19|mHvifKRH?%NPUIRdGZ~thhlCRt}Qa
zZjRkM%deZ+uIoWYuq5<)E0g+mArSjE?K#N|#AhSv^3ry8+OwDG=h5cm+og}e-Jn5k
zP=oH6Yu{@@(|F%)udgIdXBCW&zj7ZPWa#;5g?s62&_?Q?owKs-Y=NvXY>$^9%tI{Nj+=xo)6)OIt*l3ByI!MFXhg4w>jx3AbZJtg{(Tz7;cir?c
z%xal-tH#eQ&1z~A>~j+U^d?g>G`sVY7_*+o4|IUIj6xd)HP%xW8h;j!Rvwk?5LAVL
z-T_KVg&9$ix^He>)Yc}#{K^GOo0La;Gu>4nG@7;?MDTJ~-7D61
zBJv);l3oJc2Ty-C+V;=lm>;Mwpa@yWbc<U+{%I9><_L&LXL_o8
zsNDDbP&`aJbl&TzAI9d&bB2TSV36;bpv!7sLh7?ae~CEFtZ1DFv7~5d{!D$@aevN#
z<&+qa>24GtgHnGZN|$~26E5d3@$nlk_k0>RZxXg{PGt5bsK;+E>qGfU_s$KI-gq?a
zSZo-H2bS(Qo{uemdR_n2NNU(v0O{|eq0em`&>!$wD1<${@7>_cq83A$7idzI81XTF
zy4FHMorS^Hp{TqMyk6#ndBr8iE~j~Jk#N+@`cXr=Chxwv=G76Ifrtd2K2#yiz>8aS
zU{|eycdWcD$P@>=l0+W+uNh>hl3*fyXK5OWoEkl)!1JQr#()rtfr4dY9kw}KdvRb2&Hm(
z?5u@my~8VkZiwPBaZ;cUB6!WTL-aFKmR+Zi9*)fTI23IePZG<5`)!>|DQO(X-pp$3
zv;IgWOv`OWz1EXTt{DD=g8cZkhok-G&E62Bpe*NzPWR|XvcRookr?=k+Jyd7IG~;9DY0hQSr7r=3(=d
zl=oa>C|{H7O-E+tu|a?9zV@Ul