📋 Microsoft Entra Documentation Changes

Changes for April 17th 2025

Period: April 16th 2025, 12:00 AM to April 17th 2025, 12:00 AM

📚 Historical Report: This report shows documentation changes that occurred during the 24-hour period ending on April 17th 2025.

📊 Summary

82
Total Commits
0
New Files
288
Modified Files
2
Deleted Files
21
Contributors

📝 Modified Documentation Files

+231 / -218 lines changed
Commit: replaced table with v156 and replaced images with unicode
Changes:
Before
After
---
title: Microsoft Entra ID attestation for FIDO2 security key vendors
description: Explains requirements to prepare FIDO2 hardware for attestation with Microsoft Entra ID
ms.date: 03/12/2025
ms.service: entra-id
ms.subservice: authentication
author: justinha
 
## FIDO2 security keys eligible for attestation with Microsoft Entra ID
 
The following table includes each FIDO2 security key model listed in MDS version 137 that's eligible for attestation with Microsoft Entra ID. For each model, the table shows its Authenticator Attestation Globally Unique Identifier (AAGUID) and feature capabilities.
 
Description|AAGUID|Bio|USB|NFC|BLE
-----------|------|---|---|---|---
ACS FIDO Authenticator|50a45b0c-80e7-f944-bf29-f552bfa2e048|![n]|![y]|![n]|![n]
ACS FIDO Authenticator Card|973446ca-e21c-9a9b-99f5-9b985a67af0f|![n]|![n]|![y]|![n]
Allthenticator Android App: roaming BLE FIDO2 Allthenticator for Windows, Mac, Linux, and Allthenticate door readers|5ca1ab1e-fa57-1337-f1d0-a117371ca702|![y]|![y]|![n]|![n]
Allthenticator iOS App: roaming BLE FIDO2 Allthenticator for Windows, Mac, Linux, and Allthenticate door readers|5ca1ab1e-1337-fa57-f1d0-a117e71ca702|![y]|![y]|![n]|![n]
Android Authenticator with SafetyNet Attestation|b93fd961-f2e6-462f-b122-82002247de78|![y]|![n]|![n]|![n]
Arculus FIDO 2.1 Key Card \[P71\]|3f59672f-20aa-4afe-b6f4-7e5e916b6d98|![n]|![y]|![n]|![n]
---
title: Microsoft Entra ID attestation for FIDO2 security key vendors
description: Explains requirements to prepare FIDO2 hardware for attestation with Microsoft Entra ID
ms.date: 04/15/2025
ms.service: entra-id
ms.subservice: authentication
author: justinha
 
## FIDO2 security keys eligible for attestation with Microsoft Entra ID
 
The following table includes each FIDO2 security key model listed in MDS version 156 that's eligible for attestation with Microsoft Entra ID. For each model, the table shows its Authenticator Attestation Globally Unique Identifier (AAGUID) and feature capabilities.
 
Description|AAGUID|Bio|USB|NFC|BLE
-----------|------|---|---|---|---
ACS FIDO Authenticator|50a45b0c-80e7-f944-bf29-f552bfa2e048|❌|✅|❌|❌
ACS FIDO Authenticator Card|973446ca-e21c-9a9b-99f5-9b985a67af0f|❌|❌|✅|❌
ACS FIDO Authenticator NFC|c89e6a38-6c00-5426-5aa5-c9cbf48f0382|❌|✅|✅|❌
Allthenticator Android App: roaming BLE FIDO2 Allthenticator for Windows, Mac, Linux, and Allthenticate door readers|5ca1ab1e-fa57-1337-f1d0-a117371ca702|✅|✅|❌|❌
Allthenticator iOS App: roaming BLE FIDO2 Allthenticator for Windows, Mac, Linux, and Allthenticate door readers|5ca1ab1e-1337-fa57-f1d0-a117e71ca702|✅|✅|❌|❌
Android Authenticator with SafetyNet Attestation|b93fd961-f2e6-462f-b122-82002247de78|✅|❌|❌|❌
+31 / -71 lines changed
Commit: Removed references to otherMobile and AlternateMobilePhones as this can't be read or set using the currently available Graph APIs
Changes:
Before
After
 
# How to use the BypassDirSyncOverridesEnabled feature of a Microsoft Entra tenant.
 
This article describes the *BypassDirSyncOverridesEnabled*  feature and how to restore synchronization of Mobile and otherMobile attributes from Microsoft Entra ID to on-premises Active Directory.
 
Generally, synchronized users cannot be changed from Azure or Microsoft 365 admin portals, neither through PowerShell using Microsoft Entra ID or [Microsoft Graph PowerShell](/powershell/microsoftgraph/overview) modules. The exception to this is the Microsoft Entra user’s attributes called *MobilePhone* and *AlternateMobilePhones*. These attributes are synchronized from on-premises Active Directory attributes mobile and otherMobile, respectively, but end users can update their own phone number in *MobilePhone* attribute in Microsoft Entra ID through their profile page. Admins can also update synchronized user’s *MobilePhone* and *AlternateMobilePhones* values in Microsoft Entra ID using theMicrosoft Graph PowerShell module.
 
