Skip to content

Commit

Permalink
Merge pull request #5422 from MicrosoftDocs/main
Browse files Browse the repository at this point in the history
10/3/2024 PM Publish
  • Loading branch information
Taojunshen authored Oct 3, 2024
2 parents ec4737c + 66a5aa4 commit 525adc6
Show file tree
Hide file tree
Showing 10 changed files with 120 additions and 110 deletions.
6 changes: 3 additions & 3 deletions docs/identity/authentication/concept-fido2-compatibility.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ The following tables lists which authentication brokers are supported for differ
| OS | Authentication broker | Supports FIDO2 |
|------------------|---------------------------------|----------------|
| **iOS** | Microsoft Authenticator | ✅ |
| **macOS** | Microsoft Intune Company Portal <sup>1</sup> | &#x2705; |
| **macOS** | Microsoft Intune Company Portal<sup>1</sup> | &#x2705; |
| **Android**<sup>2</sup> | Authenticator or Company Portal | &#10060; |

<sup>1</sup>On macOS, the [Microsoft Enterprise Single Sign On (SSO) plug-in](~/identity-platform/apple-sso-plugin.md) is required to enable Company Portal as an authentication broker. Devices that run macOS must meet SSO plug-in requirements, including enrollment in mobile device management. For FIDO2 authentication, make sure that you run the latest version of native applications.
Expand Down Expand Up @@ -65,9 +65,9 @@ This table shows browser support for authenticating Microsoft Entra ID and Micro
| **ChromeOS** | &#x2705; | N/A | N/A | N/A |
| **Linux** | &#x2705; | &#10060; | &#10060; | N/A |
| **iOS** | &#x2705; | &#x2705; | &#x2705; | &#x2705; |
| **Android** | &#x2705; | &#x2705; | &#10060; | N/A |
| **Android** | &#x2705; | &#x2705;<sup>1</sup> | &#10060; | N/A |

[!INCLUDE [Need APIs to support browsers](~/includes/passkeys-with-chrome-browser.md)]
<sup>1</sup>Support for same-device registration in Edge on Android is coming soon.

## Web browser support for each platform

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -38,10 +38,23 @@ The scope of enforcement includes which applications plan to enforce MFA, when e

