mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
Merge pull request #2125 from MicrosoftDocs/repo_sync_working_branch
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:
commit
23499ef951
@ -12,7 +12,7 @@ ms.localizationpriority: medium
|
|||||||
author: denisebmsft
|
author: denisebmsft
|
||||||
ms.author: deniseb
|
ms.author: deniseb
|
||||||
ms.custom: nextgen
|
ms.custom: nextgen
|
||||||
ms.date: 09/03/2018
|
ms.date: 02/24/2020
|
||||||
ms.reviewer:
|
ms.reviewer:
|
||||||
manager: dansimp
|
manager: dansimp
|
||||||
---
|
---
|
||||||
@ -30,13 +30,13 @@ For a list of the cmdlets and their functions and available parameters, see the
|
|||||||
PowerShell cmdlets are most useful in Windows Server environments that don't rely on a graphical user interface (GUI) to configure software.
|
PowerShell cmdlets are most useful in Windows Server environments that don't rely on a graphical user interface (GUI) to configure software.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> PowerShell cmdlets should not be used as a replacement for a full network policy management infrastructure, such as [Microsoft Endpoint Configuration Manager](https://docs.microsoft.com/configmgr), [Group Policy Management Console](https://technet.microsoft.com/library/cc731212.aspx), or [Windows Defender Antivirus Group Policy ADMX templates](https://support.microsoft.com/kb/927367).
|
> PowerShell cmdlets should not be used as a replacement for a full network policy management infrastructure, such as [Microsoft Endpoint Configuration Manager](https://docs.microsoft.com/configmgr), [Group Policy Management Console](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731212(v=ws.11)), or [Windows Defender Antivirus Group Policy ADMX templates](https://www.microsoft.com/download/100591).
|
||||||
|
|
||||||
Changes made with PowerShell will affect local settings on the endpoint where the changes are deployed or made. This means that deployments of policy with Group Policy, Microsoft Endpoint Configuration Manager, or Microsoft Intune can overwrite changes made with PowerShell.
|
Changes made with PowerShell will affect local settings on the endpoint where the changes are deployed or made. This means that deployments of policy with Group Policy, Microsoft Endpoint Configuration Manager, or Microsoft Intune can overwrite changes made with PowerShell.
|
||||||
|
|
||||||
You can [configure which settings can be overridden locally with local policy overrides](configure-local-policy-overrides-windows-defender-antivirus.md).
|
You can [configure which settings can be overridden locally with local policy overrides](configure-local-policy-overrides-windows-defender-antivirus.md).
|
||||||
|
|
||||||
PowerShell is typically installed under the folder _%SystemRoot%\system32\WindowsPowerShell_.
|
PowerShell is typically installed under the folder `%SystemRoot%\system32\WindowsPowerShell`.
|
||||||
|
|
||||||
## Use Windows Defender Antivirus PowerShell cmdlets
|
## Use Windows Defender Antivirus PowerShell cmdlets
|
||||||
|
|
||||||
@ -45,7 +45,7 @@ PowerShell is typically installed under the folder _%SystemRoot%\system32\Window
|
|||||||
3. Enter the PowerShell command and any parameters.
|
3. Enter the PowerShell command and any parameters.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> You may need to open an administrator-level version of PowerShell. Right-click the item in the Start menu, click **Run as administrator** and click **Yes** at the permissions prompt.
|
> You may need to open PowerShell in administrator mode. Right-click the item in the Start menu, click **Run as administrator** and click **Yes** at the permissions prompt.
|
||||||
|
|
||||||
To open online help for any of the cmdlets type the following:
|
To open online help for any of the cmdlets type the following:
|
||||||
|
|
||||||
|
@ -14,7 +14,7 @@ author: jsuther1974
|
|||||||
ms.reviewer: isbrahm
|
ms.reviewer: isbrahm
|
||||||
ms.author: dansimp
|
ms.author: dansimp
|
||||||
manager: dansimp
|
manager: dansimp
|
||||||
ms.date: 04/20/2018
|
ms.date: 02/24/2020
|
||||||
---
|
---
|
||||||
|
|
||||||
# Understand WDAC policy rules and file rules
|
# Understand WDAC policy rules and file rules
|
||||||
@ -28,7 +28,7 @@ Windows Defender Application Control (WDAC) provides control over a computer run
|
|||||||
|
|
||||||
## Windows Defender Application Control policy rules
|
## Windows Defender Application Control policy rules
|
||||||
|
|
||||||
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). Note the following examples of how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
|
To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
|
||||||
|
|
||||||
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
|
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
|
||||||
|
|
||||||
@ -120,9 +120,9 @@ There is a defined list of SIDs which WDAC recognizes as admins. If a filepath a
|
|||||||
WDAC's list of well-known admin SIDs are: <br>
|
WDAC's list of well-known admin SIDs are: <br>
|
||||||
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
|
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
|
||||||
|
|
||||||
When generating filepath rules using [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards and include them in your [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) scan using the -Rules switch.
|
When generating filepath rules using [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](https://docs.microsoft.com/powershell/module/configci/new-cipolicyrule#parameters) switch.
|
||||||
|
|
||||||
Wildcards can be used at the beginning or end of a path rule: only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\* would include C:\foo\\* ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. \*\bar.exe would allow C:\bar.exe and C:\foo\bar.exe). Wildcards in the middle of a path are not supported (ex. C:\\*\foo.exe). Without a wildcard, the rule will allow only a specific file (ex. C:\foo\bar.exe). <br> Supported macros: %WINDIR%, %SYSTEM32%, %OSDRIVE%.
|
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\\*` would include `C:\foo\\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`). <br/> The use of macros is also supported and useful in scenarios where the system drive is different from the `C:\` drive. Supported macros: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
|
> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
|
||||||
|
@ -38,9 +38,9 @@ After that initial download and installation, the WDAC component will check for
|
|||||||
The reputation data on the client is rechecked periodically and enterprises can also specify that any cached reputation results are flushed on reboot.
|
The reputation data on the client is rechecked periodically and enterprises can also specify that any cached reputation results are flushed on reboot.
|
||||||
|
|
||||||
>[!NOTE]
|
>[!NOTE]
|
||||||
>Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, for example custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Configuration Manager and Microsoft Intune can be used to create and push a WDAC policy to your client machines.
|
>Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Configuration Manager and Microsoft Intune can be used to create and push a WDAC policy to your client machines.
|
||||||
|
|
||||||
Other examples of WDAC policies are available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy).
|
Other examples of WDAC policies are available in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy).
|
||||||
|
|
||||||
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
|
## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
|
||||||
|
|
||||||
@ -81,7 +81,7 @@ In order to enable trust for executables based on classifications in the ISG, th
|
|||||||
|
|
||||||
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
|
### Enable the necessary services to allow WDAC to use the ISG correctly on the client
|
||||||
|
|
||||||
In order for the heuristics used by the ISG to function properly, a number of component in Windows need to be enabled. The easiest way to do this is to run the appidtel executable in c:\windows\system32.
|
In order for the heuristics used by the ISG to function properly, a number of component in Windows need to be enabled. The easiest way to do this is to run the appidtel executable in `c:\windows\system32`.
|
||||||
|
|
||||||
```
|
```
|
||||||
appidtel start
|
appidtel start
|
||||||
|
Loading…
x
Reference in New Issue
Block a user