deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-07 10:07:21 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'main' of https://github.com/MicrosoftDocs/windows-docs-pr into uc-wkbk

Browse Source
This commit is contained in:
Meghan Stewart 2022-08-03 10:06:48 -07:00
commit e666c9de62
163 changed files with 1001 additions and 1004 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
devices/hololens/docfx.json
View File

@ -39,7 +39,7 @@
"ms.date": "04/05/2017",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "Win.itpro-hololens",

2
devices/surface-hub/docfx.json
View File

@ -36,7 +36,7 @@
"ms.date": "05/23/2017",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "Win.surface-hub",

2
devices/surface/docfx.json
View File

@ -32,7 +32,7 @@
"ms.date": "05/09/2017",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "Win.surface",

10
education/docfx.json
View File

@ -27,15 +27,13 @@
],
"globalMetadata": {
"recommendations": true,
"ROBOTS": "INDEX, FOLLOW",
"audience": "windows-education",
"ms.topic": "article",
"ms.technology": "windows",
"manager": "dansimp",
"manager": "aaroncz",
"breadcrumb_path": "/education/breadcrumb/toc.json",
"ms.date": "05/09/2017",
"feedback_system": "None",
"hideEdit": true,
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "Win.education",

2
gdpr/docfx.json
View File

@ -36,7 +36,7 @@
"ms.author": "lizross",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"contributors_to_exclude": [
"rjagiewich",
"traya1",

2
mdop/docfx.json
View File

@ -36,7 +36,7 @@
"ms.date": "04/05/2017",
"feedback_system": "GitHub",
"feedback_github_repo": "https://github.com/MicrosoftDocs/mdop-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "Win.mdop",

2
windows/client-management/docfx.json
View File

@ -41,7 +41,7 @@
"manager": "dansimp",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-client-management",

2
windows/deployment/do/index.yml
View File

@ -51,7 +51,7 @@ landingContent:
- text: Delivery Optimization Frequently Asked Questions
url: ../update/waas-delivery-optimization-faq.md
- text: Submit feedback
url: https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app
url: https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332
# Card (optional)
- title: Configure Delivery Optimization on Microsoft Endpoint Manager

2
windows/deployment/docfx.json
View File

@ -42,7 +42,7 @@
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.win-development",

2
windows/deployment/planning/windows-10-deprecated-features.md
View File

@ -31,7 +31,7 @@ The features in this article are no longer being actively developed, and might b
**The following list is subject to change and might not include every affected feature or functionality.**
> [!NOTE]
> If you have feedback about the proposed replacement of any of these features, you can use the [Feedback Hub app](https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app).
> If you have feedback about the proposed replacement of any of these features, you can use the [Feedback Hub app](https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332).
|Feature | Details and mitigation | Deprecation announced |
| ----------- | --------------------- | ---- |

2
windows/hub/docfx.json
View File

@ -42,7 +42,7 @@
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.windows-hub",

2
windows/known-issues/docfx.json
View File

@ -39,7 +39,7 @@
"breadcrumb_path": "/windows/windows-10/breadcrumb/toc.json",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"contributors_to_exclude": [
"rjagiewich",
"traya1",

2
windows/privacy/docfx.json
View File

@ -40,7 +40,7 @@
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.privacy",

2
windows/security/docfx.json
View File

@ -41,7 +41,7 @@
"audience": "ITPro",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/help/4021566/windows-10-send-feedback-to-microsoft-with-feedback-hub-app",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",
"_op_documentIdPathDepotMapping": {
"./": {
"depot_name": "MSDN.security",

22
windows/security/threat-protection/auditing/event-4913.md
View File

@ -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: <https://msdn.microsoft.com/library/cc230374.aspx>, <https://msdn.microsoft.com/library/windows/hardware/aa374892(v=vs.85).aspx>.
@ -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**).
<!-- -->

4
windows/security/threat-protection/auditing/event-4928.md
View File

@ -97,12 +97,12 @@ Failure event generates if an error occurs (**Status Code** != 0).
<img src="images/ad-sites-and-services.png" alt="Directory Replication Service options in AD Sites and Services" width="890" height="529" />
- **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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## 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.

6
windows/security/threat-protection/auditing/event-4929.md
View File

@ -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**&nbsp;&nbsp;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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## 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.

8
windows/security/threat-protection/auditing/event-4930.md
View File

@ -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**&nbsp;&nbsp;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**&nbsp;&nbsp;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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## 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.

6
windows/security/threat-protection/auditing/event-4931.md
View File

@ -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**&nbsp;&nbsp;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**&nbsp;&nbsp;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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
- **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: <https://msdn.microsoft.com/library/windows/desktop/ms681381(v=vs.85).aspx>
## Security Monitoring Recommendations

8
windows/security/threat-protection/auditing/event-4945.md
View File

@ -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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **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:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -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.

12
windows/security/threat-protection/auditing/event-4946.md
View File

@ -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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **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:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -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.

12
windows/security/threat-protection/auditing/event-4948.md
View File

@ -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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **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:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
@ -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.

4
windows/security/threat-protection/auditing/event-4950.md
View File

@ -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:
<img src="images/netsh-advfirewall-command.png" alt="Netsh advfirewall command illustration" width="951" height="422" />
@ -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.

20
windows/security/threat-protection/auditing/event-4951.md
View File

@ -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.
<img src="images/event-4951.png" alt="Event 4951 illustration" width="449" height="364" hspace="10" align="left" />
@ -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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **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:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
## 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.

18
windows/security/threat-protection/auditing/event-4953.md
View File

@ -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.
<img src="images/event-4953.png" alt="Event 4953 illustration" width="449" height="375" hspace="10" align="left" />
@ -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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
@ -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.

10
windows/security/threat-protection/auditing/event-4957.md
View File

@ -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.
description: Describes security event 4957(F) Windows Firewall didn't apply the following rule.
ms.pagetype: security
ms.prod: m365-security
ms.mktglfcycl: deploy
@ -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**&nbsp;&nbsp;For recommendations, see [Security Monitoring Recommendations](#security-monitoring-recommendations) for this event.
@ -69,17 +69,17 @@ 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:
<img src="images/registry-editor-firewallrules.png" alt="Registry Editor FirewallRules key illustration" width="1412" height="422" />
- **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:
<img src="images/windows-firewall-with-advanced-security.png" alt="Windows Firewall with Advanced Security illustration" width="1082" height="363" />
**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

8
windows/security/threat-protection/auditing/event-4958.md
View File

@ -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.
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
@ -17,15 +17,15 @@ 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.
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:***&nbsp;[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

4
windows/security/threat-protection/auditing/event-5030.md
View File

@ -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:***&nbsp;[Audit Other System Events](audit-other-system-events.md)

6
windows/security/threat-protection/auditing/event-5031.md
View File

@ -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**&nbsp;&nbsp;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**.”

8
windows/security/threat-protection/auditing/event-5038.md
View File

@ -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.
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
@ -19,11 +19,11 @@ ms.technology: windows-sec
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:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

6
windows/security/threat-protection/auditing/event-5039.md
View File

@ -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:***&nbsp;[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.

6
windows/security/threat-protection/auditing/event-5051.md
View File

@ -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:***&nbsp;[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.

4
windows/security/threat-protection/auditing/event-5056.md
View File

@ -27,9 +27,9 @@ For more information about Cryptographic Next Generation (CNG) visit these pages
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

6
windows/security/threat-protection/auditing/event-5057.md
View File

@ -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
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

10
windows/security/threat-protection/auditing/event-5058.md
View File

@ -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**&nbsp;&nbsp;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:
<img src="images/certutil-command.png" alt="Certutil command illustration" width="588" height="665" />

4
windows/security/threat-protection/auditing/event-5060.md
View File

@ -27,9 +27,9 @@ For more information about CNG, visit these pages:
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit System Integrity](audit-system-integrity.md)

10
windows/security/threat-protection/auditing/event-5061.md
View File

@ -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**&nbsp;&nbsp;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:
<img src="images/certutil-command.png" alt="Certutil command illustration" width="588" height="665" />

6
windows/security/threat-protection/auditing/event-5063.md
View File

@ -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
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

6
windows/security/threat-protection/auditing/event-5064.md
View File

@ -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
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

7
windows/security/threat-protection/auditing/event-5065.md
View File

@ -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
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

6
windows/security/threat-protection/auditing/event-5066.md
View File

@ -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
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

8
windows/security/threat-protection/auditing/event-5067.md
View File

@ -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:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

8
windows/security/threat-protection/auditing/event-5068.md
View File

@ -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:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

8
windows/security/threat-protection/auditing/event-5069.md
View File

@ -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:
- <https://msdn.microsoft.com/library/windows/desktop/aa376214(v=vs.85).aspx>
- <https://www.microsoft.com/download/details.aspx?id=30688>
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:***&nbsp;[Audit Other Policy Change Events](audit-other-policy-change-events.md)

2
windows/security/threat-protection/auditing/monitor-the-central-access-policies-that-apply-on-a-file-server.md
View File

@ -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**

2
windows/security/threat-protection/auditing/monitor-the-resource-attributes-on-files-and-folders.md
View File

@ -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:

6
windows/security/threat-protection/auditing/monitor-user-and-device-claims-during-sign-in.md
View File

@ -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.

30
windows/security/threat-protection/auditing/planning-and-deploying-advanced-security-audit-policies.md
View File

@ -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)).
## <a href="" id="bkmk-5"></a>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.
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.

4
windows/security/threat-protection/auditing/security-auditing-overview.md
View File

@ -25,14 +25,14 @@ Topics in this section are for IT professionals and describes the security audit
## <a href="" id="bkmk-over"></a>
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. |

26
windows/security/threat-protection/block-untrusted-fonts-in-enterprise.md
View File

@ -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\<process_image_name>`.<br><br>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

24
windows/security/threat-protection/device-guard/enable-virtualization-based-protection-of-code-integrity.md
View File

@ -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**.
![Enable HVCI using Group Policy.](../images/enable-hvci-gp.png)
@ -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.
<!--This comment ensures that the Important above and the Warning below don't merge together. -->
@ -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 `<OS Volume>\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 `<OS Volume>\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 `<OS Volume>\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 <VMName> -VirtualizationBasedSecurityOptOut $true
@ -324,6 +324,6 @@ Set-VMSecurity -VMName <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`.

32
windows/security/threat-protection/device-guard/requirements-and-deployment-planning-guidelines-for-virtualization-based-protection-of-code-integrity.md
View File

@ -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**,<br>plus **extended page tables** | These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>• VT-x (Intel) or<br>• AMD-V<br>And:<br>• 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**,<br>plus **extended page tables** | These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>• VT-x (Intel) or<br>• AMD-V<br>And:<br>• 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<br><blockquote><p><b>Important:</b><br> 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.</p></blockquote> | Support for VBS and for management features. |
> **Important**&nbsp;&nbsp;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.<br>• In the BIOS configuration, BIOS authentication must be set.<br>• 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.<br>• 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.<br>• 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.<br>• In the BIOS configuration, BIOS authentication must be set.<br>• 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.<br>• 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.<br>• Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
<br>
### 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).<br>• 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.<br>• 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).<br>• 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.<br>• 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.<br>• 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.<br>• 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.<br>• 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.<br>• Removing Microsoft UEFI CA from Secure Boot DB provides full control to enterprises over software that runs before the operating system boots. |
<br>
### 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.<br>• UEFI runtime service must meet these requirements: <br>&nbsp;&nbsp;&nbsp;&nbsp;• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table. <br>&nbsp;&nbsp;&nbsp;&nbsp;• PE sections need to be page-aligned in memory (not required for in non-volitile storage).<br>&nbsp;&nbsp;&nbsp;&nbsp;• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;• 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. <br><blockquote><p><b>Notes:</b><br>• This only applies to UEFI runtime service memory, and not UEFI boot service memory. <br>• This protection is applied by VBS on OS page tables.</p></blockquote><br> Please also note the following: <br>• Do not use sections that are both writeable and executable<br>• Do not attempt to directly modify executable system memory<br>• 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)<br>• 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)<br>• Reduces the attack surface to VBS from system firmware.<br>• 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.<br>• UEFI runtime service must meet these requirements: <br>&nbsp;&nbsp;&nbsp;&nbsp;• Implement UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. All UEFI runtime service memory (code and data) must be described by this table. <br>&nbsp;&nbsp;&nbsp;&nbsp;• PE sections need to be page-aligned in memory (not required for in non-volitile storage).<br>&nbsp;&nbsp;&nbsp;&nbsp;• The Memory Attributes Table needs to correctly mark code and data as RO/NX for configuration by the OS:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;• All entries must include attributes EFI_MEMORY_RO, EFI_MEMORY_XP, or both <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;• 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. <br><blockquote><p><b>Notes:</b><br>• This only applies to UEFI runtime service memory, and not UEFI boot service memory. <br>• This protection is applied by VBS on OS page tables.</p></blockquote><br> Also note the following guidelines: <br>• Don't use sections that are both writeable and executable<br>• Don't attempt to directly modify executable system memory<br>• 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)<br>• 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)<br>• Reduces the attack surface to VBS from system firmware.<br>• Blocks other security attacks against SMM. |

6
windows/security/threat-protection/mbsa-removal-and-guidance.md
View File

@ -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:
[![PowerShell script.](images/powershell-example.png)](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

20
windows/security/threat-protection/microsoft-defender-application-guard/configure-md-app-guard.md
View File

@ -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. <p>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. <p>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. <p>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. <p>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<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the clipboard functionality.|**Enabled.** Turns On the clipboard functionality and lets you choose whether to additionally:<br/>- Disable the clipboard functionality completely when Virtualization Security is enabled.<br/>- Enable copying of certain content from Application Guard into Microsoft Edge.<br/>- 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.<p>**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<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:<br/>- Enable Application Guard to print into the XPS format.<br/>- Enable Application Guard to print into the PDF format.<br/>- Enable Application Guard to print to locally attached printers.<br/>- Enable Application Guard to print from previously connected network printers. Employees can't search for additional printers.<br/><br/>**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<p>Windows 10 Pro, 1803 or higher<p>Windows 11|Determines whether Application Guard can use the print functionality.|**Enabled.** Turns On the print functionality and lets you choose whether to additionally:<br/>- Enable Application Guard to print into the XPS format.<br/>- Enable Application Guard to print into the PDF format.<br/>- Enable Application Guard to print to locally attached printers.<br/>- Enable Application Guard to print from previously connected network printers. Employees can't search for other printers.<br/><br/>**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<p>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. <p>**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.<p>**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<br><br>Windows 10 Pro, 1803 or higher<p>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.<p>**Disabled or not configured.** All user data within Application Guard is reset between sessions.<p>**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.<p>**To reset the container:**<br/>1. Open a command-line program and navigate to `Windows/System32`.<br/>2. Type `wdagtool.exe cleanup`. The container environment is reset, retaining only the employee-generated data.<br/>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<p>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:<br/>- Enable Microsoft Defender Application Guard only for Microsoft Edge<br/>- Enable Microsoft Defender Application Guard only for Microsoft Office<br/>- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office<br/><br/>**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<p>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.<p>**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<br><br>Windows 10 Pro, 1803 or higher<p>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.<br><br>**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<br><br>Windows 10 Pro, 1809 or higher<p>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.<p>**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<br><br>Windows 10 Pro, 1809 or higher<p>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.<p>**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<p>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:<br/>- Enable Microsoft Defender Application Guard only for Microsoft Edge<br/>- Enable Microsoft Defender Application Guard only for Microsoft Office<br/>- Enable Microsoft Defender Application Guard for both Microsoft Edge and Microsoft Office<br/><br/>**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<p>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.<p>**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<br><br>Windows 10 Pro, 1803 or higher<p>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.<br><br>**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<br><br>Windows 10 Pro, 1809 or higher<p>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.<p>**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<br><br>Windows 10 Pro, 1809 or higher<p>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.<p>**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<br><br>Windows 10 Pro, 1809 or higher<p>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.<p>**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).

26
windows/security/threat-protection/microsoft-defender-application-guard/faq-md-app-guard.yml
View File

@ -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 Internet Connection Service (ICS) without breaking Application Guard?
answer: |
ICS is enabled by default in Windows, and ICS must be enabled for Application Guard to function correctly. We do not recommend disabling ICS, this will stop Application Guard from working; 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: <br/>
`System\CurrentControlSet\Services\SharedAccess\Parameters\DisableIpNat = 1`
3. Configure ICS (SharedAccess) to enabled as follows: <br/>
3. Configure ICS (SharedAccess) to be enabled as follows: <br/>
`HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Start = 3`
4. (This is optional) Disable IPNAT as follows: <br/>
4. (This step is optional) Disable IPNAT as follows: <br/>
`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`.

10
windows/security/threat-protection/microsoft-defender-application-guard/reqs-md-app-guard.md
View File

@ -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)_ <p> **AND** <p> One of the following virtualization extensions for VBS:<br/>VT-x (Intel)<br/>**OR**<br/>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 <br/> Windows 10 Professional edition, version 1809 or higher <br/> Windows 10 Professional for Workstations edition, version 1809 or higher <br/> Windows 10 Professional Education edition, version 1809 or higher <br/> Windows 10 Education edition, version 1809 or higher <br/> 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. <br/> Windows 11 |
| Operating system | Windows 10 Enterprise edition, version 1809 or higher <br/> Windows 10 Professional edition, version 1809 or higher <br/> Windows 10 Professional for Workstations edition, version 1809 or higher <br/> Windows 10 Professional Education edition, version 1809 or higher <br/> Windows 10 Education edition, version 1809 or higher <br/> 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. <br/> Windows 11 |
| Browser | Microsoft Edge |
| Management system <br> (only for managed devices)| [Microsoft Intune](/intune/) <p> **OR** <p> [Microsoft Endpoint Configuration Manager](/configmgr/) <p> **OR** <p> [Group Policy](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc753298(v=ws.11)) <p> **OR** <p>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. |

4
windows/security/threat-protection/msft-security-dev-lifecycle.md
View File

@ -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

6
windows/security/threat-protection/override-mitigation-options-for-app-related-security-policies.md
View File

@ -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.

44
windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10.md
View File

@ -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. |
<a href="" id="threat-landscape"></a>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**<br> helps keep a device<br>from running malware or<br>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.<br>Device Guard is included in Windows 10 Enterprise and Windows Server 2016.<br><br>**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**,<br>which helps keep devices<br>free of viruses and other<br>malware | Windows 10 includes Microsoft Defender Antivirus, a robust inbox anti-malware solution. Microsoft Defender Antivirus has been improved significantly since it was introduced in Windows 8.<br><br>**More information**: [Microsoft Defender Antivirus](#microsoft-defender-antivirus), later in this topic |
| **Blocking of untrusted fonts**<br> helps prevent fonts<br>from being used in<br>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).<br><br>**More information**: [Block untrusted fonts in an enterprise](/windows/threat-protection/block-untrusted-fonts-in-enterprise) |
| **Memory protections**<br> help prevent malware<br>from using memory manipulation<br>techniques such as buffer<br>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:<br>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.<br><br>**More information**: [Table 2](#table-2), later in this topic |
| **Memory protections**<br> help prevent malware<br>from using memory manipulation<br>techniques such as buffer<br>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:<br>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.<br><br>**More information**: [Table 2](#table-2), later in this topic |
| **UEFI Secure Boot**<br> helps protect<br>the platform from<br>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.<br><br>**More information**: [UEFI and Secure Boot](/windows/device-security/bitlocker/bitlocker-countermeasures#uefi-and-secure-boot)</a> |
| **Early Launch Antimalware (ELAM)**<br> helps protect<br>the platform from<br>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.<br><br>**More information**: [Early Launch Antimalware](/windows/device-security/bitlocker/bitlocker-countermeasures#protection-during-startup) |
| **Device Health Attestation**<br> helps prevent<br>compromised devices from<br>accessing an organization's<br>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.<br><br>**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)**<br> helps prevent<br>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.<br>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.<br>**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.<br><br>**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**<br> helps prevent<br>overwrites of the<br>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.<br>**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.<br><br>**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)**<br> helps prevent<br>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.<br>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.<br>**More information**: [Data Execution Prevention](#data-execution-prevention), later in this topic.<br><br>**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**<br> helps prevent<br>overwrites of the<br>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.<br>**More information**: [Structured Exception Handling Overwrite Protection](#structured-exception-handling-overwrite-protection), later in this topic.<br><br>**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**<br> helps mitigate malware<br>attacks based on<br>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.<br>**More information**: [Address Space Layout Randomization](#address-space-layout-randomization), later in this topic.<br><br>**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**<br>screen downloadable<br>apps and run them in<br>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.<br><br>**More information**: [Universal Windows apps protections](#universal-windows-apps-protections), later in this topic. |
| **Heap protections**<br>help prevent<br>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.<br><br>**More information**: [Windows heap protections](#windows-heap-protections), later in this topic. |
| **Kernel pool protections**<br>help prevent<br>exploitation of pool memory<br>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.<br><br>**More information**: [Kernel pool protections](#kernel-pool-protections), later in this topic. |
| **Control Flow Guard**<br>helps mitigate exploits<br>based on<br>flow between code locations<br>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.<br>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.<br><br>**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
| **Control Flow Guard**<br>helps mitigate exploits<br>based on<br>flow between code locations<br>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.<br>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.<br><br>**More information**: [Control Flow Guard](#control-flow-guard), later in this topic. |
| **Protections built into Microsoft Edge** (the browser)<br>helps mitigate multiple<br>threats | Windows 10 includes an entirely new browser, Microsoft Edge, designed with multiple security improvements.<br><br>**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.
|<li>DEP<li>SEHOP<li>ASLR (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.|
|<li>Load Library Check (LoadLib)<li>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.|
|<li>Heap Spray<li>EAF<li>EAF+|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.|
|<li>Heap Spray<li>EAF<li>EAF+|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.|
|<li>Caller Check<li>Simulate Execution Flow<li>Stack Pivot<li>Deep Hooks (an ROP "Advanced Mitigation")<li>Anti Detours (an ROP "Advanced Mitigation")<li>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

144
windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
View File

@ -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.<p>UEFI Secure Boot ensures that the device boots only authorized code.<p>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.<div class="alert">**Note:** Device Guard can be enabled without using virtualization-based security.</div>|
|X64 processor|Required to support virtualization-based security that uses Windows Hypervisor. Hyper-V is supported only on x64 processor (and not on x86).<p>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).<p>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.
## <a href="" id="detect-unhealthy"></a>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|<li>PCR0 measurement<li>Secure Boot Enabled<li>Secure Boot db matches Expected<li>Secure Boot dbx is up to date<li>Secure Boot policy GUID matches Expected<li>BitLocker enabled<li>Virtualization-based security enabled<li>ELAM was loaded<li>Code Integrity version is up to date<li>Code 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
### <a href="" id="management-of-windows-defender-by-third-party-mdm-"></a>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
### <a href="" id="office-365-conditional-access-control-"></a>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:
### <a href="" id="cloud-and-on-premises-apps-conditional-access-control-"></a>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.

16
windows/security/threat-protection/security-policy-settings/access-this-computer-from-the-network.md
View File

@ -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)

8
windows/security/threat-protection/security-policy-settings/account-lockout-duration.md
View File

@ -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

26
windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md
View File

@ -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.
### <a href="" id="bkmk-impleconsiderations"></a>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
### <a href="" id="bkmk-countermeasure"></a>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.

2
windows/security/threat-protection/security-policy-settings/account-policies.md
View File

@ -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

22
windows/security/threat-protection/security-policy-settings/accounts-administrator-account-status.md
View File

@ -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

22
windows/security/threat-protection/security-policy-settings/accounts-block-microsoft-accounts.md
View File

@ -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

10
windows/security/threat-protection/security-policy-settings/accounts-guest-account-status.md
View File

@ -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

18
windows/security/threat-protection/security-policy-settings/accounts-limit-local-account-use-of-blank-passwords-to-console-logon-only.md
View File

@ -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)

10
windows/security/threat-protection/security-policy-settings/accounts-rename-administrator-account.md
View File

@ -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

6
windows/security/threat-protection/security-policy-settings/accounts-rename-guest-account.md
View File

@ -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

12
windows/security/threat-protection/security-policy-settings/act-as-part-of-the-operating-system.md
View File

@ -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

16
windows/security/threat-protection/security-policy-settings/add-workstations-to-domain.md
View File

@ -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)

73
windows/security/threat-protection/security-policy-settings/administer-security-policy-settings.md
View File

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

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

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

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

@ -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.

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

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

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

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

@ -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

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

@ -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

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

@ -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

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

@ -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

Some files were not shown because too many files have changed in this diff Show More