From d53044b57e2d7d98e8da140caea6d7b05270ceb7 Mon Sep 17 00:00:00 2001 From: Michael Epping Date: Wed, 27 Nov 2024 10:51:06 -0800 Subject: [PATCH 1/2] Add section on MAM CA policies --- .../how-to-support-authenticator-passkey.md | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/identity/authentication/how-to-support-authenticator-passkey.md b/docs/identity/authentication/how-to-support-authenticator-passkey.md index c797f05e9b6..6cae3c2888a 100644 --- a/docs/identity/authentication/how-to-support-authenticator-passkey.md +++ b/docs/identity/authentication/how-to-support-authenticator-passkey.md @@ -57,6 +57,33 @@ There are a couple workarounds: >[!NOTE] >With either workaround, users must also satisfy any Conditional Access policy that targets **Register security info**, or they can't register the passkey. Additionally, if you have other conditions set up with the **All resources** policies, those will have to be met when registering the passkey. +## Workarounds for users blocked from registering passkeys by Conditional Access "Require approved client app" or "Require app protection policy" grant control + +Organizations that are deploying passkeys and have Conditional Access policies that require the **Require approved client app** or **Require app protection policy** grant control when accessing **All resources (formerly 'All cloud apps')** can run into an issue where users are not allowed to register a passkey in Microsoft Authenticator. An example of such a policy configuration: + +- Condition: **All devices (Windows, Linux, MacOS, Windows, Android)** +- Targeted resource: **All resources (formerly 'All cloud apps')** +- Grant control: **Require approved client app** or **Require app protection policy** + +The policy effectively enforces that the targeted users must use an app that supports [Microsoft Intune app protection policies](/mem/intune/apps/app-protection-policy) to authenticate to all cloud applications, which the Microsoft Authenticator app does not support. This means users cannot register a passkey in Microsoft Authenticator when this type of Conditional Access policy is enforced. This affects both Android and iOS. + +There are a couple workarounds: + +- You can [filter for applications](~/identity/conditional-access/concept-filter-for-applications.md) and transition the policy target from **All resources (formerly 'All cloud apps')** to specific applications. Start with a review of applications that are used in your tenant and use filters to tag appropriate applications. + +- You can leverage full MDM management and the **Require device to be marked as compliant** control. An example of such a policy configuration: + + - Condition: **All devices (Windows, Linux, MacOS, Windows, Android)** + - Targeted resource: **All resources (formerly 'All cloud apps')** + - Grant control: **Require approved client app** or **Require app protection policy** or ***Require device to be marked as compliant*** + +- You can grant users a temporary exemption from the Conditional Access policy. Microsoft recommends using one or more compensating controls: + - Only allow the exemption for a period of time. Communicate to the end user what the time window is where they are allowed to register a passkey. Remove the exemption at the end of the time window and direct users to call the help desk if they missed the window. + - Use another Conditional Access policy to require that users register only from a specific network location or a compliant device + +>[!NOTE] +>With any proposed workaround, users must also satisfy any Conditional Access policy that targets **Register security info**, or they can't register the passkey. Additionally, if you have other conditions set up with the **All resources** policies, those will have to be met when registering the passkey. + ## Restrict Bluetooth usage to passkeys in Authenticator Some organizations restrict Bluetooth usage, which includes the use of passkeys. In such cases, organizations can allow passkeys by permitting Bluetooth pairing exclusively with passkey-enabled FIDO2 authenticators. For more information about how to configure Bluetooth usage only for passkeys, see [Passkeys in Bluetooth-restricted environments](/windows/security/identity-protection/passkeys/?tabs=windows%2Cintune#passkeys-in-bluetooth-restricted-environments). From 06bfead0ad518bb5239a9d39ebef01a6e8cd05b5 Mon Sep 17 00:00:00 2001 From: Michael Epping Date: Wed, 27 Nov 2024 12:14:51 -0800 Subject: [PATCH 2/2] Update how-to-support-authenticator-passkey.md --- .../how-to-support-authenticator-passkey.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/identity/authentication/how-to-support-authenticator-passkey.md b/docs/identity/authentication/how-to-support-authenticator-passkey.md index 6cae3c2888a..bc791f8cabb 100644 --- a/docs/identity/authentication/how-to-support-authenticator-passkey.md +++ b/docs/identity/authentication/how-to-support-authenticator-passkey.md @@ -24,7 +24,7 @@ This topic covers issues that users might see when they use passkeys in Microsof Organizations that are deploying passkeys and have Conditional Access policies that require phishing-resistant authentication when accessing **All resources (formerly 'All cloud apps')** can run into a looping issue when users attempt to add a passkey to Microsoft Authenticator. An example of such a policy configuration: -- Condition: **All devices (Windows, Linux, MacOS, Windows, Android)** +- Condition: **All devices (Windows, Linux, macOS, Windows, Android)** - Targeted resource: **All resources (formerly 'All cloud apps')** - Grant control: **Authentication strength – Require passkey in Authenticator** @@ -61,7 +61,7 @@ There are a couple workarounds: Organizations that are deploying passkeys and have Conditional Access policies that require the **Require approved client app** or **Require app protection policy** grant control when accessing **All resources (formerly 'All cloud apps')** can run into an issue where users are not allowed to register a passkey in Microsoft Authenticator. An example of such a policy configuration: -- Condition: **All devices (Windows, Linux, MacOS, Windows, Android)** +- Condition: **All devices (Windows, Linux, macOS, Windows, Android)** - Targeted resource: **All resources (formerly 'All cloud apps')** - Grant control: **Require approved client app** or **Require app protection policy** @@ -71,9 +71,9 @@ There are a couple workarounds: - You can [filter for applications](~/identity/conditional-access/concept-filter-for-applications.md) and transition the policy target from **All resources (formerly 'All cloud apps')** to specific applications. Start with a review of applications that are used in your tenant and use filters to tag appropriate applications. -- You can leverage full MDM management and the **Require device to be marked as compliant** control. An example of such a policy configuration: +- You can leverage full MDM management and the **Require device to be marked as compliant** control. The Microsoft Authenticator app can satisfy this grant control if the device is MDM managed and is successfully reporting as being in a compliant state. An example of such a policy configuration: - - Condition: **All devices (Windows, Linux, MacOS, Windows, Android)** + - Condition: **All devices (Windows, Linux, macOS, Windows, Android)** - Targeted resource: **All resources (formerly 'All cloud apps')** - Grant control: **Require approved client app** or **Require app protection policy** or ***Require device to be marked as compliant***