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

Merge pull request #6947 from MicrosoftDocs/main

Browse Source 
Publish 08/12/2022 3:30 PM PT
This commit is contained in:
Angela Fleischmann 2022-08-12 17:06:36 -06:00 committed by GitHub
commit dbed7a708c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 29 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md
View File

@ -33,14 +33,14 @@ Unenrolling from Windows Autopatch requires manual actions from both you and fro
| Responsibility | Description | | Responsibility | Description |
| ----- | ----- | | ----- | ----- |
| Windows Autopatch data | Windows Autopatch will delete user data that is within the Windows Autopatch service. We won’t make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../references/windows-autopatch-privacy.md). | | Windows Autopatch data | Windows Autopatch will delete user data that is within the Windows Autopatch service. We won’t make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../references/windows-autopatch-privacy.md). |
| Deregistering devices | Windows Autopatch will deregister all devices previously registered with the service. Only the Windows Autopatch device record will be deleted. We will not delete Microsoft Intune and/or Azure Active Directory device records. For more information, see [Deregister a device](/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices). | | Deregistering devices | Windows Autopatch will deregister all devices previously registered with the service. Only the Windows Autopatch device record will be deleted. We won't delete Microsoft Intune and/or Azure Active Directory device records. For more information, see [Deregister a device](/windows/deployment/windows-autopatch/operate/windows-autopatch-deregister-devices). |
## Your responsibilities after unenrolling your tenant ## Your responsibilities after unenrolling your tenant
| Responsibility | Description | | Responsibility | Description |
| ----- | ----- | | ----- | ----- |
| Updates | After the Windows Autopatch service is unenrolled, we’ll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. | | Updates | After the Windows Autopatch service is unenrolled, we’ll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. |
| Optional Windows Autopatch configuration | Windows Autopatch won’t remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant unenrollment. If you don’t wish to use these policies for your devices after unenrollment, you may safely delete them. | | Optional Windows Autopatch configuration | Windows Autopatch won’t remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant unenrollment. If you don’t wish to use these policies for your devices after unenrollment, you may safely delete them. For more information, see [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). |
| Windows Autopatch cloud service accounts | After unenrollment, you may safely remove the cloud service accounts created during the enrollment process. The accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> | | Windows Autopatch cloud service accounts | After unenrollment, you may safely remove the cloud service accounts created during the enrollment process. The accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> |
| Conditional access policy | After unenrollment, you may safely remove the **Modern Workplace – Secure Workstation** conditional access policy. | | Conditional access policy | After unenrollment, you may safely remove the **Modern Workplace – Secure Workstation** conditional access policy. |
| Microsoft Endpoint Manager roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. | | Microsoft Endpoint Manager roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. |

41
windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-dynamic-code-security.md
View File

