diff --git a/windows/client-management/mdm/policy-csp-localusersandgroups.md b/windows/client-management/mdm/policy-csp-localusersandgroups.md index 68938fa3b7..5f21ba8658 100644 --- a/windows/client-management/mdm/policy-csp-localusersandgroups.md +++ b/windows/client-management/mdm/policy-csp-localusersandgroups.md @@ -14,9 +14,6 @@ manager: dansimp # Policy CSP - LocalUsersAndGroups -> [!WARNING] -> Some information relates to prereleased products, which may be substantially modified before it's commercially released. Microsoft makes no warranties, expressed or implied, concerning the information provided here. -
diff --git a/windows/security/threat-protection/auditing/audit-other-privilege-use-events.md b/windows/security/threat-protection/auditing/audit-other-privilege-use-events.md index 87c74a4998..7e8dea77c3 100644 --- a/windows/security/threat-protection/auditing/audit-other-privilege-use-events.md +++ b/windows/security/threat-protection/auditing/audit-other-privilege-use-events.md @@ -21,8 +21,7 @@ ms.technology: mde - Windows 10 - Windows Server 2016 - -This auditing subcategory should not have any events in it, but for some reason Success auditing will enable generation of event 4985(S): The state of a transaction has changed. +This auditing subcategory should not have any events in it, but for some reason Success auditing will enable the generation of event [4985(S): The state of a transaction has changed](/windows/security/threat-protection/auditing/event-4985). | Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | |-------------------|-----------------|-----------------|------------------|------------------|-----------------------------------------------------------------------| @@ -35,4 +34,3 @@ This auditing subcategory should not have any events in it, but for some reason - [4985](event-4985.md)(S): The state of a transaction has changed. - diff --git a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md index 73357d0809..c5fd34e870 100644 --- a/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md +++ b/windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md @@ -35,6 +35,8 @@ MEMCM includes native support for WDAC, which allows you to configure Windows 10 - [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG) - [Optional] Apps and executables already installed in admin-definable folder locations that MEMCM will allow through a one-time scan during policy creation on managed endpoints. +Note that MEMCM does not remove policies once deployed. To stop enforcement, you should switch the policy to audit mode, which will produce the same effect. If you want to disable WDAC altogether (including audit mode), you can deploy a script to delete the policy file from disk, and either trigger a reboot or wait for the next reboot. + For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager) ## Deploy custom WDAC policies using Packages/Programs or Task Sequences 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 c3a43bac96..ee556ecef8 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 @@ -120,6 +120,10 @@ To create the WDAC policy, they build a reference server on their standard hardw As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version. +## File rule precedence order + +WDAC has a built-in file rule conflict logic that translates to precedence order. It will first processes all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these exists, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md). + ## More information about filepath rules Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.