deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #5305 from MicrosoftDocs/repo_sync_working_branch

Browse Source 
Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
Diana Hanson 2021-06-23 12:25:49 -06:00 committed by GitHub
commit 33abbd37ea
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
windows/client-management/mdm/policy-csp-localusersandgroups.md
View File

@ -14,9 +14,6 @@ manager: dansimp
# Policy CSP - LocalUsersAndGroups # 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.
<hr/> <hr/>
<!--Policies--> <!--Policies-->

4
windows/security/threat-protection/auditing/audit-other-privilege-use-events.md
View File

@ -21,8 +21,7 @@ ms.technology: mde
- Windows 10 - Windows 10
- Windows Server 2016 - Windows Server 2016
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).
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.
| Computer Type | General Success | General Failure | Stronger Success | Stronger Failure | Comments | | 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. - [4985](event-4985.md)(S): The state of a transaction has changed.

2
windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-with-memcm.md
View File

@ -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] 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. - [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) 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 ## Deploy custom WDAC policies using Packages/Programs or Task Sequences

4
windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md
View File

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