@ -1,6 +1,6 @@
--- ---
title: Windows Defender Application Control and .NET Hardening (Windows) title: Windows Defender Application Control and .NET (Windows)
description: Dynamic Code Security is an application control feature that can verify code loaded by .NET at runtime. description: Understand how WDAC and .NET work together and use Dynamic Code Security to verify code loaded by .NET at runtime.
keywords: security, malware keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security ms.prod: m365-security
@ -11,30 +11,43 @@ ms.localizationpriority: medium
audience: ITPro audience: ITPro
ms.collection: M365-security-compliance ms.collection: M365-security-compliance
author: jsuther1974 author: jsuther1974
ms.reviewer: isbrahm ms.reviewer: jogeurte
ms.author: dansimp ms.author: dansimp
manager: dansimp manager: dansimp
ms.date: 06/15/2022 ms.date: 08/10/2022
ms.technology: windows-sec ms.technology: windows-sec
--- ---
# Windows Defender Application Control and .NET hardening # Windows Defender Application Control (WDAC) and .NET
Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and scripts that are allowed to run to those sets approved by an organization. .NET apps (as written in a high-level language like C#) are compiled to an Intermediate Language (IL). IL is a compact code format that can be supported on any operating system or architecture. Most .NET apps use APIs that are supported in multiple environments, requiring only the .NET runtime to run. IL needs to be compiled to native code in order to execute on a CPU, for example Arm64 or x64. When .NET compiles IL to native image (NI) on a device with a WDAC user mode policy, it first checks whether the original IL file passes the current WDAC policies. If so, .NET sets an NTFS extended attribute (EA) on the generated NI file so that WDAC knows to trust it as well. When the .NET app runs, WDAC sees the EA on the NI file and allows it.
Security researchers have found that some .NET applications may be used to circumvent those controls by using .NET’s capabilities to load libraries from external sources or generate new code on the fly.
Beginning with Windows 10, version 1803, or Windows 11, Windows Defender Application Control features a new capability, called *Dynamic Code Security* to verify code loaded by .NET at runtime. The EA set on the NI file only applies to the currently active WDAC policies. If one of the active WDAC policies is updated or a new policy is applied, the EA on the NI file is invalidated. The next time the app runs, WDAC will block the NI file. .NET handles the block gracefully and will fall back to the original IL code. If the IL still passes the latest WDAC policies, then the app runs without any functional impact. Since the IL is now being compiled at runtime, you may notice a slight impact to performance of the app. When .NET must fall back to IL, .NET will also schedule a process to run at the next maintenance window to regenerate all NI files, thus reestablishing the WDAC EA for all code that passes the latest WDAC policies.
In some cases, if an NI file is blocked, you may see a "false positive" block event in the *CodeIntegrity - Operational* event log as described in [WDAC Admin Tips & Known Issues](/windows/security/threat-protection/windows-defender-application-control/operations/known-issues#net-native-images-may-generate-false-positive-block-events).
To mitigate any performance impact caused when the WDAC EA isn't valid or missing, use any of the following strategies:
1. Work with the app developer to pre-compile their NI and digitally sign it. Then, ensure your WDAC policies allow that signature;
2. Run *ngen.exe update* to force .NET to regenerate all NI files immediately after applying changes to your WDAC policies;
3. [Create and sign a catalog file](/windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control) for the native images
## WDAC and .NET hardening
Security researchers have found that some .NET capabilities that allow apps to load libraries from external sources or generate new code at runtime can be used to circumvent WDAC controls.
Beginning with Windows 10, version 1803, WDAC includes a new option, called *Dynamic Code Security* that works with .NET to verify code loaded at runtime.
When the Dynamic Code Security option is enabled, Application Control policy is applied to libraries that .NET loads from external sources. For example, any non-local sources, such as the internet or a network share. When the Dynamic Code Security option is enabled, Application Control policy is applied to libraries that .NET loads from external sources. For example, any non-local sources, such as the internet or a network share.
Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with. Additionally, it detects tampering in code generated to disk by .NET and blocks loading code that has been tampered with.
Dynamic Code Security isn't enabled by default because existing policies may not account for externally loaded libraries. Dynamic Code Security isn't enabled by default because existing policies may not account for externally loaded libraries.
Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled. Additionally, a few .NET loading features, including loading unsigned assemblies built with System.Reflection.Emit, aren't currently supported with Dynamic Code Security enabled.
Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy. Microsoft recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new libraries should be included in the policy.
Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/aspnet/web-forms/overview/older-versions-getting-started/deploying-web-site-projects/precompiling-your-website-cs) document for how to fix that. Additionally, customers can precompile for deployment only to prevent an allowed executable from being terminated because it tries to load unsigned dynamically generated code. See the "Precompiling for Deployment Only" section in the [ASP.NET Precompilation Overview](/previous-versions/aspnet/bb398860(v=vs.100)) document for how to fix that.
To enable Dynamic Code Security, add the following option to the `<Rules>` section of your policy: To enable Dynamic Code Security, add the following option to the `<Rules>` section of your WDAC policy:
```xml ```xml
<Rule> <Rule>