mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-15 14:57:23 +00:00
Merge branch 'master' into privacy-update-vb
This commit is contained in:
commit
21302878ff
@ -22,7 +22,7 @@ ms.technology: mde
|
|||||||
The threat landscape is continually evolving. While hackers are busy developing new techniques to breach enterprise networks by compromising workstations, phishing schemes remain one of the top ways to lure employees into social engineering attacks. Microsoft Defender Application Guard is designed to help prevent old, and newly emerging attacks, to help keep employees productive.
|
The threat landscape is continually evolving. While hackers are busy developing new techniques to breach enterprise networks by compromising workstations, phishing schemes remain one of the top ways to lure employees into social engineering attacks. Microsoft Defender Application Guard is designed to help prevent old, and newly emerging attacks, to help keep employees productive.
|
||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
>Microsoft Defender Application Guard is not supported on VMs and VDI environment. For testing and automation on non-production machines, you may enable WDAG on a VM by enabling Hyper-V nested virtualization on the host.
|
> Given the technological complexity, the security promise of Microsoft Defender Application Guard (MDAG) may not hold true on VMs and in VDI environments. Hence, MDAG is currently not officially supported on VMs and in VDI environments. However, for testing and automation purposes on non-production machines, you may enable MDAG on a VM by enabling Hyper-V nested virtualization on the host.
|
||||||
|
|
||||||
## Hardware requirements
|
## Hardware requirements
|
||||||
Your environment needs the following hardware to run Microsoft Defender Application Guard.
|
Your environment needs the following hardware to run Microsoft Defender Application Guard.
|
||||||
|
@ -14,7 +14,7 @@ manager: dansimp
|
|||||||
audience: ITPro
|
audience: ITPro
|
||||||
ms.collection: M365-security-compliance
|
ms.collection: M365-security-compliance
|
||||||
ms.topic: conceptual
|
ms.topic: conceptual
|
||||||
ms.date: 04/19/2017
|
ms.date: 05/19/2021
|
||||||
ms.technology: mde
|
ms.technology: mde
|
||||||
---
|
---
|
||||||
|
|
||||||
@ -100,6 +100,9 @@ Assign the **Deny access to this computer from the network** user right to the f
|
|||||||
|
|
||||||
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 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.
|
||||||
|
|
||||||
|
> [!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
|
### 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 are not negatively affected.
|
||||||
|
@ -32,7 +32,6 @@ This topic covers how to disable unsigned or signed WDAC policies.
|
|||||||
There may come a time when an administrator wants to disable a WDAC policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
|
There may come a time when an administrator wants to disable a WDAC policy. For unsigned WDAC policies, this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on the next computer restart:
|
||||||
|
|
||||||
- <EFI System Partition>\\Microsoft\\Boot\\
|
- <EFI System Partition>\\Microsoft\\Boot\\
|
||||||
|
|
||||||
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
||||||
|
|
||||||
Note that as of the Windows 10 May 2019 Update (1903), WDAC allows multiple policies to be deployed to a device. To fully disable WDAC when multiple policies are in effect, you must first disable each method being used to deploy a policy. Then delete the {Policy GUID}.cip policy files found in the \CIPolicies\Active subfolder under each of the paths listed above in addition to any SIPolicy.p7b file found in the root directory.
|
Note that as of the Windows 10 May 2019 Update (1903), WDAC allows multiple policies to be deployed to a device. To fully disable WDAC when multiple policies are in effect, you must first disable each method being used to deploy a policy. Then delete the {Policy GUID}.cip policy files found in the \CIPolicies\Active subfolder under each of the paths listed above in addition to any SIPolicy.p7b file found in the root directory.
|
||||||
@ -43,21 +42,22 @@ Signed policies protect Windows from administrative manipulation as well as malw
|
|||||||
|
|
||||||
> [!NOTE]
|
> [!NOTE]
|
||||||
> For reference, signed WDAC policies should be replaced and removed from the following locations:
|
> For reference, signed WDAC policies should be replaced and removed from the following locations:
|
||||||
|
>
|
||||||
- <EFI System Partition>\\Microsoft\\Boot\\
|
> * <EFI System Partition>\\Microsoft\\Boot\\
|
||||||
|
> * <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
||||||
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
|
||||||
|
|
||||||
|
|
||||||
1. Replace the existing policy with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
|
1. Replace the existing policy with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
|
||||||
|
|
||||||
> **Note** To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
|
> [!NOTE]
|
||||||
|
> To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
|
||||||
|
|
||||||
2. Restart the client computer.
|
2. Restart the client computer.
|
||||||
|
|
||||||
3. Verify that the new signed policy exists on the client.
|
3. Verify that the new signed policy exists on the client.
|
||||||
|
|
||||||
> **Note** If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
|
> [!NOTE]
|
||||||
|
> If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
|
||||||
|
|
||||||
4. Delete the new policy.
|
4. Delete the new policy.
|
||||||
|
|
||||||
@ -67,13 +67,15 @@ If the signed WDAC policy has been deployed using by using Group Policy, you mus
|
|||||||
|
|
||||||
1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
|
1. Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
|
||||||
|
|
||||||
> **Note** To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
|
> [!NOTE]
|
||||||
|
> To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
|
||||||
|
|
||||||
2. Restart the client computer.
|
2. Restart the client computer.
|
||||||
|
|
||||||
3. Verify that the new signed policy exists on the client.
|
3. Verify that the new signed policy exists on the client.
|
||||||
|
|
||||||
> **Note** If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
|
> [!NOTE]
|
||||||
|
> If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
|
||||||
|
|
||||||
4. Set the GPO to disabled.
|
4. Set the GPO to disabled.
|
||||||
|
|
||||||
@ -86,5 +88,4 @@ If the signed WDAC policy has been deployed using by using Group Policy, you mus
|
|||||||
There may be a time when signed WDAC policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
|
There may be a time when signed WDAC policies cause a boot failure. Because WDAC policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
|
||||||
|
|
||||||
- <EFI System Partition>\\Microsoft\\Boot\\
|
- <EFI System Partition>\\Microsoft\\Boot\\
|
||||||
|
|
||||||
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
- <OS Volume>\\Windows\\System32\\CodeIntegrity\\
|
||||||
|
Loading…
x
Reference in New Issue
Block a user