All users who sign into the [applications](#applications) listed previously to perform any Create, Read, Update, or Delete (CRUD) operation will require MFA when the enforcement begins. End users who access application, websites, or services hosted on Azure, but don't sign into the listed applications, aren't required to use MFA. The authentication requirements for end users are controlled by the application, website, or service owner.

Workload identities, such as managed identities and service principals, aren't impacted by [Phase 1](#enforcement-phases) of the MFA enforcement. If user identities sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins. User identities aren't recommended for automation. You should migrate those user identities to [workload identities](~/workload-id/workload-identities-overview.md).

Break glass or emergency access accounts are also required to sign in with MFA once enforcement begins. We recommend updating these accounts to use [passkey (FIDO2)](~/identity/authentication/how-to-enable-passkey-fido2.md) or configure [certificate-based authentication](~/identity/authentication/how-to-certificate-based-authentication.md) for MFA. Both methods satisfy the MFA requirement.

Workload identities, such as managed identities and service principals, aren't impacted by [either phase](#enforcement-phases) of this Azure MFA enforcement. If user identities are used to sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins. User identities aren't recommended for automation. You should migrate those user identities to [workload identities](~/workload-id/workload-identities-overview.md).

> [!Tip]
> We recommend customers currently using user accounts as service accounts begin the process of discovery and migration to workload identities. This will often require updating scripts and automation processes to use workload identities.
>
> Review [Prepare for multifactor authentication](#prepare-for-multifactor-authentication) to identify all user accounts (including user accounts being used as service accounts) signing into the phase 2 applications.
>
> For guidance on migrating authentication with these applications from user based service accounts to workload identities see:
>
>- [Sign into Azure with a managed identity using the Azure CLI](/cli/azure/authenticate-azure-cli-managed-identity)
>- [Sign into Azure with a service principal using the Azure CLI](/cli/azure/authenticate-azure-cli-service-principal)
>- [Sign in to Azure PowerShell non-interactively for automation scenarios](/powershell/azure/authenticate-noninteractive) (Includes guidance for both managed identity and service principal use cases)
>
> Customers applying conditional access policies to the user based service accounts can reclaim this user based license and apply [workload identities](~/workload-id/workload-identities-overview.md) license to apply [Conditional Access for workload identities](~/identity/conditional-access/workload-identity.md).
## Implementation

This requirement for MFA at sign-in is implemented for admin portals. Microsoft Entra ID [sign-in logs](~/identity/monitoring-health/concept-sign-ins.md) shows it as the source of the MFA requirement.
Expand Down
1 change: 1 addition & 0 deletions docs/identity/authentication/feature-availability.md
Original file line number Diff line number Diff line change
Expand Up @@ -109,6 +109,7 @@ This following tables list Microsoft Entra feature availability in Azure Governm
|Workday Writeback | &#x2705; |
|SuccessFactors to Microsoft Entra user provisioning | &#x2705; |
|SuccessFactors to Writeback | &#x2705; |
|API-driven inbound provisioning | &#10060; |
|Provisioning agent configuration and registration with Gov cloud tenant| Works with special undocumented command-line invocation:<br> `AADConnectProvisioningAgent.Installer.exe ENVIRONMENTNAME=AzureUSGovernment` |

## Other Microsoft Entra products
Expand Down
52 changes: 28 additions & 24 deletions docs/identity/authentication/how-to-enable-authenticator-passkey.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ description: Learn about how to enable passkeys in Microsoft Authenticator for M
ms.service: entra-id
ms.subservice: authentication
ms.topic: how-to
ms.date: 05/07/2024
ms.date: 09/03/2024

ms.author: justinha
author: justinha
Expand All @@ -32,41 +32,45 @@ To learn more about where you can use passkeys in Authenticator to sign in, see

## Enable passkeys in Authenticator in the admin center

The **Microsoft Authenticator** policy doesn't give you the option to enable passkeys in Authenticator. Instead, to enable passkeys in Authenticator, you must edit the **FIDO2 security key** Authentication methods policy.
An Authentication Policy Administrator needs to consent to allow Authenticator in the **Passkey (FIDO2) settings** of the Authentication methods policy. They need to explicitly allow the Authenticator Attestation GUIDs (AAGUIDs) for Microsoft Authenticator to enable users to register passkeys in the Authenticator app. There's no setting to enable passkeys in the **Microsoft Authenticator app** section of the Authentication Methods policy.

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least an [Authentication Policy Administrator](~/identity/role-based-access-control/permissions-reference.md#authentication-policy-administrator).
1. Browse to **Protection** > **Authentication methods** > **Authentication method policy**.
1. Under the method **FIDO2 security key**, select **All users** or **Add groups** to select specific groups. *Only security groups are supported*.
1. On the **Configure** tab, set:
- **Allow self-service set up** to **Yes**
- **Enforce attestation** to **No**
- **Enforce key restrictions** to **Yes**
- **Restrict specific keys** to **Allow**
- Select **Microsoft Authenticator (preview)** if the checkbox is displayed in the admin center. This setting automatically populates the Authenticator app AAGUIDs for you in the key restriction list. Otherwise, you can manually add the following AAGUIDs to enable the Authenticator passkey preview:

- **Authenticator for Android:** de1e552d-db1d-4423-a619-566b625cdc84
- **Authenticator for iOS:** 90a3ccdf-635c-4729-a248-9b709135078f
1. Under the method **Passkey (FIDO2)**, select **All users** or **Add groups** to select specific groups. *Only security groups are supported*.
1. On the **Configure** tab:
- Set **Allow self-service set up** to **Yes**. If set to **No**, users can't register a passkey by using [Security info](https://mysignins.microsoft.com/security-info), even if passkeys (FIDO2) are enabled by the Authentication methods policy.
- Set **Enforce attestation** to **No** for preview. Attestation support is planned for General Availability.
- Key restrictions set the usability of specific passkeys for both registration and authentication. Set **Enforce key restrictions** to **Yes** to only allow or block certain passkeys, which are identified by their AAGUIDs.

This setting must be **Yes** and you need to add the Microsoft Authenticator AAGUIDs to allow users to register passkeys in the Authenticator, either by signing into the Authenticator app, or by adding **Passkey in Microsoft Authenticator** from their Security info.

:::image type="content" border="true" source="media/how-to-enable-authenticator-passkey/optional-settings.png" alt-text="Screenshot showing Microsoft Authenticator enabled for passkey."lightbox="media/how-to-enable-authenticator-passkey/optional-settings.png":::
[Security info](https://mysignins.microsoft.com/security-info) requires this setting to be set to **Yes** for users to be able to choose **Passkey in Authenticator** and go through a dedicated Authenticator passkey registration flow. If you choose **No**, users may still be able to add a passkey in Microsoft Authenticator by choosing the **Passkey** method, depending upon their operating system and browser. However, we do not expect this avenue to be discoverable and used by most users.

If your organization doesn't currently enforce key restrictions and already has active passkey usage, you should collect the AAGUIDs of the keys being used today. Add them to the Allow list, along with the Authenticator AAGUIDs, to enable this preview. This task can be done with an automated script that analyzes logs, such as registration details and sign-in logs.

>[!WARNING]
>Key restrictions set the usability of specific passkeys for both registration and authentication. If you change key restrictions and remove an AAGUID that you previously allowed, users who previously registered an allowed method can no longer use it for sign-in. If your organization doesn't currently enforce key restrictions and already has active passkey usage, you should collect the AAGUIDs of the keys being used today. Add them to the Allow list, along with the Authenticator AAGUIDs, to enable this preview. This task can be done with an automated script that analyzes logs such as registration details and sign-in logs.
If you change key restrictions and remove an AAGUID that you previously allowed, users who previously registered an allowed method can no longer use it for sign-in.

The following list describes other optional settings:
- Set **Restrict specific keys** to **Allow**.
- Select **Microsoft Authenticator (Preview)** to automatically add the Authenticator app AAGUIDs to the key restriction list, or manually add the following AAGUIDs to allow users to register passkeys in the Authenticator by signing into the Authenticator app or by going through a guided flow on the Security info page:

**General**
- **Authenticator for Android:** de1e552d-db1d-4423-a619-566b625cdc84
- **Authenticator for iOS:** 90a3ccdf-635c-4729-a248-9b709135078f

>[!NOTE]
>If you turn off key retrictions, make sure you clear the **Microsoft Authenticator (Preview)** checkbox so that users aren’t prompted to set up a passkey in the Authenticator app in [Security info](https://mysignins.microsoft.com/security-info).
- **Allow self-service set up** should remain set to **Yes**. If set to no, your users aren't able to register a passkey through MySecurityInfo, even if enabled by Authentication Methods policy.
- **Enforce attestation** Should be set to **No** for preview. Attestation support is planned for General Availability.
Two more AAGUIDs may be listed.
They are `b6879edc-2a86-4bde-9c62-c1cac4a8f8e5` and `257fa02a-18f3-4e34-8174-95d454c2e9ad`.
These AAGUIDs appear in advance of an upcoming feature.
You can remove them from the list of allowed AAGUIDs.

**Key Restriction Policy**
:::image type="content" border="true" source="media/how-to-enable-authenticator-passkey/optional-settings.png" alt-text="Screenshot showing Microsoft Authenticator enabled for passkey."lightbox="media/how-to-enable-authenticator-passkey/optional-settings.png":::

- **Enforce key restrictions** should be set to **Yes** only if your organization wants to only allow or disallow certain passkeys, which are identified by their Authenticator Attestation GUID (AAGUID). If you want, you can manually enter the Authenticator app AAGUIDs or specifically restrict only Android or iOS devices. Otherwise, you can manually add the following AAGUIDs to enable the Authenticator passkey preview:
1. After you finish the configuration, select **Save**.

- **Authenticator for Android:** de1e552d-db1d-4423-a619-566b625cdc84
- **Authenticator for iOS:** 90a3ccdf-635c-4729-a248-9b709135078f
>[!NOTE]
>If you see an error when you try to save, replace multiple groups with a single group in one operation, and then click **Save** again.
After you finish the configuration, select **Save**.

## Enable passkeys in Authenticator using Graph Explorer

Expand Down
Loading

0 comments on commit 525adc6

Please sign in to comment.