From fe835d46e4edb9e42d457bba8a80fcc9c995c53d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Sun, 19 Dec 2021 23:56:07 +0100 Subject: [PATCH 01/12] Replaced old Azure AD Graph-based examples Updated section "Verify the onPremisesDistinguishedName attribute is synchronized" as suggested in user feedback for issue #10216 Replaced Azure AD Graph examples with Microsoft Graph. #ATCP --- .../hello-hybrid-aadj-sso-cert.md | 46 ++++++++++++++++--- 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index cd403a4167..d6ce21bdd3 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -87,17 +87,51 @@ Sign-in to computer running Azure AD Connect with access equivalent to _local ad ### Verify the onPremisesDistinguishedName attribute is synchronized -The easiest way to verify the onPremisesDistingushedNamne attribute is synchronized is to use Azure AD Graph Explorer. +The easiest way to verify that the onPremisesDistingushedNamne attribute is synchronized is to use the Graph Explorer for Microsoft Graph. -1. Open a web browser and navigate to https://graphexplorer.azurewebsites.net/ +1. Open a web browser and navigate to https://developer.microsoft.com/en-us/graph/graph-explorer -2. Click **Login** and provide Azure credentials +2. Click **Sign in to Graph Explorer** and provide Azure credentials -3. In the Azure AD Graph Explorer URL, type https://graph.windows.net/myorganization/users/[userid], where **[userid]** is the user principal name of user in Azure Active Directory. Click **Go** +> [!NOTE] +> To successfully query the Graph API, adequate [permissions](/graph/api/user-get?view=graph-rest-1.0&tabs=http#permissions) must be granted. -4. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and the value is accurate for the given user. +3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and click **Consent**. You will now be prompted for delegated permissions consent. - ![Azure AD Connect On-Prem DN Attribute.](images/aadjcert/aadconnectonpremdn.png) +4. In the Graph Explorer URL, type https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName, where **[userid]** is the user principal name of a user in the Azure Active Directory. Click **Run query** + +> [!NOTE] +> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters we will use the $select [Optional OData query parameter](/graph/api/user-get?view=graph-rest-1.0&tabs=http#optional-query-parameters). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios. + +#### Request + + +```msgraph-interactive +GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}?$select=displayName,userPrincipalName,onPremisesDistinguishedName +``` + +5. In the returned results, review the JSON data for the **onPremisesDistinguishedName** attribute. Ensure the attribute has a value and that the value is accurate for the given user. If the **onPremisesDistinguishedName** attribute is not synchronized the value will be **null**. + +#### Response + +```http +HTTP/1.1 200 OK +Content-type: application/json + +{ + "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(displayName,userPrincipalName,onPremisesDistinguishedName)/$entity", + "displayName": "Nestor Wilke", + "userPrincipalName": "NestorW@contoso.com", + "onPremisesDistinguishedName" : "CN=Nestor Wilke,OU=Operations,DC=contoso,DC=com" +} +``` ## Prepare the Network Device Enrollment Services (NDES) Service Account From 28b5dbc5b87461f5e74fb36f8f1fba7cc16a0f70 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Mon, 20 Dec 2021 15:14:13 +0100 Subject: [PATCH 02/12] Update Graph Explorer URL Was uncertain as to keep or not keep the locale in the URL. I noticed it worked either way, so thanks for clarifying! :-) Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index d6ce21bdd3..30fa08883f 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -89,7 +89,7 @@ Sign-in to computer running Azure AD Connect with access equivalent to _local ad The easiest way to verify that the onPremisesDistingushedNamne attribute is synchronized is to use the Graph Explorer for Microsoft Graph. -1. Open a web browser and navigate to https://developer.microsoft.com/en-us/graph/graph-explorer +1. Open a web browser and navigate to [Graph Explorer](https://developer.microsoft.com/graph/graph-explorer). 2. Click **Sign in to Graph Explorer** and provide Azure credentials From ffbe7994c5809665ddb01c5fe7cafd1ca367734b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Mon, 20 Dec 2021 15:15:05 +0100 Subject: [PATCH 03/12] Select rather than Click ...and a full stop, thanks :-) Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index 30fa08883f..70de4da80f 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -91,7 +91,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync 1. Open a web browser and navigate to [Graph Explorer](https://developer.microsoft.com/graph/graph-explorer). -2. Click **Sign in to Graph Explorer** and provide Azure credentials +2. Select **Sign in to Graph Explorer** and provide Azure credentials. > [!NOTE] > To successfully query the Graph API, adequate [permissions](/graph/api/user-get?view=graph-rest-1.0&tabs=http#permissions) must be granted. From bf9231540fac8dc39bef2ff66a3fd720bbc976d5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Mon, 20 Dec 2021 15:16:13 +0100 Subject: [PATCH 04/12] Lets get rid of click! Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index 70de4da80f..74e6286f69 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -96,7 +96,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync > [!NOTE] > To successfully query the Graph API, adequate [permissions](/graph/api/user-get?view=graph-rest-1.0&tabs=http#permissions) must be granted. -3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and click **Consent**. You will now be prompted for delegated permissions consent. +3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You will now be prompted for delegated permissions consent. 4. In the Graph Explorer URL, type https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName, where **[userid]** is the user principal name of a user in the Azure Active Directory. Click **Run query** From 01dc646ce3e1972a8bfe8d11cc2c58b24cb1e765 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Mon, 20 Dec 2021 15:17:01 +0100 Subject: [PATCH 05/12] Clean up text Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index 74e6286f69..4892c11eb3 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -98,7 +98,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync 3. Select **Modify permissions (Preview)**. Scroll down and locate **User.Read.All** (or any other required permission) and select **Consent**. You will now be prompted for delegated permissions consent. -4. In the Graph Explorer URL, type https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName, where **[userid]** is the user principal name of a user in the Azure Active Directory. Click **Run query** +4. In the Graph Explorer URL, enter https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName, where **[userid]** is the user principal name of a user in Azure Active Directory. Select **Run query**. > [!NOTE] > Because the v1.0 endpoint of the Graph API only provides a limited set of parameters we will use the $select [Optional OData query parameter](/graph/api/user-get?view=graph-rest-1.0&tabs=http#optional-query-parameters). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios. From 53f68a50da0331345fc890a615e6404121a943e3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim=20Peter=20Edstr=C3=B8m?= <22084975+timpeteren@users.noreply.github.com> Date: Mon, 20 Dec 2021 15:17:40 +0100 Subject: [PATCH 06/12] Correct writing. Thanks for reading through and proposing changes! Co-authored-by: JohanFreelancer9 <48568725+JohanFreelancer9@users.noreply.github.com> --- .../hello-for-business/hello-hybrid-aadj-sso-cert.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index 4892c11eb3..b7b190c49c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -101,7 +101,7 @@ The easiest way to verify that the onPremisesDistingushedNamne attribute is sync 4. In the Graph Explorer URL, enter https://graph.microsoft.com/v1.0/users/[userid]?$select=displayName,userPrincipalName,onPremisesDistinguishedName, where **[userid]** is the user principal name of a user in Azure Active Directory. Select **Run query**. > [!NOTE] -> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters we will use the $select [Optional OData query parameter](/graph/api/user-get?view=graph-rest-1.0&tabs=http#optional-query-parameters). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios. +> Because the v1.0 endpoint of the Graph API only provides a limited set of parameters, we will use the $select [Optional OData query parameter](/graph/api/user-get?view=graph-rest-1.0&tabs=http#optional-query-parameters). For convenience, it is possible to switch the API version selector from **v1.0** to **beta** before performing the query. This will provide all available user information, but remember, **beta** endpoint queries should not be used in production scenarios. #### Request From afb3401379cdfbb67b423cdb58d0c2eb9aebf3b8 Mon Sep 17 00:00:00 2001 From: Evan Miller Date: Mon, 31 Jan 2022 16:50:52 -0800 Subject: [PATCH 07/12] 38000313 - Add variable type to MR policies page Apologies for any mistakes, I used web editor instead of desktop / VS code. --- .../mdm/policy-csp-mixedreality.md | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/windows/client-management/mdm/policy-csp-mixedreality.md b/windows/client-management/mdm/policy-csp-mixedreality.md index 8ffc0e7ba1..ad02deaa2f 100644 --- a/windows/client-management/mdm/policy-csp-mixedreality.md +++ b/windows/client-management/mdm/policy-csp-mixedreality.md @@ -7,7 +7,7 @@ ms.topic: article ms.prod: w10 ms.technology: windows author: dansimp -ms.date: 10/12/2021 +ms.date: 1/31/2022 ms.reviewer: manager: dansimp --- @@ -99,6 +99,7 @@ The OMA-URI of new policy `./Device/Vendor/MSFT/Policy/Config/MixedReality/AutoL String value + - User with the same email address will have autologon enabled. On a device where this policy is configured, the user specified in the policy will need to log-on at least once. Subsequent reboots of the device after the first logon will have the specified user automatically logged on. Only a single autologon user is supported. Once enabled, the automatically logged on user will not be able to log out manually. To log-on as a different user, the policy must first be disabled. @@ -129,6 +130,8 @@ This policy setting controls for how many days Azure AD group membership cache i +- Integer value + Supported values are 0-60. The default value is 0 (day) and maximum value is 60 (days). @@ -167,6 +170,8 @@ This policy setting controls if pressing the brightness button changes the brigh +- Boolean value + The following list shows the supported values: - 0 - False (Default) @@ -208,7 +213,7 @@ This policy controls the behavior of moving platform feature on Hololens 2, that -Integer +- Integer value - 0 (Default) - Last set user's preference. Initial state is OFF and after that user's preference is persisted across reboots and is used to initialize the system. - 1 Force off - Moving platform is disabled and cannot be changed by user. @@ -250,6 +255,8 @@ This policy setting controls when and if diagnostic logs can be collected using +- Integer value + The following list shows the supported values: - 0 - Disabled @@ -292,6 +299,8 @@ This policy configures behavior of HUP to determine, which algorithm to use for +- Boolean value + The following list shows the supported values: - 0 - Feature – Default feature based / SLAM-based tracker (Default) @@ -333,6 +342,8 @@ This policy setting controls whether microphone on HoloLens 2 is disabled or not +- Boolean value + The following list shows the supported values: - 0 - False (Default) @@ -374,6 +385,8 @@ This policy setting controls if pressing the volume button changes the volume or +- Boolean value + The following list shows the supported values: - 0 - False (Default) @@ -415,6 +428,8 @@ This policy controls whether a visitor user will be automatically logged in. Vis +- Boolean value + The following list shows the supported values: - 0 Disabled (Default) From 0f987bab7cc43bdc77d8466b73ef54067bc2d557 Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Wed, 2 Feb 2022 10:21:49 -0800 Subject: [PATCH 08/12] Update event-id-explanations.md --- .../event-id-explanations.md | 71 ++++++++++--------- 1 file changed, 36 insertions(+), 35 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md index 9acce652d1..402cadf606 100644 --- a/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md +++ b/windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md @@ -11,10 +11,10 @@ ms.localizationpriority: medium audience: ITPro ms.collection: M365-security-compliance author: jsuther1974 -ms.reviewer: isbrahm +ms.reviewer: jogeurte ms.author: dansimp manager: dansimp -ms.date: 06/02/2021 +ms.date: 02/01/2022 ms.technology: windows-sec --- @@ -22,71 +22,71 @@ ms.technology: windows-sec A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either enforced or audit mode. These events are generated under two locations: -- Event IDs beginning with 30 appear in **Applications and Services logs** > **Microsoft** > **Windows** > **CodeIntegrity** > **Operational** +- Events about WDAC policy activation and the control of executables, dlls, and drivers appear in **Applications and Services logs** > **Microsoft** > **Windows** > **CodeIntegrity** > **Operational** -- Event IDs beginning with 80 appear in **Applications and Services logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script** +- Events about the control of MSI installers, scripts, and COM objects appear in **Applications and Services logs** > **Microsoft** > **Windows** > **AppLocker** > **MSI and Script** > [!NOTE] -> These event IDs are not applicable on Windows Server Core edition. +> These event IDs are not included on Windows Server Core edition. -## Microsoft Windows CodeIntegrity Operational log event IDs +## WDAC events found in the Microsoft Windows CodeIntegrity Operational log | Event ID | Explanation | |--------|-----------| -| 3076 | Audit executable/dll file | -| 3077 | Block executable/dll file | -| 3089 | Signing information event correlated with either a 3076 or 3077 event. One 3089 event is generated for each signature of a file. Contains the total number of signatures on a file and an index as to which signature it is. Unsigned files will generate a single 3089 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". | -| 3099 | Indicates that a policy has been loaded | +| 3004 | This event isn't common and may occur with or without a WDAC policy present. It typically indicates a kernel driver tried to load with an invalid signature. For example, the file may not be WHQL-signed on a system where WHQL is required. | +| 3033 | This event isn't common. It often means the file's signature is revoked or expired. Try using option *20 Enabled:Revoked Expired As Unsigned* in your policy along with a non-signature rule (for example, hash) to address issues with revoked or expired certs. | +| 3034 | This event isn't common. It is the audit mode equivalent of event 3033 described above. | +| 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. | +| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. | +| 3089 | This event contains signature information for files that were blocked or would have been blocked by WDAC. One 3089 event is created for each signature of a file. The event shows the total number of signatures found and an index value to identify the current signature. Unsigned files produce a single 3089 event with TotalSignatureCount 0. 3089 events are correlated with 3004, 3033, 3034, 3076 and 3077 events. You can match the events using the "Correlation ActivityID" found in the "System" portion of the event. | +| 3099 | Indicates that a policy has been loaded. This event also includes information about the policy options that were specified by the policy. Refer to the | -## Microsoft Windows AppLocker MSI and Script log event IDs +## WDAC events found in the Microsoft Windows AppLocker MSI and Script log | Event ID | Explanation | |--------|-----------| -| 8028 | Audit script/MSI file generated by Windows LockDown Policy (WLDP) being called by the script hosts themselves. Note: there is no WDAC enforcement on third-party script hosts. | -| 8029 | Block script/MSI file | +| 8028 | This event indicates that a script host, such as PowerShell, queried WDAC about a file the script host was about to run. Since the WDAC policy was in audit mode, the script or MSI file should have run. Some script hosts may have additional information in their logs. Note: Most third-party script hosts do not integrate with WDAC. Consider the risks from unverified scripts when choosing which script hosts you allow to run. | +| 8029 | This event is the enforcement mode equivalent of event 8028 described above. Note: While this event says that a script was blocked, the actual script enforcement behavior is implemented by the script host. The script host may allow the file to run with restrictions and not block the file outright. For example, PowerShell will allow a script to run but only in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes.md). | | 8036| COM object was blocked. To learn more about COM object authorization, see [Allow COM object registration in a Windows Defender Application Control policy](allow-com-object-registration-in-windows-defender-application-control-policy.md). | -| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. Correlated in the "System" portion of the event data under "Correlation ActivityID". | +| 8038 | Signing information event correlated with either an 8028 or 8029 event. One 8038 event is generated for each signature of a script file. Contains the total number of signatures on a script file and an index as to which signature it is. Unsigned script files will generate a single 8038 event with TotalSignatureCount 0. 8038 events are correlated with 8028 and 8029 events and can be matched using the "Correlation ActivityID" found in the "System" portion of the event. | -## Optional Intelligent Security Graph (ISG) or Managed Installer (MI) diagnostic events +## Diagnostic events for Intelligent Security Graph (ISG) and Managed Installer (MI) -If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092 events to provide more diagnostic information. +Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or MI option is enabled by any WDAC policy. These events can help you debug why something was allowed/denied based on managed installer or ISG. These events do not necessarily indicate a problem but should be reviewed in context with other events like 3076 or 3077 described above. | Event ID | Explanation | |--------|---------| -| 3090 | Allow executable/dll file | -| 3091 | Audit executable/dll file | -| 3092 | Block executable/dll file | +| 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. | +| 3091 | This event indicates that a file did not have ISG or managed installer authorization and the policy is in audit mode. | +| 3092 | This event is the enforcement mode equivalent of 3091. | -3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy, regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker template that appears in the event should indicate why the binary passed/failed. Only one event is generated per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated. +The above events are reported per active policy on the system, so you may see multiple events for the same file. -### SmartLocker template +### ISG and MI diagnostic event details -Below are the fields that help to diagnose what a 3090, 3091, or 3092 event indicates. +The following information is found in the details for 3090, 3091, and 3092 events. | Name | Explanation | |------|------| -| StatusCode | STATUS_SUCCESS indicates a binary passed the active WDAC policies. If so, a 3090 event is generated. If not, a 3091 event is generated if the blocking policy is in audit mode, and a 3092 event is generated if the policy is in enforce mode. | -| ManagedInstallerEnabled | Policy trusts a MI | -| PassesManagedInstaller | File originated from a trusted MI | -| SmartlockerEnabled | Policy trusts the ISG | -| PassesSmartlocker | File had positive reputation | +| ManagedInstallerEnabled | Indicates whether the specified policy enables managed installer trust | +| PassesManagedInstaller | Indicates whether the file originated from a MI | +| SmartlockerEnabled | Indicates whether the specified policy enables ISG trust | +| PassesSmartlocker | Indicates whether the file had positive reputation according to the ISG | | AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode | +| PolicyName | The name of the policy to which the event applies | ### Enabling ISG and MI diagnostic events -In order to enable 3091 audit events and 3092 block events, you must create a TestFlags regkey with a value of 0x100. You can do so using the following PowerShell command: - -```powershell -reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x100 -``` - -To enable 3090 allow events, and 3091 and 3092 events, you must instead create a TestFlags regkey with a value of 0x300. You can do so using the following PowerShell command: +To enable 3090 allow events, create a TestFlags regkey with a value of 0x300 as shown in the following PowerShell command. Then restart your computer. ```powershell reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300 ``` -## System Integrity Policy Options +3091 and 3092 events are inactive on some versions of Windows. The above steps will also turn on those events. + +## Event ID 3099 Options + The WDAC policy rule-option values can be derived from the "Options" field in the Details section of the Code integrity 3099 event. To parse the values, first convert the hex value to binary. Next, use the bit addresses and their values from the table below to determine the state of each [policy rule-option](/select-types-of-rules-to-create#table-1-windows-defender-application-control-policy---rule-options). | Bit Address | Policy Rule Option | @@ -113,6 +113,7 @@ The WDAC policy rule-option values can be derived from the "Options" field in th | 28 | `Enabled:Update Policy No Reboot` | ## Appendix + A list of other relevant event IDs and their corresponding description. | Event ID | Description | From 218d85c22cd5b2b4f1d826bb14f75842672c4daf Mon Sep 17 00:00:00 2001 From: Rafal Sosnowski <51166236+rafals2@users.noreply.github.com> Date: Thu, 3 Feb 2022 11:39:09 -0800 Subject: [PATCH 09/12] Update bitlocker-csp.md updated the part for encryption type with non-silent / silent enablement --- windows/client-management/mdm/bitlocker-csp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/client-management/mdm/bitlocker-csp.md b/windows/client-management/mdm/bitlocker-csp.md index 4530da2896..cb39d3bcd2 100644 --- a/windows/client-management/mdm/bitlocker-csp.md +++ b/windows/client-management/mdm/bitlocker-csp.md @@ -120,7 +120,7 @@ If you want to disable this policy, use the following SyncML: ``` > [!NOTE] -> Currently only used space encryption is supported when using this CSP. +> Currently full disk encryption is supported when using this CSP for silent encryption. For non-silent encryption, encryption type will depend on SystemDrivesEncryptionType and FixedDrivesEncryptionType configured on the device. From 532cf5e07512dbce85865026ff7ffe4c35d234b3 Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 4 Feb 2022 08:01:53 -0800 Subject: [PATCH 10/12] Fixed broken links --- .../configure-wdac-managed-installer.md | 2 +- .../create-wdac-deny-policy.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md b/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md index d0179f7f5e..92f944b419 100644 --- a/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md +++ b/windows/security/threat-protection/windows-defender-application-control/configure-wdac-managed-installer.md @@ -55,7 +55,7 @@ Ea Value Length: 7e ## Enabling managed installer logging events -Refer to [Understanding Application Control Events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) for information on enabling optional managed installer diagnostic events. +Refer to [Understanding Application Control Events](event-id-explanations.md#diagnostic-events-for-intelligent-security-graph-isg-and-managed-installer-mi) for information on enabling optional managed installer diagnostic events. ## Deploying the Managed Installer rule collection diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md index bc8dc984f9..4cac29413c 100644 --- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md +++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md @@ -109,7 +109,7 @@ The second option involves merging the blocklist with your existing WDAC policy, ## Best Practices -1. **Starting with Audit Mode Policies** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3077 block events](event-id-explanations.md#optional-intelligent-security-graph-isg-or-managed-installer-mi-diagnostic-events) to ensure only the applications you intended to block are being blocked. More information on monitoring block events via the Event Viewer logs and Advanced Hunting: [Managing and troubleshooting Windows Defender Application Control policies](windows-defender-application-control-operational-guide.md) +1. **Starting with Audit Mode Policies** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3077 block events](event-id-explanations.md) to ensure only the applications you intended to block are being blocked. More information on monitoring block events via the Event Viewer logs and Advanced Hunting: [Managing and troubleshooting Windows Defender Application Control policies](windows-defender-application-control-operational-guide.md) 2. **Recommended Deny Rules Types** - signer and file attribute rules are recommended from a security, manageability, and performance perspective. Hash rules should only be utilized where otherwise impossible. The hash of an application is updated for every new version released by the publisher, which quickly becomes impractical to manage and protect against new threats where the attacker is quickly iterating on the payload. Additionally, WDAC has optimized parsing of hash rules, but devices may see performance impacts at runtime evaluation when policies have tens of thousands or more hash rules. From a7bb138610900c3fa12410788d47132e2d06564b Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 4 Feb 2022 08:39:16 -0800 Subject: [PATCH 11/12] Fixed acrolinx warnings --- .../create-wdac-deny-policy.md | 49 +++++++++++-------- .../select-types-of-rules-to-create.md | 6 +-- 2 files changed, 32 insertions(+), 23 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md index 4cac29413c..8ff7c7eec6 100644 --- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md +++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-deny-policy.md @@ -20,21 +20,22 @@ ms.technology: windows-sec # Guidance on Creating WDAC Deny Policies -With Windows Defender Application Control (WDAC), you can create application control policies to explicitly deny specific drivers and applications, as well as signatures and certificates and file paths. +With Windows Defender Application Control (WDAC), you can create policies to explicitly deny specific drivers and applications. + +In this article we explain: -Topics this article will be discussing are: 1. File Rule Precedence Order 2. Adding Allow Rules 3. Singe Policy Considerations 4. Multiple Policy Considerations 5. Best Practices -6. Tutorial/Walkthrough +6. Tutorial ## File Rule Precedence Order -To create effective WDAC deny policies, it is crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order. +To create effective WDAC deny policies, it's crucial to understand how WDAC parses the policy. The WDAC engine evaluates files against the policy in the following order. -1. Explicit deny rules - if there is an explicit deny rule, do not process the rest of the rules; the file is untrusted. +1. Explicit deny rules - if any explicit deny rule exists for a file, it will not run even if other rules are created to try to allow it. Deny rules can use any [rule level](select-types-of-rules-to-create.md#windows-defender-application-control-file-rule-levels). Use the most specific rule level practical when creating deny rules to avoid blocking more than you intend. 2. Explicit allow rules. @@ -42,12 +43,11 @@ To create effective WDAC deny policies, it is crucial to understand how WDAC par 4. Lastly, WDAC will call the Intelligent Security Graph (ISG) to get reputation on file, if the policy has support for the ISG. -Explicit allow and deny rules encompass rules at any level (for example hash rules, signer rules path rules, attribute rules, or package family name rules). If there is an explicit deny rule, WDAC does not process any other rules, meaning a deny rule always takes precedence in the case where a deny and allow rule would be at odds. +5. If no rule exists for the file and it's not allowed based on ISG or MI, then the file is blocked implicitly. ## Interaction with Existing Policies -### Adding Allow Rules -In the scenario where there is not an explicit allow rule, there is not a managed installer or ISG EA and ISG is not configured, WDAC will block the file as there is nothing in the policy vouching for trust of the file. +### Adding Allow Rules If this deny policy is the only policy on the device, the following rule(s) need to be added to the policy in addition to the deny/block rules to trust for the driver files outside of the intended blocklisted ones: @@ -67,10 +67,11 @@ If this deny policy is the only policy on the device, the following rule(s) need ``` If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-option, the following section needs to be added to the policy in addition to the deny/block rules to trust for the driver and user mode files outside of the intended blocklisted ones: + ```xml - - + + @@ -89,8 +90,10 @@ If the policy enables user mode code integrity via the ***Enabled:UMCI*** rule-o ``` + ## Single Policy Considerations -If the set of deny rules is to be added into an existing policy with allow rules, then the above Allow All rules should not be added to the policy. Instead, the deny policy should be merged with the existing WDAC policy via the [WDAC Wizard](wdac-wizard-merging-policies.md) or using the following PowerShell command: + +If the set of deny rules is to be added into an existing policy with allow rules, then the above Allow All rules shouldn't be added to the policy. Instead, the deny policy should be merged with the existing WDAC policy via the [WDAC Wizard](wdac-wizard-merging-policies.md) or using the following PowerShell command: ```PowerShell $DenyPolicy = @@ -99,11 +102,12 @@ Merge-CIPolicy -PolicyPaths $ DenyPolicy, $ExistingPolicy -OutputFilePath $Exist ``` ## Multiple Policy Considerations -If you are currently using [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) on a device, there are two options for integrating the blocklist into your policy set. -(Recommended) The first option is to keep the blocklist as its own policy isolated from your allow policies as it is easier to manage. Since applications need to be [allowed by both WDAC policies to run on the device](deploy-multiple-windows-defender-application-control-policies.md#base-and-supplemental-policy-interaction), you will need to add the Allow All rule(s) to your deny policy. This will not override the set of applications allowed by WDAC illustrated by the following example: +If you're currently using [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) on a device, there are two options for integrating the blocklist into your policy set. -Policy 1 is an allowlist of Windows and Microsoft-signed applications. Policy 2 is our new deny policy, which blocks MaliciousApp.exe with the Allow All rules. MaliciousApp.exe will be blocked since there is an explicit block rule in Policy 2. Windows and Microsoft applications will be allowed since there is an explicit allow rule in Policy 1 and Policy 2 (due to the Allow All rules). All other applications, if not Windows and Microsoft signed, for example, ExampleApp.exe, will not be allowed as this application is only trusted by Policy 2 (due to the Allow All rules) and not Policy 1. +(Recommended) The first option is to keep the blocklist as its own policy isolated from your allow policies as it is easier to manage. Since applications need to be [allowed by both WDAC policies to run on the device](deploy-multiple-windows-defender-application-control-policies.md#base-and-supplemental-policy-interaction), you'll need to add the Allow All rule(s) to your deny policy. Doing so won't override the set of applications allowed by WDAC illustrated by the following example: + +Policy 1 is an allowlist of Windows and Microsoft-signed applications. Policy 2 is our new deny policy, which blocks MaliciousApp.exe with the Allow All rules. MaliciousApp.exe will be blocked since there's an explicit block rule in Policy 2. Windows and Microsoft applications will be allowed since there's an explicit allow rule in Policy 1 and Policy 2 (due to the Allow All rules). All other applications, if not Windows and Microsoft signed, for example, ExampleApp.exe, won't be allowed as this application is only trusted by Policy 2 (due to the Allow All rules) and not Policy 1. The second option involves merging the blocklist with your existing WDAC policy, regardless if the policy is an allowlist policy and contains allow and/or deny rules. @@ -111,38 +115,43 @@ The second option involves merging the blocklist with your existing WDAC policy, 1. **Starting with Audit Mode Policies** - as with all new policies, we recommend rolling out your new deny policy in Audit Mode and monitoring the [3077 block events](event-id-explanations.md) to ensure only the applications you intended to block are being blocked. More information on monitoring block events via the Event Viewer logs and Advanced Hunting: [Managing and troubleshooting Windows Defender Application Control policies](windows-defender-application-control-operational-guide.md) -2. **Recommended Deny Rules Types** - signer and file attribute rules are recommended from a security, manageability, and performance perspective. Hash rules should only be utilized where otherwise impossible. The hash of an application is updated for every new version released by the publisher, which quickly becomes impractical to manage and protect against new threats where the attacker is quickly iterating on the payload. Additionally, WDAC has optimized parsing of hash rules, but devices may see performance impacts at runtime evaluation when policies have tens of thousands or more hash rules. - +2. **Recommended Deny Rules Types** - signer and file attribute rules are recommended from a security, manageability, and performance perspective. Hash rules should only be utilized where otherwise impossible. The hash of an application is updated for every new version released by the publisher, which quickly becomes impractical to manage and protect against new threats where the attacker is quickly iterating on the payload. Additionally, WDAC has optimized parsing of hash rules, but devices may see performance impacts at runtime evaluation when policies have tens of thousands or more hash rules. ## Creating a Deny Policy Tutorial -Deny rules and policies can be created using the PowerShell cmdlets or the [WDAC Wizard](https://webapp-wdac-wizard.azurewebsites.net/). We recommend creating signer rules (PCACertificate, Publisher, and FilePublisher) wherever possible. In the cases of unsigned binaries, rules must be created on attributes of the file, such as the original filename, or the hash. +Deny rules and policies can be created using the PowerShell cmdlets or the [WDAC Wizard](https://webapp-wdac-wizard.azurewebsites.net/). We recommend creating signer rules (PCACertificate, Publisher, and FilePublisher) wherever possible. In the cases of unsigned binaries, rules must be created on attributes of the file, such as the original filename, or the hash. ### Software Publisher Based Deny Rule + ```Powershell $DenyRules += New-CIPolicyRule -Level FilePublisher -DriverFilePath -Deny -Fallback FileName,Hash ``` ### Software Attributes Based Deny Rule + ```Powershell $DenyRules += New-CIPolicyRule -Level FileName -DriverFilePath -Deny -Fallback Hash ``` ### Hash Based Deny Rule + ```PowerShell New-CIPolicyRule -Level Hash -DriverFilePath -Deny ``` ### Adding Allow All Rules -If necessary, as in the cases listed above, [Allow All Rules](#adding-allow-rules) may need to be added to the policy. The Allow All rules can be manually added to the policy xml or by merging with the Allow All xml present on the client system in the WDAC template folder: + +If necessary, as in the cases listed above, [Allow All Rules](#adding-allow-rules) may need to be added to the policy. The Allow All rules can be manually added to the policy xml or by merging with the Allow All xml present on the client system in the WDAC template folder: ```PowerShell $DenyPolicy = $AllowAllPolicy = $Env:windir + "\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml" Merge-CIPolicy -PolicyPaths $DenyPolicy, $AllowAllPolicy -OutputFilePath $DenyPolicy ``` + ### Deploying the Deny Policy -Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options: + +Policies should be thoroughly evaluated and first rolled out in audit mode before strict enforcement. Policies can be deployed via multiple options: 1. Mobile Device Management (MDM): [Deploy WDAC policies using Mobile Device Management (MDM) (Windows)](deploy-windows-defender-application-control-policies-using-intune.md) @@ -150,4 +159,4 @@ Policies should be thoroughly evaluated and first rolled out in audit mode befor 3. Scripting [Deploy Windows Defender Application Control (WDAC) policies using script (Windows)](deployment/deploy-wdac-policies-with-script.md) -4. Group Policy: [Deploy WDAC policies via Group Policy (Windows)](deploy-windows-defender-application-control-policies-using-group-policy.md) \ No newline at end of file +4. Group Policy: [Deploy WDAC policies via Group Policy (Windows)](deploy-windows-defender-application-control-policies-using-group-policy.md) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index a4b02ea6ac..146ad43afe 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -22,9 +22,9 @@ ms.technology: windows-sec **Applies to:** -- Windows 10 -- Windows 11 -- Windows Server 2016 and above +- Windows 10 +- Windows 11 +- Windows Server 2016 and above >[!NOTE] >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). From ccb4c783d4b4fd1b91676ec0da3aa35591bedf45 Mon Sep 17 00:00:00 2001 From: Denise Vangel-MSFT Date: Fri, 4 Feb 2022 09:03:28 -0800 Subject: [PATCH 12/12] Update bitlocker-csp.md --- windows/client-management/mdm/bitlocker-csp.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/windows/client-management/mdm/bitlocker-csp.md b/windows/client-management/mdm/bitlocker-csp.md index cb39d3bcd2..6b83e9c150 100644 --- a/windows/client-management/mdm/bitlocker-csp.md +++ b/windows/client-management/mdm/bitlocker-csp.md @@ -7,7 +7,7 @@ ms.prod: w10 ms.technology: windows author: dansimp ms.localizationpriority: medium -ms.date: 04/16/2020 +ms.date: 02/04/2022 ms.reviewer: manager: dansimp ms.collection: highpri @@ -21,7 +21,7 @@ The BitLocker configuration service provider (CSP) is used by the enterprise to > > You must send all the settings together in a single SyncML to be effective. -A Get operation on any of the settings, except for RequireDeviceEncryption and RequireStorageCardEncryption, returns +A `Get` operation on any of the settings, except for `RequireDeviceEncryption` and `RequireStorageCardEncryption`, returns the setting configured by the admin. For RequireDeviceEncryption and RequireStorageCardEncryption, the Get operation returns the actual status of enforcement to the admin, such as if Trusted Platform Module (TPM) protection is required and if encryption is required. And if the device has BitLocker enabled but with password protector, the status reported is 0. A Get operation on RequireDeviceEncryption does not verify that a minimum PIN length is enforced (SystemDrivesMinimumPINLength). @@ -120,7 +120,7 @@ If you want to disable this policy, use the following SyncML: ``` > [!NOTE] -> Currently full disk encryption is supported when using this CSP for silent encryption. For non-silent encryption, encryption type will depend on SystemDrivesEncryptionType and FixedDrivesEncryptionType configured on the device. +> Currently full disk encryption is supported when using this CSP for silent encryption. For non-silent encryption, encryption type will depend on `SystemDrivesEncryptionType` and `FixedDrivesEncryptionType` configured on the device.