Giving users and admins the ability to update phone numbers directly in Microsoft Entra ID enables enterprises to reduce the administrative overhead of managing user’s phone numbers in local Active Directory as these can change more frequently.
 
The caveat however, is that once a synchronized user's *MobilePhone* or *AlternateMobilePhones* number is updated via admin portal or PowerShell, the synchronization API will no longer honor updates to these attributes when they originate from on-premises Active Directory. This is commonly known as a *“DirSyncOverrides”* feature. Administrators will notice this behavior when updates to Mobile or otherMobile attributes in Active Directory, do not update the correspondent user’s MobilePhone or AlternateMobilePhones in Microsoft Entra ID accordingly, even though, the object is successfully synchronized through Microsoft Entra Connect's engine.
 
## Identifying users with different Mobile and otherMobile values
 
You can export a list of users with different Mobile and otherMobile values between Active Directory and Microsoft Entra ID using *‘Compare-ADSyncToolsDirSyncOverrides’* from *ADSyncTools* PowerShell module. This will allow you to determine the users and respective values that are different between on-premises Active Directory and Microsoft Entra ID. This is important to know because enabling the *BypassDirSyncOverridesEnabled* feature will overwrite all the different values in Microsoft Entra ID with the value coming from on-premises Active Directory.
 
### Using Compare-ADSyncToolsDirSyncOverrides
 
Install-Module ADSyncTools
```
 
 
# How to use the BypassDirSyncOverridesEnabled feature of a Microsoft Entra tenant.
 
This article describes the *BypassDirSyncOverridesEnabled* feature and how to restore synchronization of _mobile_ and _otherMobile_ attributes from Microsoft Entra ID to on-premises Active Directory.
 
Synchronized users properties cannot be changed from Microsoft Entra ID or Microsoft 365 admin portals, neither through any available PowerShell modules. Up until recently, the exception to this was the Microsoft Entra user’s attributes called _MobilePhone_ and _AlternateMobilePhones_. These attributes are synchronized from on-premises Active Directory attributes _mobile_ and _otherMobile_, respectively, but end users used to be able to update their own phone number in _MobilePhone_ attribute in Microsoft Entra ID through their profile page. Changes to _MobilePhone_ and _AlternateMobilePhones_ attributes are no longer possible for Synchronized users except through the use of Microsoft Entra Connect or Microsoft Entra Cloud Sync.
 
Previously, administrators and synchronized users had the capability to update the values of the _MobilePhone_ and _AlternateMobilePhones_ attributes in Microsoft Entra ID. This is no longer possible for synchronized users. When this was possible the synchronization API was not honoring updates to these attributes when they originated from on-premises Active Directory. This was commonly known as a “DirSyncOverrides” feature. Administrators noticed this behavior when updates to _mobile_ or _otherMobile_ attributes in Active Directory did not update the corresponding user’s _MobilePhone_ or _AlternateMobilePhones_ in Microsoft Entra ID accordingly, even though the object was successfully synchronized through Microsoft Entra Connect's engine.
 
## Identifying users with different Mobile values
 
You can export a list of users with different Mobile values between Active Directory and Microsoft Entra ID using *‘Compare-ADSyncToolsDirSyncOverrides’* from *ADSyncTools* PowerShell module. This will allow you to determine the users and respective values that are different between on-premises Active Directory and Microsoft Entra ID. This is important to know because enabling the BypassDirSyncOverridesEnabled feature will overwrite all the different values in Microsoft Entra ID with the value coming from on-premises Active Directory.
 
 
### Using Compare-ADSyncToolsDirSyncOverrides
 
Install-Module ADSyncTools
```
 
To compare all the synchronized user’s Mobile values, run the following command:
+12 / -21 lines changed
Commit: Acrolinx fixes to improve score in quality and clarity.
Changes:
Before
After
---
title: Users aren't being provisioned in my application
description: How to troubleshoot common issues faced when you don't see users appearing in a Microsoft Entra Gallery Application you have configured for user provisioning with Microsoft Entra ID
 
author: kenwith
manager: femila
ms.service: entra-id
ms.subservice: app-provisioning
ms.topic: how-to
ms.date: 03/04/2025
ms.author: kenwith
ms.reviewer: arvinh
ai-usage: ai-assisted
---
 
# No users are being provisioned
>[!NOTE]
>Starting 04/16/2020 we have changed the behavior for users assigned the default access role. See the section below for details.
>
After automatic provisioning has been configured for an application (including verifying that the app credentials provided to Microsoft Entra ID to connect to the app are valid), then users and/or groups are provisioned to the app. Provisioning is determined by the following things:
---
title: Users aren't being provisioned in my application
description: Troubleshoot common issues faced when a user isn't appearing in a Microsoft Entra Gallery Application configured for user provisioning with Microsoft Entra ID.
#customer intent: As an IT admin, I want to troubleshoot why users aren't being provisioned in a Microsoft Entra Gallery Application so that I can resolve the issue and ensure proper user access.
author: kenwith
manager: femila
ms.service: entra-id
ms.subservice: app-provisioning
ms.topic: how-to
ms.date: 04/15/2025
ms.author: kenwith
ms.reviewer: arvinh
ai-usage: ai-assisted
---
 
