diff --git a/windows/security/identity-protection/hello-for-business/hello-faq.yml b/windows/security/identity-protection/hello-for-business/hello-faq.yml index 2f77d6ba0e..a0c26cb08e 100644 --- a/windows/security/identity-protection/hello-for-business/hello-faq.yml +++ b/windows/security/identity-protection/hello-for-business/hello-faq.yml @@ -31,6 +31,7 @@ sections: answer: | Windows Hello for Business cloud trust is a new trust model that is currently in preview. This trust model will enable Windows Hello for Business deployment using the infrastructure introduced for supporting [security key sign-in on Hybrid Azure AD-joined devices and on-premises resource access on Azure AD Joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). Cloud trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [Hybrid Cloud Trust Deployment (Preview)](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust). + - question: What about virtual smart cards? answer: | Windows Hello for Business is the modern, two-factor credential for Windows 10. Microsoft will be deprecating virtual smart cards in the future, but no date is set at this time. Customers using Windows 10 and virtual smart cards should move to Windows Hello for Business. Microsoft will publish the date early to ensure customers have adequate lead time to move to Windows Hello for Business. Microsoft recommends that new Windows 10 deployments use Windows Hello for Business. Virtual smart cards remain supported for Windows 7 and Windows 8. @@ -42,6 +43,7 @@ sections: - question: Can I use Windows Hello for Business key trust and RDP? answer: | Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Windows Defender Remote Credential Guard](../remote-credential-guard.md) without deploying certificates. + - question: Can I deploy Windows Hello for Business by using Microsoft Endpoint Configuration Manager? answer: | @@ -57,9 +59,8 @@ sections: - question: How can a PIN be more secure than a password? answer: | - The Windows Hello for Business PIN isn't a symmetric key, whereas a password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key. - - The statement "PIN is stronger than Password" isn't directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multi-factor Unlock](feature-multifactor-unlock.md) feature. + When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key. + The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature. - question: How does Windows Hello for Business work with Azure AD registered devices? answer: | @@ -123,9 +124,9 @@ sections: - question: What's the difference between non-destructive and destructive PIN reset? answer: | - Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 Enterprise and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md). + Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Azure Active Directory can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md). - Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 Enterprise can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid deployments, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services. + Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For hybrid Azure Active Directory joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services. - question: | Which is better or more secure, key trust or certificate trust? @@ -149,7 +150,31 @@ sections: - question: Is Windows Hello for Business multi-factor authentication? answer: | Windows Hello for Business is two-factor authentication based on the observed authentication factors of: something you have, something you know, and something that's part of you. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the "something you know" authentication factor with the "something that is part of you" factor, with the assurances that users can fall back to the "something you know factor". - + + - question: Where is Windows Hello biometrics data stored? + answer: | + When you enroll in Windows Hello, a representation of your face called an enrollment profile is created more information can be found on [Windows Hello face authentication](https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn’t roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details see [Windows Hello biometrics in the enterprise](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored). + + - question: What is the format used to store Windows Hello biometrics data on the device? + answer: | + Windows Hello biometrics data is stored on the device as an encrypted template database. The data from the biometrics sensor (e.g., face camera or fingerprint reader) creates a data representation—or graph—that is then encrypted before it’s stored on the device. Each biometrics sensor on the device which is used by Windows Hello (face or fingerprint) will have its own biometric database file where template data is stored. Each biometrics database file is encrypted with unique, randomly generated key that is encrypted to the system using AES encryption producing an SHA256 hash. + + - question: Who has access on Windows Hello biometrics data? + answer: | + Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it. + + - question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication? + answer: | + Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method (e.g. pin). Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start** > **Settings** > **Accounts** > **Sign-in** options. Or just click on **Go to Sign-in options**. To enroll into Windows Hello, user can go to **Start** > **Settings** > **Accounts** > **Sign-in** options, select the Windows Hello method that they want to set up, and then select **Set up**. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can by policy request users to enroll into Windows Hello during autopilot or during initial setup of the device. Admins can disallow users to enroll into biometrics via Windows hello for business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users. + + - question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication? + answer: | + To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start** > **Settings** > **Accounts** > **Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will unenroll the user from Windows Hello biometrics auth and will also delete the associated biometrics template database file. For more details see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/en-us/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy). + + - question: What about any diagnostic data coming out when WHFB is enabled? + answer: | + To help us keep things working properly, to help detect and prevent fraud, and to continue improving Windows Hello, we collect diagnostic data about how people use Windows Hello. For example, data about whether people sign in with their face, iris, fingerprint, or PIN; the number of times they use it; and whether it works or not is all valuable information that helps us build a better product. The data is pseudonymized, does not include biometric information, and is encrypted before it is transmitted to Microsoft. You can choose to stop sending diagnostic data to Microsoft at any time. [Learn more about diagnostic data in Windows](https://support.microsoft.com/en-us/windows/diagnostics-feedback-and-privacy-in-windows-28808a2b-a31b-dd73-dcd3-4559a5199319). + - question: What are the biometric requirements for Windows Hello for Business? answer: | Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information. @@ -206,7 +231,7 @@ sections: answer: | Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business don't require a TPM. Administrators can choose to allow key operations in software. - Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to re-authenticate to the IDP before the IDP allows them to re-register). + Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against various known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they'll need to use MFA to reauthenticate to the IDP before the IDP allows them to re-register). - question: Can Windows Hello for Business work in air-gapped environments? answer: | @@ -223,9 +248,9 @@ sections: | Protocol | Description | | :---: | :--- | | [[MS-KPP]: Key Provisioning Protocol](/openspecs/windows_protocols/ms-kpp/25ff7bd8-50e3-4769-af23-bcfd0b4d4567) | Specifies the Key Provisioning Protocol, which defines a mechanism for a client to register a set of cryptographic keys on a user and device pair. | - | [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and login hints. | + | [[MS-OAPX]: OAuth 2.0 Protocol Extensions](/openspecs/windows_protocols/ms-oapx/7612efd4-f4c8-43c3-aed6-f5c5ce359da2)| Specifies the OAuth 2.0 Protocol Extensions, which are used to extend the OAuth 2.0 Authorization Framework. These extensions enable authorization features such as resource specification, request identifiers, and log in hints. | | [[MS-OAPXBC]: OAuth 2.0 Protocol Extensions for Broker Clients](/openspecs/windows_protocols/ms-oapxbc/2f7d8875-0383-4058-956d-2fb216b44706) | Specifies the OAuth 2.0 Protocol Extensions for Broker Clients, extensions to RFC6749 (the OAuth 2.0 Authorization Framework) that allow a broker client to obtain access tokens on behalf of calling clients. | - | [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define additional claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define additional provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. | + | [[MS-OIDCE]: OpenID Connect 1.0 Protocol Extensions](/openspecs/windows_protocols/ms-oidce/718379cf-8bc1-487e-962d-208aeb8e70ee) | Specifies the OpenID Connect 1.0 Protocol Extensions. These extensions define other claims to carry information about the user, including the user principal name, a locally unique identifier, a time for password expiration, and a URL for password change. These extensions also define more provider meta-data that enables the discovery of the issuer of access tokens and gives additional information about provider capabilities. | - question: Does Windows Hello for Business work with Mac and Linux clients? answer: | @@ -235,3 +260,4 @@ sections: - question: Does Windows Hello for Business work with Azure Active Directory Domain Services (Azure AD DS) clients? answer: | No, Azure AD DS is a separately managed environment in Azure, and hybrid device registration with cloud Azure AD isn't available for it via Azure AD Connect. Hence, Windows Hello for Business doesn't work with Azure AD. + diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md index 5d90ae5f90..64e72640b6 100644 --- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md +++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md @@ -1,6 +1,6 @@ --- title: Pin Reset -description: Learn how Microsoft PIN reset services enables you to help users recover who have forgotten their PIN. +description: Learn how Microsoft PIN reset services enable you to help users recover who have forgotten their PIN. ms.prod: m365-security author: GitPrakhar13 ms.author: prsriva @@ -22,38 +22,49 @@ Windows Hello for Business provides the capability for users to reset forgotten There are two forms of PIN reset: -- **Destructive PIN reset**: with this option, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new log in key and PIN are provisioned. Destructive PIN reset is the default option, and doesn't require configuration. +- **Destructive PIN reset**: with this option, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, are deleted from the client and a new login key and PIN are provisioned. Destructive PIN reset is the default option, and doesn't require configuration. - **Non-destructive PIN reset**: with this option, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. For non-destructive PIN reset, you must deploy the **Microsoft PIN Reset Service** and configure your clients' policy to enable the **PIN Recovery** feature. ## Using PIN reset + +There are two forms of PIN reset called destructive and non-destructive. Destructive PIN reset is the default and doesn't require configuration. During a destructive PIN reset, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned. For non-destructive PIN reset, you must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. + +**Requirements** + +- Reset from settings - Windows 10, version 1703 or later, Windows 11 +- Reset above Lock - Windows 10, version 1709 or later, Windows 11 + Destructive and non-destructive PIN reset use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users do not have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider. + >[!IMPORTANT] >For hybrid Azure AD-joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN. ### Reset PIN from Settings -1. Sign-in to Windows 10 using an alternate credential -1. Open **Settings**, select **Accounts** > **Sign-in options** -1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions +1. Sign-in to Windows 10 using an alternate credential. +1. Open **Settings**, select **Accounts** > **Sign-in options**. +1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions. + ### Reset PIN above the Lock Screen For Azure AD-joined devices: -1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon -1. Select **I forgot my PIN** from the PIN credential provider -1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key) -1. Follow the instructions provided by the provisioning process -1. When finished, unlock your desktop using your newly created PIN +1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon. +1. Select **I forgot my PIN** from the PIN credential provider. +1. Select an authentication option from the list of presented options. This list will be based on the different authentication methods enabled in your tenant (e.g., Password, PIN, Security key). +1. Follow the instructions provided by the provisioning process. +1. When finished, unlock your desktop using your newly created PIN. + For Hybrid Azure AD-joined devices: -1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon -1. Select **I forgot my PIN** from the PIN credential provider -1. Enter your password and press enter -1. Follow the instructions provided by the provisioning process -1. When finished, unlock your desktop using your newly created PIN +1. If the PIN credential provider is not selected, expand the **Sign-in options** link, and select the PIN pad icon. +1. Select **I forgot my PIN** from the PIN credential provider. +1. Enter your password and press enter. +1. Follow the instructions provided by the provisioning process. +1. When finished, unlock your desktop using your newly created PIN. > [!NOTE] > Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work. @@ -65,16 +76,36 @@ You may find that PIN reset from settings only works post login, and that the "l **Requirements:** - Azure Active Directory +- Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. - Hybrid Windows Hello for Business deployment - Azure AD registered, Azure AD joined, and Hybrid Azure AD joined + When non-destructive PIN reset is enabled on a client, a 256-bit AES key is generated locally and added to a user's Windows Hello for Business container and keys as the PIN reset protector. This PIN reset protector is encrypted using a public key retrieved from the Microsoft PIN reset service and then stored on the client for later use during PIN reset. After a user initiates a PIN reset, completes authentication and multi-factor authentication to Azure AD, the encrypted PIN reset protector is sent to the Microsoft PIN reset service, decrypted, and returned to the client. The decrypted PIN reset protector is used to change the PIN used to authorize Windows Hello for Business keys and it is then cleared from memory. Using Group Policy, Microsoft Intune or a compatible MDM solution, you can configure Windows devices to securely use the **Microsoft PIN Reset Service** which enables users to reset their forgotten PIN without requiring re-enrollment. >[!IMPORTANT] +> The Microsoft PIN Reset service only works with **Enterprise Edition** for Windows 10, version 1709 to 1809 and later, and Windows 11. The feature works with **Enterprise Edition** and **Pro** edition with Windows 10, version 1903 and later, Windows 11. +> The Microsoft PIN Reset service is not currently available in Azure Government. + +### Summary + +|Category|Destructive PIN Reset|Non-Destructive PIN Reset| +|--- |--- |--- | +|**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.| +|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There is no licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.| +|**Azure Active Directory Joined**|Cert Trust, Key Trust, and Cloud Trust|Cert Trust, Key Trust, and Cloud Trust| +|**Hybrid Azure Active Directory Joined**|Cert Trust and Cloud Trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and Cloud Trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.| +|**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it is only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.| +|**Additional Configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature On-board the Microsoft PIN reset service to respective Azure Active Directory tenant Configure Windows devices to use PIN reset using Group *Policy\MDM*.| +|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.| + +### Onboarding the Microsoft PIN reset service to your Intune tenant + > The **Microsoft PIN Reset Service** is not currently available in Azure Government. + ### Enable the Microsoft PIN Reset Service in your Azure AD tenant Before you can remotely reset PINs, you must register two applications in your Azure Active Directory tenant: @@ -84,21 +115,21 @@ Before you can remotely reset PINs, you must register two applications in your A #### Connect Azure Active Directory with the PIN Reset Service -1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant -1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization +1. Go to the [Microsoft PIN Reset Service Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=b8456c59-1230-44c7-a4a2-99b085333e84&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fcred.microsoft.com&state=e9191523-6c2f-4f1d-a4f9-c36f26f89df0&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant. +1. After you have logged in, select **Accept** to give consent to the **PIN Reset Service** to access your organization. ![PIN reset service application in Azure.](images/pinreset/pin-reset-service-prompt.png) #### Connect Azure Active Directory with the PIN Reset Client -1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant -1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization +1. Go to the [Microsoft PIN Reset Client Production website](https://login.windows.net/common/oauth2/authorize?response_type=code&client_id=9115dd05-fad5-4f9c-acc7-305d08b1b04e&resource=https%3A%2F%2Fcred.microsoft.com%2F&redirect_uri=ms-appx-web%3A%2F%2FMicrosoft.AAD.BrokerPlugin%2F9115dd05-fad5-4f9c-acc7-305d08b1b04e&state=6765f8c5-f4a7-4029-b667-46a6776ad611&prompt=admin_consent), and sign in using a Global Administrator account you use to manage your Azure Active Directory tenant. +1. After you have logged in, select **Accept** to give consent for the **PIN Reset Client** to access your organization. ![PIN reset client application in Azure.](images/pinreset/pin-reset-client-prompt.png) #### Confirm that the two PIN Reset service principals are registered in your tenant -1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com) -1. Select **Azure Active Directory** > **Applications** > **Enterprise applications** -1. Search by application name "Microsoft PIN" and both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** will show up in the list +1. Sign in to the [Microsoft Entra Manager admin center](https://entra.microsoft.com). +1. Select **Azure Active Directory** > **Applications** > **Enterprise applications**. +1. Search by application name "Microsoft PIN" and both **Microsoft Pin Reset Service Production** and **Microsoft Pin Reset Client Production** will show up in the list. :::image type="content" alt-text="PIN reset service permissions page." source="images/pinreset/pin-reset-applications.png" lightbox="images/pinreset/pin-reset-applications-expanded.png"::: ### Enable PIN Recovery on your devices @@ -109,39 +140,39 @@ Before you can remotely reset PINs, your devices must be configured to enable PI You can configure Windows devices to use the **Microsoft PIN Reset Service** using Microsoft Intune. -1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com) -1. Select **Devices** > **Configuration profiles** > **Create profile** +1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com). +1. Select **Devices** > **Configuration profiles** > **Create profile**. 1. Enter the following properties: - - **Platform**: Select **Windows 10 and later** - - **Profile type**: Select **Settings catalog** -1. Select **Create** + - **Platform**: Select **Windows 10 and later**. + - **Profile type**: Select **Settings catalog**. +1. Select **Create**. 1. In **Basics**, enter the following properties: - - **Name**: Enter a descriptive name for the profile - - **Description**: Enter a description for the profile. This setting is optional, but recommended -1. Select **Next** -1. In **Configuration settings**, select **Add settings** -1. In the settings picker, select **Windows Hello For Business** > **Enable Pin Recovery** -1. Configure **Enable Pin Recovery** to **true** -1. Select **Next** -1. In **Scope tags**, assign any applicable tags (optional) -1. Select **Next** -1. In **Assignments**, select the security groups that will receive the policy -1. Select **Next** -1. In **Review + create**, review your settings and select **Create** + - **Name**: Enter a descriptive name for the profile. + - **Description**: Enter a description for the profile. This setting is optional, but recommended. +1. Select **Next**. +1. In **Configuration settings**, select **Add settings**. +1. In the settings picker, select **Windows Hello For Business** > **Enable Pin Recovery**. +1. Configure **Enable Pin Recovery** to **true**. +1. Select **Next**. +1. In **Scope tags**, assign any applicable tags (optional). +1. Select **Next**. +1. In **Assignments**, select the security groups that will receive the policy. +1. Select **Next**. +1. In **Review + create**, review your settings and select **Create**. >[!NOTE] > You can also configure PIN recovery from the **Endpoint security** blade: -> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com) -> 1. Select **Endpoint security** > **Account protection** > **Create Policy** +> 1. Sign in to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com). +> 1. Select **Endpoint security** > **Account protection** > **Create Policy**. #### [✅ **GPO**](#tab/gpo) You can configure Windows devices to use the **Microsoft PIN Reset Service** using a Group Policy Object (GPO). -1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory -1. Edit the Group Policy object from Step 1 -1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business** -1. Close the Group Policy Management Editor to save the Group Policy object +1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory. +1. Edit the Group Policy object from Step 1. +1. Enable the **Use PIN Recovery** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**. +1. Close the Group Policy Management Editor to save the Group Policy object. #### [✅ **CSP**](#tab/csp) @@ -198,6 +229,44 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a +----------------------------------------------------------------------+ ``` +## Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices + +**Applies to:** + +- Windows 10, version 1803 or later +- Windows 11 +- Azure AD joined + +The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that are allowed to be navigated to during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset. + +### Configuring Policy Using Intune + +1. Sign-in to [Endpoint Manager admin center](https://endpoint.microsoft.com/) using a Global administrator account. + +1. Click **Devices**. Click **Configuration profiles**. Click **Create profile**. + +1. For Platform select **Windows 10 and later** and for Profile type select **Templates**. In the list of templates that is loaded, select **Custom** and click Create. + +1. In the **Name** field type **Web Sign In Allowed URLs** and optionally provide a description for the configuration. Click Next. + +1. On the Configuration settings page, click **Add** to add a custom OMA-URI setting. Provide the following information for the custom settings: + + - **Name:** Web Sign In Allowed URLs + - **Description:** (Optional) List of domains that are allowed during PIN reset flows. + - **OMA-URI:** ./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls + - **Data type:** String + - **Value**: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be _signin.contoso.com;portal.contoso.com_ (without quotation marks) + + :::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist.png"::: + +1. Click the **Save** button to save the custom configuration. + +1. On the Assignments page, use the Included groups and Excluded groups sections to define the groups of users or devices that should receive this policy. Once you have completed configuring groups click the Next button. + +1. On the Applicability rules page, click **Next**. + +1. Review the configuration that is shown on the Review + create page to make sure that it is accurate. Click create to save the profile and apply it to the configured groups. + ### Configure Web Sign-in Allowed URLs for Third Party Identity Providers on Azure AD Joined Devices The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-authentication#authentication-configurewebsigninallowedurls) policy allows you to specify a list of domains that can be reached during PIN reset flows on Azure AD-joined devices. If you have a federated environment and authentication is handled using AD FS or a third-party identity provider, this policy should be set to ensure that authentication pages from that identity provider can be used during Azure AD joined PIN reset. @@ -205,28 +274,29 @@ The [ConfigureWebSignInAllowedUrls](/windows/client-management/mdm/policy-csp-au #### Configure Web Sign-in Allowed URLs using Microsoft Intune -1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431) -1. Select **Devices** > **Configuration profiles** > **Create profile** +1. Sign in to the [Microsoft Endpoint Manager admin center](https://go.microsoft.com/fwlink/?linkid=2109431). +1. Select **Devices** > **Configuration profiles** > **Create profile**. 1. Enter the following properties: - - **Platform**: Select **Windows 10 and later** - - **Profile type**: Select **Templates** - - In the list of templates that is loaded, select **Custom** > **Create** + - **Platform**: Select **Windows 10 and later**. + - **Profile type**: Select **Templates**. + - In the list of templates that is loaded, select **Custom** > **Create**. 1. In **Basics**, enter the following properties: - - **Name**: Enter a descriptive name for the profile - - **Description**: Enter a description for the profile. This setting is optional, but recommended -1. Select **Next** + - **Name**: Enter a descriptive name for the profile. + - **Description**: Enter a description for the profile. This setting is optional, but recommended. +1. Select **Next**. 1. In **Configuration settings**, select **Add** and enter the following settings: - Name: **Web Sign In Allowed URLs** - Description: **(Optional) List of domains that are allowed during PIN reset flows** - OMA-URI: `./Vendor/MSFT/Policy/Config/Authentication/ConfigureWebSignInAllowedUrls` - Data type: **String** - - Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks) + - Value: Provide a semicolon delimited list of domains needed for authentication during the PIN reset scenario. An example value would be **signin.contoso.com;portal.contoso.com** (without quotation marks). :::image type="content" alt-text="Custom Configuration for ConfigureWebSignInAllowedUrls policy." source="images/pinreset/allowlist.png" lightbox="images/pinreset/allowlist-expanded.png"::: -1. Select **Save** > **Next** -1. In **Assignments**, select the security groups that will receive the policy -1. Select **Next** -1. In **Applicability Rules**, select **Next** -1. In **Review + create**, review your settings and select **Create** +1. Select **Save** > **Next**. +1. In **Assignments**, select the security groups that will receive the policy. +1. Select **Next**. +1. In **Applicability Rules**, select **Next**. +1. In **Review + create**, review your settings and select **Create**. + > [!NOTE] > For Azure Government, there is a known issue with PIN reset on Azure AD Joined devices failing. When the user attempts to launch PIN reset, the PIN reset UI shows an error page that says, "We can't open that page right now." The ConfigureWebSignInAllowedUrls policy can be used to work around this issue. If you are experiencing this problem and you are using Azure US Government cloud, set **login.microsoftonline.us** as the value for the ConfigureWebSignInAllowedUrls policy. diff --git a/windows/security/threat-protection/windows-defender-application-control/applocker/script-rules-in-applocker.md b/windows/security/threat-protection/windows-defender-application-control/applocker/script-rules-in-applocker.md index aee609a7fd..e30b2c517a 100644 --- a/windows/security/threat-protection/windows-defender-application-control/applocker/script-rules-in-applocker.md +++ b/windows/security/threat-protection/windows-defender-application-control/applocker/script-rules-in-applocker.md @@ -1,6 +1,6 @@ --- title: Script rules in AppLocker (Windows) -description: This topic describes the file formats and available default rules for the script rule collection. +description: This article describes the file formats and available default rules for the script rule collection. ms.assetid: fee24ca4-935a-4c5e-8a92-8cf1d134d35f ms.reviewer: ms.author: macapara @@ -26,10 +26,6 @@ ms.technology: windows-sec - Windows 11 - Windows Server 2016 and above -> [!NOTE] -> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability). - - This article describes the file formats and available default rules for the script rule collection. AppLocker defines script rules to include only the following file formats: @@ -44,11 +40,11 @@ The following table lists the default rules that are available for the script ru | Purpose | Name | User | Rule condition type | | - | - | - | - | | Allows members of the local Administrators group to run all scripts| (Default Rule) All scripts| BUILTIN\Administrators | Path: `*\` | -| Allow all users to run scripts in the Windows folder| (Default Rule) All scripts located in the Windows folder| Everyone | Path: `%windir%\*` | -| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder|Everyone | Path: `%programfiles%\*`| - +| Allow all users to run scripts in the Windows folder| (Default Rule) All scripts located in the Windows folder| Everyone | Path: `%windir%\*` | +| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder|Everyone | Path: `%programfiles%\*`| + > [!NOTE] -> Windows Defender Application Control cannot be used to block PowerShell scripts. AppLocker just forces PowerShell scripts to be run in Constrained Language mode. Also note that in cases where a PS1 script is "blocked", AppLocker generates an 8007 event, which states that the script will be blocked, but then the script runs. +> When a script runs that is not allowed by policy, AppLocker raises an event indicating that the script was "blocked". However, the actual script enforcement behavior is handled by the script host. In the case of PowerShell, "blocked" scripts will still run, but only in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). Authorized scripts run in Full Language Mode. ## Related articles diff --git a/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md b/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md index 2d31e8f0f7..f9b070ff3b 100644 --- a/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md +++ b/windows/security/threat-protection/windows-defender-application-control/create-initial-default-policy.md @@ -1,6 +1,6 @@ --- -title: Create a WDAC policy for fixed-workload devices using a reference computer (Windows) -description: To create a Windows Defender Application Control (WDAC) policy for fixed-workload devices within your organization, follow this guide. +title: Create a WDAC policy using a reference computer (Windows) +description: To create a Windows Defender Application Control (WDAC) policy that allows all code installed on a reference computer within your organization, follow this guide. keywords: security, malware ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb ms.prod: m365-security @@ -11,83 +11,133 @@ ms.localizationpriority: medium audience: ITPro ms.collection: M365-security-compliance author: jsuther1974 -ms.reviewer: isbrahm +ms.reviewer: jogeurte ms.author: dansimp manager: dansimp -ms.date: 05/03/2018 +ms.date: 08/08/2022 ms.technology: windows-sec --- -# Create a WDAC policy for fixed-workload devices using a reference computer +# Create a WDAC policy using a reference computer **Applies to:** -- Windows 10 -- Windows 11 -- Windows Server 2016 and above +- Windows 10 +- Windows 11 +- Windows Server 2016 and above >[!NOTE] >Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](feature-availability.md). -This section outlines the process to create a Windows Defender Application Control (WDAC) policy for fixed-workload devices within an organization. Fixed-workload devices tend to be dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. - -For this example, you must initiate variables to be used during the creation process or use the full file paths in the command. -Then create the WDAC policy by scanning the system for installed applications. -The policy file is converted to binary format when it gets created so that Windows can interpret it. - -## Overview of the process of creating Windows Defender Application Control policies - -A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone more company assets. Windows Defender Application Control policies follow a similar methodology that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of WDAC policies is similar to imaging, these policies should be maintained independently. Assess the necessity of more WDAC policies based on what should be allowed to be installed and run and for whom. For more information on doing this assessment, see the [WDAC Design Guide](windows-defender-application-control-design-guide.md). - -Optionally, WDAC can align with your software catalog and any IT department–approved applications. One straightforward method to implement WDAC is to use existing images to create one master WDAC policy. You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged, or serviced, and managed. - -If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in [Optional: Create a code signing certificate for Windows Defender Application Control](create-code-signing-cert-for-windows-defender-application-control.md). +This section outlines the process to create a Windows Defender Application Control (WDAC) policy **using a reference computer** that is already configured with the software you want to allow. You can use this approach for fixed-workload devices that are dedicated to a specific functional purpose and share common configuration attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment, manufacturing devices, cash registers, ATMs, etc. This approach can also be used to turn on WDAC on systems "in the wild" and you want to minimize the potential impact on users' productivity. > [!NOTE] -> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the WDAC policy. +> Some of the Windows Defender Application Control options described in this topic are only available on Windows 10 version 1903 and above, or Windows 11. When using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or some of these features and assess the impact for any features that may be unavailable on your clients. You may need to adapt this guidance to meet your specific organization's needs. -Each installed software application should be validated as trustworthy before you create a policy. -We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. -Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you don't want to run scripts. -You can remove or disable such software on the reference computer. +As described in [common Windows Defender Application Control deployment scenarios](types-of-devices.md), we'll use the example of **Lamna Healthcare Company (Lamna)** to illustrate this scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to prevent unwanted or unauthorized applications from running on their managed devices. -To create a Windows Defender Application Control policy, copy each of the following commands into an elevated Windows PowerShell session, in order: +**Alice Pena** is the IT team lead tasked with the rollout of WDAC. -1. Initialize variables that you'll use. +## Create a custom base policy using a reference device + +Alice previously created a policy for the organization's fully managed end-user devices. She now wants to use WDAC to protect Lamna's critical infrastructure servers. Lamna's imaging practice for infrastructure systems is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone more company assets. Alice decides to use these same "golden" image systems to create the WDAC policies, which will result in separate custom base policies for each type of infrastructure server. As with imaging, she'll have to create policies from multiple golden computers based on model, department, application set, and so on. + +> [!NOTE] +> Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before creating the WDAC policy.

Each installed software application should be validated as trustworthy before you create a policy.

We recommend that you review the reference computer for software that can load arbitrary DLLs and run code or scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you don't want to run scripts. You can remove or disable such software on the reference computer. + +Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's critical infrastructure servers: + +- All devices are running Windows Server 2019 or above; +- All apps are centrally managed and deployed; +- No interactive users. + +Based on the above, Alice defines the pseudo-rules for the policy: + +1. **“Windows works”** rules that authorize: + - Windows + - WHQL (third-party kernel drivers) + - Windows Store signed apps + +2. Rules for **scanned files** that authorize all pre-existing app binaries found on the device + +To create the WDAC policy, Alice runs each of the following commands in an elevated Windows PowerShell session, in order: + +1. Initialize variables. ```powershell $PolicyPath=$env:userprofile+"\Desktop\" $PolicyName="FixedWorkloadPolicy_Audit" - $WDACPolicy=$PolicyPath+$PolicyName+".xml" - $WDACPolicyBin=$PolicyPath+$PolicyName+".bin" + $LamnaServerPolicy=$PolicyPath+$PolicyName+".xml" + $DefaultWindowsPolicy=$env:windir+"\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml" + ``` 2. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to create a new WDAC policy by scanning the system for installed applications: ```powershell - New-CIPolicy -Level PcaCertificate -FilePath $WDACPolicy –UserPEs 3> CIPolicyLog.txt + New-CIPolicy -FilePath $LamnaServerPolicy -Level SignedVersion -Fallback FilePublisher,FileName,Hash -ScanPath c:\ -UserPEs -MultiplePolicyFormat -OmitPaths c:\Windows,'C:\Program Files\WindowsApps\',c:\windows.old\,c:\users\ 3> CIPolicyLog.txt ``` > [!Note] - > - > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the WDAC policy. In contrast, if you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers, in other words, the allow list will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Application Control. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. - > - You can add the **-MultiplePolicyFormat** parameter when creating policies which will be deployed to computers which are running Windows build 1903+. For more information about multiple policies, see [Deploy multiple Windows Defender Application Control policies](deploy-multiple-windows-defender-application-control-policies.md). + > > - You can add the **-Fallback** parameter to catch any applications not discovered using the primary file rule level specified by the **-Level** parameter. For more information about file rule level options, see [Windows Defender Application Control file rule levels](select-types-of-rules-to-create.md). - > > - To specify that the WDAC policy scan only a specific drive, include the **-ScanPath** parameter followed by a path. Without this parameter, the tool will scan the C-drive by default. - > + > - When you specify the **-UserPEs** parameter (to include user mode executables in the scan), rule option **0 Enabled:UMCI** is automatically added to the WDAC policy. If you do not specify **-UserPEs**, the policy will be empty of user mode executables and will only have rules for kernel mode binaries like drivers. In other words, the allow list will not include applications. If you create such a policy and later add rule option **0 Enabled:UMCI**, all attempts to start applications will cause a response from Windows Defender Application Control. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. + > - To create a policy for Windows 10 1903 and above, including support for supplemental policies, use **-MultiplePolicyFormat**. + > - To specify a list of paths to exclude from the scan, use the **-OmitPaths** option and supply a comma-delimited list of paths. > - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**. -3. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format: +3. Merge the new policy with the WindowsDefault_Audit policy to ensure all Windows binaries and kernel drivers will load. + + ```powershell + Merge-CIPolicy -OutputFilePath $LamnaServerPolicy -PolicyPaths $LamnaServerPolicy,$DefaultWindowsPolicy + ``` + +4. Give the new policy a descriptive name, and initial version number: + + ```powershell + Set-CIPolicyIdInfo -FilePath $LamnaServerPolicy -PolicyName $PolicyName + Set-CIPolicyVersion -FilePath $LamnaServerPolicy -Version "1.0.0.0" + ``` + +5. Modify the merged policy to set policy rules: + + ```powershell + Set-RuleOption -FilePath $LamnaServerPolicy -Option 3 # Audit Mode + Set-RuleOption -FilePath $LamnaServerPolicy -Option 6 # Unsigned Policy + Set-RuleOption -FilePath $LamnaServerPolicy -Option 9 # Advanced Boot Menu + Set-RuleOption -FilePath $LamnaServerPolicy -Option 12 # Enforce Store Apps + Set-RuleOption -FilePath $LamnaServerPolicy -Option 16 # No Reboot + Set-RuleOption -FilePath $LamnaServerPolicy -Option 17 # Allow Supplemental + Set-RuleOption -FilePath $LamnaServerPolicy -Option 19 # Dynamic Code Security + ``` + +6. If appropriate, add more signer or file rules to further customize the policy for your organization. + +7. Use [ConvertFrom-CIPolicy](/powershell/module/configci/convertfrom-cipolicy) to convert the WDAC policy to a binary format: ```powershell - ConvertFrom-CIPolicy $WDACPolicy $WDACPolicyBin + [xml]$LamnaServerPolicyXML = Get-Content $LamnaServerPolicy + $PolicyId = $LamnaServerPolicyXML.SiPolicy.PolicyId + $LamnaServerPolicyBin = $PolicyPath+$PolicyId+".cip" + ConvertFrom-CIPolicy $LamnaServerPolicy $LamnaServerPolicyBin ``` -After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy) will be available on your desktop. You can use the binary file as a WDAC policy or sign it for more security. +8. Upload the base policy XML and the associated binary to a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration). -> [!NOTE] -> We recommend that you keep the original .xml file of the policy for use when you need to merge the WDAC policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge WDAC policies, see [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md). +Alice now has an initial policy for Lamna's critical infrastructure servers that is ready to deploy in audit mode. -We recommend that every WDAC policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error messages. For information about how to audit a WDAC policy, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md). +## Create a custom base policy to minimize user impact on in-use client devices +Alice previously created a policy for the organization's fully managed devices. Alice has included the fully managed device policy as part of Lamna's device build process so all new devices now begin with WDAC enabled. She's preparing to deploy the policy to systems that are already in use, but is worried about causing disruption to users' productivity. To minimize that risk, Alice decides to take a different approach for those systems. She'll continue to deploy the fully managed device policy in audit mode to those devices, but for enforcement mode she'll merge the fully managed device policy rules with a policy created by scanning the device for all previously installed software. In this way, each device is treated as its own "golden" system. +Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's fully managed in-use devices: + +- Everything described for Lamna's [Fully Managed Devices](create-wdac-policy-for-fully-managed-devices.md); +- Users have installed apps that they need to continue to run. + +Based on the above, Alice defines the pseudo-rules for the policy: + +1. Everything included in the Fully Managed Devices policy +2. Rules for **scanned files** that authorize all pre-existing app binaries found on the device + +For Lamna's existing, in-use devices, Alice deploys a script along with the Fully Managed Devices policy XML (not the converted WDAC policy binary). The script then generates a custom policy locally on the client as described in the previous section, but instead of merging with the DefaultWindows policy, the script merges with Lamna's Fully Managed Devices policy. Alice also modifies the steps above to match the requirements of this different use case. diff --git a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md index 7cd08be428..2d13639669 100644 --- a/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md +++ b/windows/security/threat-protection/windows-defender-application-control/create-wdac-policy-for-fully-managed-devices.md @@ -82,8 +82,9 @@ Alice follows these steps to complete this task: 2. On the client device, run the following commands in an elevated Windows PowerShell session to initialize variables: ```powershell + $PolicyPath=$env:userprofile+"\Desktop\" $PolicyName= "Lamna_FullyManagedClients_Audit" - $LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml" + $LamnaPolicy=$PolicyPath+$PolicyName+".xml" $MEMCMPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml" ``` @@ -121,7 +122,9 @@ Alice follows these steps to complete this task: > In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including braces **{ }**) found in your policy XML file. ```powershell - $WDACPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin" + [xml]$LamnaPolicyXML = Get-Content $LamnaPolicy + $PolicyId = $LamnaPolicyXML.SiPolicy.PolicyId + $LamnaPolicyBin = $PolicyPath+$PolicyId+".cip" ConvertFrom-CIPolicy $LamnaPolicy $WDACPolicyBin ```