# No users are being provisioned
After automatic provisioning is configured for an application (including verifying that the app credentials provided to Microsoft Entra ID to connect to the app are valid), then users and/or groups are provisioned to the app. Provisioning is determined by the following things:
 
- Which users and groups have been **assigned** to the application. Provisioning nested groups isn't supported. For more information on assignment, see [Assign a user or group to an enterprise app in Microsoft Entra ID](~/identity/enterprise-apps/assign-user-or-group-access-portal.md).
- Whether or not **attribute mappings** are enabled, and configured to sync valid attributes from Microsoft Entra ID to the app. For more information on attribute mappings, see [Customizing User Provisioning Attribute Mappings for SaaS Applications in Microsoft Entra ID](customize-application-attributes.md).
+26 / -7 lines changed
Commit: remove prepare tenant article
Changes:
Before
After
In this tutorial;
 
> [!div class="checklist"]
> - Create a Node.js app in Visual Studio Code, then install dependencies.
> - Enable the Node.js app to acquire an access token for calling a web API.
 
## Prerequisites
 
- [Tutorial: Prepare your external tenant to authorize a Node.js daemon application](tutorial-daemon-node-call-api-prepare-tenant.md).
- A protected web API that is running and ready to accept requests. If you haven't created one, see the [create a protected web API tutorial](./tutorial-web-api-dotnet-core-build-app.md). Ensure this web API is using the app registration details you created in the [prepare tenant tutorial](tutorial-daemon-node-call-api-prepare-tenant.md). Make sure your web API exposes the following endpoints via HTTPS:
- `GET /api/todolist` to get all todos.
- `POST /api/todolist` to add a TODO.
- [Node.js](https://nodejs.org).
- Although any integrated development environment (IDE) that supports React applications can be used, this tutorial uses [Visual Studio Code](https://visualstudio.microsoft.com/downloads/).
- Registration details for the Node.js daemon app and web API you created in the [prepare tenant tutorial](tutorial-daemon-node-call-api-prepare-tenant.md).
 
## Create the Node.js daemon project
 
 
 
In this tutorial;
 
> [!div class="checklist"]
> - Configure app roles for the web API
> - Grant permissions to the daemon app
> - Create a Node.js app in Visual Studio Code, then install dependencies.
> - Enable the Node.js app to acquire an access token for calling a web API.
 
## Prerequisites
 
* Register a new client app in the [Microsoft Entra admin center](https://entra.microsoft.com), configured for *Accounts in any organizational directory and personal Microsoft accounts*. Refer to [Register an application](quickstart-register-app.md) for more details. Record the following values from the application **Overview** page for later use:
* Application (client) ID
* Directory (tenant) ID
* Directory (tenant) domain name (for example, *contoso.onmicrosoft.com* or *contoso.com*).
* Add a client secret to your client app registration. **Do not** use client secrets in production apps. Use certificates or federated credentials instead. For more information, see [add credentials to your application](./how-to-add-credentials.md?tabs=client-secret).
 
* A protected web API that is running and ready to accept requests. If you haven't created one, see the [create a protected web API tutorial](./tutorial-web-api-dotnet-core-build-app.md). Ensure this web API is using the app registration details you created in the [prepare tenant tutorial](tutorial-daemon-node-call-api-prepare-tenant.md). Make sure your web API exposes the following endpoints via HTTPS:
* `GET /api/todolist` to get all todos.
* `POST /api/todolist` to add a TODO.
* [Node.js](https://nodejs.org).
+15 / -15 lines changed
Commit: Acrolinx fixes to improve quality and clarity.
Changes:
Before
After
---
title: Known issues with System for Cross-Domain Identity Management (SCIM) 2.0 protocol compliance
description: How to solve common protocol compatibility issues faced when adding a non-gallery application that supports SCIM 2.0 to Microsoft Entra ID
 
author: kenwith
manager: femila
ms.service: entra-id
ms.subservice: app-provisioning
ms.topic: reference
ms.date: 03/04/2025
ms.author: kenwith
ms.reviewer: arvinh
ai-usage: ai-assisted
 
# Known issues and resolutions with SCIM 2.0 protocol compliance of the Microsoft Entra user provisioning service
 
Microsoft Entra ID can automatically provision users and groups to any application or system that is fronted by a web service with the interface defined in the [System for Cross-Domain Identity Management (SCIM) 2.0 protocol specification](https://tools.ietf.org/html/draft-ietf-scim-api-19).
 
Microsoft Entra support for the SCIM 2.0 protocol is described in [Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Microsoft Entra ID to applications](use-scim-to-provision-users-and-groups.md), which lists the specific parts of the protocol that it implements in order to automatically provision users and groups from Microsoft Entra ID to applications that support SCIM 2.0.
 
---
title: Known issues with System for Cross-Domain Identity Management (SCIM) 2.0 protocol compliance
description: How to solve common protocol compatibility issues faced when adding a non-gallery application that supports SCIM 2.0 to Microsoft Entra ID
#customer intent: As an IT admin, I want to understand SCIM 2.0 compliance issues so that I can troubleshoot provisioning problems with non-gallery applications.
author: kenwith
manager: femila
ms.service: entra-id
ms.subservice: app-provisioning
ms.topic: reference
ms.date: 04/15/2025
ms.author: kenwith
ms.reviewer: arvinh
ai-usage: ai-assisted
 
# Known issues and resolutions with SCIM 2.0 protocol compliance of the Microsoft Entra user provisioning service
 
Microsoft Entra ID can automatically provision users and groups to any application or system fronted by a web service with the interface defined in the [System for Cross-Domain Identity Management (SCIM) 2.0 protocol specification](https://tools.ietf.org/html/draft-ietf-scim-api-19).
 
Microsoft Entra support for the SCIM 2.0 protocol is described in [Using System for Cross-Domain Identity Management (SCIM) to automatically provision users and groups from Microsoft Entra ID to applications](use-scim-to-provision-users-and-groups.md), which lists the specific parts of the protocol that it implements in order to automatically provision users and groups from Microsoft Entra ID to applications that support SCIM 2.0.
 
Modified by shlipsey3 on Apr 16, 2025 7:11 AM
📖 View on learn.microsoft.com
+13 / -15 lines changed
Commit: cleanup
Changes:
Before
After
ms.service: entra-id-protection
 
ms.topic: conceptual
ms.date: 02/28/2025
 
author: shlipsey3
ms.author: sarahlipsey
---
# Microsoft Entra ID Protection for B2B Users
 
Microsoft Entra ID Protection detects compromised credentials for Microsoft Entra users, including B2B users. If your credential is detected as compromised, it means that someone else might have your password and be using it illegitimately. To prevent further risk to your account, it's important to securely reset your password so that the bad actor can no longer use your compromised password. ID Protection marks accounts that might be compromised as "at risk."
 
You can use your organizational credentials to sign-in to another organization as a guest. This process is referred to [business-to-business or B2B collaboration](~/external-id/what-is-b2b.md). Organizations can configure policies to block users from signing-in if their credentials are considered [at risk](concept-identity-protection-risks.md). If your account is at risk and you're blocked from signing-in to another organization as a guest, you might be able to self-remediate your account using the following steps. If your organization didn't enable self-service password reset, your administrator needs to manually remediate your account.
 
## Unblock Your Account
 
If you're attempting to sign-in to another organization as a guest and are blocked due to risk, you see the following block message: "Your account is blocked. We've detected suspicious activity on your account."
 
:::image type="content" source="./media/concept-identity-protection-b2b/risky-guest-user-blocked.png" alt-text="Screenshot of error message showing guest account blocked, contact your organization's administrator.":::
 
ms.service: entra-id-protection
 
ms.topic: conceptual
ms.date: 04/15/2025
 
author: shlipsey3
ms.author: sarahlipsey
---
# Microsoft Entra ID Protection for B2B Users
 
You can use your organizational credentials to sign in to another organization as a guest. This process is referred to [business-to-business or B2B collaboration](../external-id/what-is-b2b.md). Organizations can configure Conditional Access policies to block users from signing in if their credentials are considered [at risk](concept-identity-protection-risks.md). Microsoft Entra ID Protection detects compromised credentials for Microsoft Entra users, including B2B users. If your credential is detected as compromised, it means that someone else might have your password and is using it illegitimately. To prevent further risk to your account, it's important to securely reset your password so that the bad actor can no longer use your compromised password.
 
If your account is at risk and you're blocked from signing in to another organization as a guest, you might be able to self-remediate your account using the steps in this article.
 
## Unblock your account
 
If you're attempting to sign in to another organization as a guest and are blocked due to risk, you see the following block message: "Your account is blocked. We've detected suspicious activity on your account."
 
:::image type="content" source="./media/concept-identity-protection-b2b/risky-guest-user-blocked.png" alt-text="Screenshot of error message showing guest account blocked, contact your organization's administrator.":::
 
Modified by Ortagus Winfrey on Apr 16, 2025 10:25 PM
📖 View on learn.microsoft.com
+15 / -6 lines changed
Commit: Updates to reference custom extension
Changes:
Before
After
 
 
## Reference the custom extension in an access package assignment policy.
TODO: Add introduction sentence(s)
[Include a sentence or two to explain only what is needed to complete the procedure.]
TODO: Add ordered list of procedure steps
1. Step 1
1. Step 2
1. Step 3
 
## Configure the Logic App and corresponding business logic.
TODO: Add introduction sentence(s)
 
 
 
 
 
 
 
 
 
 
## Reference the custom extension in an access package assignment policy.
 
Once you've created the custom extension and Logic app, you can reference the custom extension in an access package assignment policy by doing the following steps:
 
1. Select the catalog in which the custom extension was created.
 
1. On the catalog screen, select **Access packages**, and select the access package for the policy you want to update.
 
1. On the access package overview page, select **Policies**, and select the policy to edit.
:::image type="content" source="media/entitlement-management-dynamic-approval/access-package-policies-list.png" alt-text="Screenshot of the policies list for an access package.":::
1. On the **Edit policy** screen under **Requests**, set the **Require approval* box to yes, and you will be able to add your custom extension as the first approver.
:::image type="content" source="media/entitlement-management-dynamic-approval/custom-extension-approver.png" alt-text="Screenshot of the custom extension as first approver in access package policy.":::
1. Select **Update**.
 
Once updated, you can go to the edited policy, and confirm the change by selecting **Approval stage details**:
:::image type="content" source="media/entitlement-management-dynamic-approval/access-package-approval-stage-details.png" alt-text="Screenshot of edited approval stage details.":::
 
## Configure the Logic App and corresponding business logic.
Modified by Michele Martin on Apr 16, 2025 2:51 AM
📖 View on learn.microsoft.com
+9 / -9 lines changed
Commit: Acrolinx fixes
Changes:
Before
After
> [!IMPORTANT]
>
> - **As of July 12, 2021**, if Microsoft Entra B2B customers set up new Google integrations for use with self-service sign-up for their custom or line-of-business applications, authentication with Google identities won’t work until authentications are moved to system web-views. [Learn more](google-federation.md#deprecation-of-web-view-sign-in-support).
> - **On September 30, 2021**, Google [deprecated embedded web-view sign-in support](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). If your apps authenticate users with an embedded web-view and you're using Google federation with [Azure AD B2C](/azure/active-directory-b2c/identity-provider-google) or Microsoft Entra B2B for [external user invitations](google-federation.md) or [self-service sign-up](identity-providers.md), Google Gmail users won't be able to authenticate. [Learn more](google-federation.md#deprecation-of-web-view-sign-in-support).
 
## Create an API connector
 
Custom attributes exist in the **extension_\<extensions-app-id>_AttributeName** format in the directory. Your API should expect to receive claims in this same serialized format. For more information on custom attributes, see [define custom attributes for self-service sign-up flows](user-flow-add-custom-attributes.md).
 
Additionally, the claims are typically sent in all request:
- **UI Locales ('ui_locales')** - An end-user's locale(s) as configured on their device. This can be used by your API to return internationalized responses.
<!-- - **Step ('step')** - The step or point on the user flow that the API connector was invoked for. Values include:
- `PostFederationSignup` - corresponds to "After federating with an identity provider during sign-up"
- `PostAttributeCollection` - corresponds to "Before creating the user"
- **Email Address ('email')** or [**identities ('identities')**](/graph/api/resources/objectidentity) - these claims can be used by your API to identify the end-user that is authenticating to the application.
 
> [!IMPORTANT]
> If a claim does not have a value at the time the API endpoint is called, the claim will not be sent to the API. Your API should be designed to explicitly check and handle the case in which a claim is not in the request.
 
## Enable the API connector in a user flow
> [!IMPORTANT]
>
> - **As of July 12, 2021**, if Microsoft Entra B2B customers set up new Google integrations for use with self-service sign-up for their custom or line-of-business applications, authentication with Google identities won’t work until authentications are moved to system web-views. [Learn more](google-federation.md#deprecation-of-web-view-sign-in-support).
> - **On September 30, 2021**, Google [deprecated embedded web-view sign-in support](https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html). If your apps authenticate users with an embedded web-view and you're using Google federation with [Azure AD B2C](/azure/active-directory-b2c/identity-provider-google) or Microsoft Entra B2B for [external user invitations](google-federation.md) or [self-service sign-up](identity-providers.md), Google Gmail users can't authenticate. [Learn more](google-federation.md#deprecation-of-web-view-sign-in-support).
 
## Create an API connector
 
Custom attributes exist in the **extension_\<extensions-app-id>_AttributeName** format in the directory. Your API should expect to receive claims in this same serialized format. For more information on custom attributes, see [define custom attributes for self-service sign-up flows](user-flow-add-custom-attributes.md).
 
Additionally, the claims are typically sent in all request:
- **UI Locales ('ui_locales')** - An end-user's locales as configured on their device, which your API can use to return internationalized responses.
<!-- - **Step ('step')** - The step or point on the user flow that the API connector was invoked for. Values include:
- `PostFederationSignup` - corresponds to "After federating with an identity provider during sign-up"
- `PostAttributeCollection` - corresponds to "Before creating the user"
- **Email Address ('email')** or [**identities ('identities')**](/graph/api/resources/objectidentity) - these claims can be used by your API to identify the end-user that is authenticating to the application.
 
> [!IMPORTANT]
> If a claim doesn't have a value at the time the API endpoint is called, it isn't sent to the API. Your API should be designed to explicitly check and handle the case in which a claim isn't in the request.
 
## Enable the API connector in a user flow
+8 / -8 lines changed
Commit: Update authenticate-application-id.md
Changes:
Before
After
> - It is recommended to use the TPM to provide a hardware-based security boundary, as opposed to the Local Machine store. To check the status of your TPM use the [Get-TPM](/powershell/module/trustedplatformmodule/get-tpm?view=windowsserver2025-ps) PowerShell cmdlet. If using Hyper-V VMs, the TPM can be enabled by checking Security &gt; Enable Trusted Platform Module. This can only be done on a generation 2 virtual machines. Generation 1 virtual machines can't be converted to a generation 2 virtual machines. For more information see [Generation 2 virtual machine security settings for Hyper-V](/windows-server/virtualization/hyper-v/learn-more/generation-2-virtual-machine-security-settings-for-hyper-v) and [Enable Trusted launch on existing Azure Gen2 VMs](/azure/virtual-machines/trusted-launch-existing-vm)
 
### BYOC Prerequisites
- A certificate is created in an HSM using a CNG provider and the private key is marked as non-exportable. The following certificate configurations are supported:
- KeyLength: 2048
- KeyAlgorithm: RSA
- KeyHashAlgorithm: SHA256
 
- Managed by Microsoft Entra Connect:
``` powershell
Add-EntraApplicationRegistration –UserPrincipalName <AdminUserPrincipalName>
```
 
- Use BYOC:
> [!NOTE]
> The certificate thumbprint needs to be provided when registering the application.
 
``` powershell
> - It is recommended to use the TPM to provide a hardware-based security boundary, as opposed to the Local Machine store. To check the status of your TPM use the [Get-TPM](/powershell/module/trustedplatformmodule/get-tpm?view=windowsserver2025-ps) PowerShell cmdlet. If using Hyper-V VMs, the TPM can be enabled by checking Security &gt; Enable Trusted Platform Module. This can only be done on a generation 2 virtual machines. Generation 1 virtual machines can't be converted to a generation 2 virtual machines. For more information see [Generation 2 virtual machine security settings for Hyper-V](/windows-server/virtualization/hyper-v/learn-more/generation-2-virtual-machine-security-settings-for-hyper-v) and [Enable Trusted launch on existing Azure Gen2 VMs](/azure/virtual-machines/trusted-launch-existing-vm)
 
### BYOC Prerequisites
- A certificate is created in an HSM or TPM using a CNG provider and the private key is marked as non-exportable. The following certificate configurations are supported:
- KeyLength: 2048
- KeyAlgorithm: RSA
- KeyHashAlgorithm: SHA256
 
- Managed by Microsoft Entra Connect:
``` powershell
Add-EntraApplicationRegistration –UserPrincipalName <AdminUserPrincipalName>
```
 
- Use BYOC:
> [!NOTE]
> The certificate thumbprint needs to be provided when registering the application.
 
``` powershell
+5 / -9 lines changed
Commit: adding-fixed-code-snippet
Changes:
Before
After
 
```javascript
/**
* Configuration object to be passed to MSAL instance on creation.
* For a full list of MSAL.js configuration parameters, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/configuration.md
*/
const msalConfig = {
auth: {
// WORKFORCE TENANT
authority: "https://login.microsoftonline.com/Enter_the_Tenant_Info_Here", // Replace the placeholder with your tenant info
redirectUri: '/', // You must register this URI on App Registration. Defaults to window.location.href e.g. http://localhost:3000/
msalConfig: msalConfig,
loginRequest: loginRequest,
};
module.exports = {
msalConfig: msalConfig,
loginRequest: loginRequest,
};
}
 
```javascript
/**
* Configuration object to be passed to MSAL instance on creation.
* For a full list of MSAL.js configuration parameters, visit:
* https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/configuration.md
*/
const msalConfig = {
auth: {
clientId: "Enter_the_Application_Id_Here",
// WORKFORCE TENANT
authority: "https://login.microsoftonline.com/Enter_the_Tenant_Info_Here", // Replace the placeholder with your tenant info
redirectUri: '/', // You must register this URI on App Registration. Defaults to window.location.href e.g. http://localhost:3000/
msalConfig: msalConfig,
loginRequest: loginRequest,
};
}
 
```
 
Modified by shlipsey3 on Apr 16, 2025 6:32 AM
📖 View on learn.microsoft.com
+0 / -14 lines changed
Commit: idp-faqs-041525
Changes:
Before
After
 
:::image type="content" source="media/workbook-risk-based-policy-impact/workbook-risk-based-impact-trusted-network.png" alt-text="Screenshot showing the trusted network section of the workbook." lightbox="media/workbook-risk-based-policy-impact/workbook-risk-based-impact-trusted-network.png":::
 
## FAQs
 
### What if I don’t use Microsoft Entra for multifactor authentication?
 
If you don’t use Microsoft Entra multifactor authentication, you might still see sign-in risk remediated in your environment if you use a non-Microsoft MFA provider. [External authentication methods](/entra/identity/authentication/how-to-authentication-external-method-manage) make it possible to remediate risk when using a non-Microsoft MFA provider.
 
### What if I am in a hybrid environment?
 
User risk can be self-remediated using a [secure password change](howto-identity-protection-remediate-unblock.md#user-self-remediation) if self-service password reset is enabled with password writeback. If only password hash sync is enabled, consider enabling [allow on-premises password reset to remediate user risk](howto-identity-protection-remediate-unblock.md#allow-on-premises-password-reset-to-remediate-user-risks).
 
### I just received a high-risk alert but they aren't showing up in this report?
 
If the user is assigned high risk, but hasn't signed-in yet, you don't see them in this report. The report only uses sign-in logs to populate this data. If you have high risk users that haven't signed in, they aren't counted in this report.
 
## Next steps
 
- [What are Microsoft Entra workbooks?](../identity/monitoring-health/overview-workbooks.md)
 
:::image type="content" source="media/workbook-risk-based-policy-impact/workbook-risk-based-impact-trusted-network.png" alt-text="Screenshot showing the trusted network section of the workbook." lightbox="media/workbook-risk-based-policy-impact/workbook-risk-based-impact-trusted-network.png":::
 
## Next steps
 
- [What are Microsoft Entra workbooks?](../identity/monitoring-health/overview-workbooks.md)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Modified by Chris Werner on Apr 16, 2025 1:13 AM
📖 View on learn.microsoft.com
+4 / -9 lines changed
Commit: remove prepare tenant article
Changes:
Before
After
* Application Developer
* Cloud Application Administrator
* A workforce tenant. You can use your Default Directory or [set up a new tenant](./quickstart-create-new-tenant.md).
* Register a new app in the [Microsoft Entra admin center](https://entra.microsoft.com) with the following configuration. For more information, see [Register an application](quickstart-register-app.md).
* **Name**: *identity-client-daemon-app*
* **Supported account types**: *Accounts in this organizational directory only (Single tenant)*
 
#### [.NET](#tab/asp-dot-net-core-workforce)
 
 
---
 
## Create a client secret
 
[!INCLUDE [add-app-client-secret](../external-id/customers/includes/register-app/add-app-client-secret.md)]
 
[!INCLUDE [client-credential-advice](./includes/register-app/client-credential-advice.md)]
 
## Grant API permissions to the daemon app
 
* Application Developer
* Cloud Application Administrator
* A workforce tenant. You can use your Default Directory or [set up a new tenant](./quickstart-create-new-tenant.md).
* Register a new app in the [Microsoft Entra admin center](https://entra.microsoft.com), configured for *Accounts in this organizational directory only*. Refer to [Register an application](quickstart-register-app.md) for more details. Record the following values from the application **Overview** page for later use:
* Application (client) ID
* Directory (tenant) ID
* Add a client secret to your app registration. **Do not** use client secrets in production apps. Use certificates or federated credentials instead. For more information, see [add credentials to your application](./how-to-add-credentials.md?tabs=client-secret).
 
#### [.NET](#tab/asp-dot-net-core-workforce)
 
 
---
 
## Grant API permissions to the daemon app
 
For daemon app to access data in Microsoft Graph API, you grant it the permissions it needs. The daemon app needs application type permissions. Users can't interact with a daemon application, so the tenant administrator must consent to these permissions. Use the following steps to grant and consent to the permissions:
 
 
 
 
+6 / -6 lines changed
Commit: recommendations-041525
Changes:
Before
After
ms.service: entra-id
ms.topic: overview
ms.subservice: monitoring-health
ms.date: 01/22/2025
ms.author: sarahlipsey
ms.reviewer: deawari
 
| AAD Connect Deprecated | Tenant | Preview | No | Hybrid Identity Administrator |
| [Convert per-user MFA to Conditional Access MFA](recommendation-turn-off-per-user-mfa.md) | Users | Generally available | No | Security Administrator |
| Designate more than one Global Administrator | Users | Generally available | Yes | Global Administrator |
| Do not allow users to grant consent to unreliable applications | Tenant | Preview | Yes | Global Administrator |
| Do not expire passwords | Tenant | Preview | Yes | Global Administrator |
| Enable password hash sync if hybrid | Tenant | Generally available | Yes | Hybrid Identity Administrator |
| Enable policy to block legacy authentication | Users | Generally available | Yes | Conditional Access Administrator, Security Administrator |
| Enable self-service password reset | Users | Preview | Yes | Authentication Policy Administrator |
| Ensure all users can complete multifactor authentication | Users | Preview | Yes | Conditional Access Administrator, Security Administrator |
| [Migrate applications from AD FS to Microsoft Entra ID](recommendation-migrate-apps-from-adfs-to-azure-ad.md) | Applications | Generally available | No | Application Administrator, Authentication Administrator Hybrid Identity Administrator |
| [Migrate applications from the retiring Azure AD Graph APIs to Microsoft Graph](recommendation-migrate-to-microsoft-graph-api.md) | Applications | Preview | No | Application Administrator |
| [Migrate from ADAL to MSAL](recommendation-migrate-from-adal-to-msal.md) | Applications | Generally available | No | Application Administrator |
| Require MFA for administrative roles | Users | Generally available | Yes | Conditional Access Administrator, Security Administrator |
ms.service: entra-id
ms.topic: overview
ms.subservice: monitoring-health
ms.date: 04/15/2025
ms.author: sarahlipsey
ms.reviewer: deawari
 
| AAD Connect Deprecated | Tenant | Preview | No | Hybrid Identity Administrator |
| [Convert per-user MFA to Conditional Access MFA](recommendation-turn-off-per-user-mfa.md) | Users | Generally available | No | Security Administrator |
| Designate more than one Global Administrator | Users | Generally available | Yes | Global Administrator |
| Do not allow users to grant consent to unreliable applications | Tenant | Generally available | Yes | Global Administrator |
| Do not expire passwords | Tenant | Generally available | Yes | Global Administrator |
| Enable password hash sync if hybrid | Tenant | Generally available | Yes | Hybrid Identity Administrator |
| Enable policy to block legacy authentication | Users | Generally available | Yes | Conditional Access Administrator, Security Administrator |
| Enable self-service password reset | Users | Generally available | Yes | Authentication Policy Administrator |
| Ensure all users can complete multifactor authentication | Users | Generally available | Yes | Conditional Access Administrator, Security Administrator |
| [Migrate applications from AD FS to Microsoft Entra ID](recommendation-migrate-apps-from-adfs-to-azure-ad.md) | Applications | Generally available | No | Application Administrator, Authentication Administrator Hybrid Identity Administrator |
| [Migrate applications from the retiring Azure AD Graph APIs to Microsoft Graph](recommendation-migrate-to-microsoft-graph-api.md) | Applications | Preview | No | Application Administrator |
| [Migrate from ADAL to MSAL](recommendation-migrate-from-adal-to-msal.md) | Applications | Generally available | No | Application Administrator |
| Require MFA for administrative roles | Users | Generally available | Yes | Conditional Access Administrator, Security Administrator |
+5 / -6 lines changed
Commit: open-pr
Changes:
Before
After
---
title: Sign in users in a React SPA by using native authentication
description: Learn how to configure a sample React single-page application that uses native authentication API to sign up users.
 
author: kengaderdus
manager: mwongerapk
ms.author: kengaderdus
#Customer intent: As a developer, I want to configure a sample React single-page application using native authentication so that I can authenticate users, including sign-up, sign-in, sign-out, and password reset flows.
---
 
# Quickstart: Sign in users in a sample React single-page application by using native authentication (preview)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
In this quickstart, you use a React single-page application (SPA) to demonstrate how to authenticate users by using [native authentication API](reference-native-authentication-api.md). The sample app demonstrates user sign-up, sign in, sign out and password reset with an email and a password.
 
## Prerequisites
 
* [Add your application to the user flow](/entra/external-id/customers/how-to-user-flow-add-application)
* [Node.js](https://nodejs.org/en/download/).
---
title: "Sign in users in a React single-page app (SPA) by using native authentication"
description: Learn how to configure a sample React single-page app (SPA) that uses native authentication API to sign up users.
author: kengaderdus
manager: mwongerapk
ms.author: kengaderdus
#Customer intent: As a developer, I want to configure a sample React single-page application using native authentication so that I can authenticate users, including sign-up, sign-in, sign-out, and password reset flows.
---
 
# Quickstart: Sign in users in a React single-page app by using native authentication (preview)
 
[!INCLUDE [applies-to-external-only](../external-id/includes/applies-to-external-only.md)]
 
In this quickstart, you use a React single-page application (SPA) to demonstrate how to authenticate users by using [native authentication API](reference-native-authentication-api.md). The sample app demonstrates user sign-up, sign-in, sign-out and password reset with an email and a password.
 
## Prerequisites
 
* [Add your application to the user flow](/entra/external-id/customers/how-to-user-flow-add-application)
* [Node.js](https://nodejs.org/en/download/).
* [Visual Studio Code](https://code.visualstudio.com/download) or another code editor.
+5 / -6 lines changed
Commit: open-pr
Changes:
Before
After
---
title: "Tutorial: Add sign-in and sign-out flows to a JavaScript SPA"
description: Learn how to add authentication to a JavaScript single-page app (SPA) using the Microsoft identity platform.
author: OwenRichards1
manager: CelesteDG
ms.author: owenrichards
ms.service: entra-external-id
ms.subservice: external
ms.custom: devx-track-js
ms.topic: tutorial
ms.date: 02/11/2024
#Customer intent: As a developer, I want to learn how to configure JavaScript single-page app (SPA) to sign in and sign out users with my external tenant.
---
 
# Tutorial: Add sign-in and sign-out flows to a JavaScript SPA
 
[!INCLUDE [applies-to-workforce-external](../external-id/includes/applies-to-workforce-external.md)]
 
---
title: "Tutorial: Add sign-in and sign-out flows to a JavaScript single-page app (SPA)"
description: Learn how to add authentication to a JavaScript single-page app (SPA) using the Microsoft identity platform.
author: OwenRichards1
manager: CelesteDG
ms.author: owenrichards
ms.service: identity-platform
ms.custom:
ms.topic: tutorial
ms.date: 02/11/2024
#Customer intent: As a developer, I want to learn how to configure JavaScript single-page app (SPA) to sign in and sign out users with my external tenant.
---
 
# Tutorial: Add sign-in and sign-out flows to a JavaScript single-page app
 
[!INCLUDE [applies-to-workforce-external](../external-id/includes/applies-to-workforce-external.md)]
 
 

🗑️ Deleted Documentation Files

DELETED docs/identity-platform/tutorial-daemon-node-call-api-prepare-tenant.md
Deleted by Chris Werner on Apr 16, 2025 1:13 AM
📖 Was available at: https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-daemon-node-call-api-prepare-tenant
-66 lines removed
Commit: remove prepare tenant article
DELETED docs/identity-platform/tutorial-desktop-wpf-dotnet-sign-in-prepare-tenant.md
Deleted by Chris Werner on Apr 16, 2025 12:15 AM
📖 Was available at: https://learn.microsoft.com/en-us/entra/identity-platform/tutorial-desktop-wpf-dotnet-sign-in-prepare-tenant
-65 lines removed
Commit: resolving build errors #2