๐Ÿ“‹ Microsoft Entra Documentation Changes

Changes for May 14th 2025

Period: May 13th 2025, 12:00 AM to May 14th 2025, 12:00 AM

๐Ÿ“š Historical Report: This report shows documentation changes that occurred during the 24-hour period ending on May 14th 2025.

๐Ÿ“Š Summary

55
Total Commits
0
New Files
23
Modified Files
0
Deleted Files
23
Contributors

๐Ÿ“ Modified Documentation Files

+34 / -19 lines changed
Commit: updates
Changes:
Before
After
---
title: Secretless authentication in Azure
description:
 
author: rwike77
manager: CelesteDG
 
# Secretless authentication to Azure resources
 
Passwords and security keys have been the foundation of digital security for decades, but are no longer able to keep up with modern security threats. Secretless, or credential-free authentication, associated with the zero-trust model, is a shift in how access control and user verification are handled within digital environments. Secretless authentication involves designing secure applications in the cloud without relying on traditional, shared credentials such as passwords, certificates, secrets, or security keys. Secretless authentication provides the following benefits:
 
- Reduced credential risks: By eliminating passwords, secretless authentication mitigates risks associated with credential theft, phishing attacks, and brute force attacks. This approach uses verifiable identity elements such as biometrics, digital certificates, and hardware tokens.
- Streamlined access control: It enhances security and streamlines the user experience by relying on mechanisms that verify true identity rather than shared secrets. This aligns with the principles of zero trust by verifying every access request based on true identity.
- Improved end-user experience: Users benefit from a more seamless and secure authentication process, which reduces the need for password resets and improves overall user satisfaction.
 
This article explains secretless authentication options for different Azure application scenarios.
 
### Security challenges with passwords and secrets
 
Passwords and and other secrets should be used with caution, and developers must never place them in an unsecure location. Many apps connect to backend database, cache, messaging, and eventing services using usernames, passwords, and access keys. If exposed, these credentials could be used to gain unauthorized access to sensitive information such as a sales catalog that you built for an upcoming campaign, or customer data that must be private.
---
title: Secretless authentication in Azure
description: Discover secretless authentication options in Azure to reduce credential risks, improve user experience, and align with zero-trust principles.
 
author: rwike77
manager: CelesteDG
 
# Secretless authentication to Azure resources
 
Passwords and security keys were the foundation of digital security for decades, but are no longer able to keep up with modern security threats. Secretless, or credential-free authentication, associated with the zero-trust model, is a shift in how access control and user verification are handled within digital environments. Secretless authentication involves designing secure applications in the cloud without relying on traditional, shared credentials such as passwords, certificates, secrets, or security keys. Secretless authentication provides the following benefits:
 
- Reduced credential risks: By eliminating passwords, secretless authentication mitigates risks associated with credential theft, phishing attacks, and brute force attacks. This approach uses verifiable identity elements such as biometrics, digital certificates, and hardware tokens.
- Streamlined access control: It enhances security and streamlines the user experience by relying on mechanisms that verify true identity rather than shared secrets. This aligns with the principles of zero trust by verifying every access request based on true identity.
- Improved end-user experience: Users benefit from a more seamless and secure authentication process, which reduces the need for password resets and improves overall user satisfaction.
 
This article explores secretless authentication in Azure, its benefits, and how to implement it across various scenarios, including client applications, Azure service-to-service communication, and external workloads.
 
### Security challenges with passwords and secrets
 
Passwords and other secrets should be used with caution, and developers must never place them in an unsecure location. Many apps connect to backend database, cache, messaging, and eventing services using usernames, passwords, and access keys. If exposed, these credentials could be used to gain unauthorized access to sensitive information such as a sales catalog that you built for an upcoming campaign, or customer data that must be private.
+22 / -17 lines changed
Commit: Update how-to-manage-ssh-server-administration.md
Changes:
Before
After
manager: martinco
ms.service: entra
ms.topic: how-to
ms.date: 04/30/2025
ms.author: jricketts
ms.reviewer: mgarciafani
ai-usage: human-only
# Management for SSH-based server administration
There's wide recognition in the IT industry that IT administrators use Secure Shell (SSH) as a critical service. Admins enable security while managing configuration, deployment, and maintenance of servers and applications in an organization's infrastructure. SSH is a secure way to access and manage devices over an unsecured network. SSH encryption protocols, ensure the integrity and confidentiality of administrative tasks and remote system interactions, pivotal for operational efficiency and risk reduction.
In this guide, learn to configure and establish an SSH connection using Microsoft Entra Private Access for enhanced security. Organizations use Private Access to modernize user access to private apps and resources.
You can [learn more about Private Access](concept-private-access.md).
## Establish SSH connections with Private Access
Microsoft Entra Private Access enhances the security and efficiency of SSH management traffic by providing a secure, identity-centric Zero Trust Network Access (ZTNA) solution by It allowing IT administrators to establish SSH connections to remote servers securely.
manager: martinco
ms.service: entra
ms.topic: how-to
ms.date: 05/12/2025
ms.author: jricketts
ms.reviewer: mgarciafani
ai-usage: human-only
# Management for SSH-based server administration
Secure Shell (SSH) is widely recognized across the IT industry as a critical service for system administrators. It provides a secure and encrypted method to access and manage remote systems over unsecured networks.
IT administrators rely on SSH to perform essential tasks securely, including the configuration, deployment, and maintenance of servers and applications in an organizationโ€™s infrastructure.
In this guide, you'll learn how to configure and establish an SSH connection using Microsoft Entra Private Access to enhance security in your remote access workflows.
You can [learn more about Private Access](concept-private-access.md).
## Establish SSH connections with Private Access
Microsoft Entra Private Access enhances the security and efficiency of SSH management traffic by providing a secure, identity-centric Zero Trust Network Access (ZTNA) solution by allowing IT administrators to establish SSH connections to remote servers securely.
Modified by Ryan Wike on May 13, 2025 10:48 AM
๐Ÿ“– View on learn.microsoft.com
+7 / -7 lines changed
Commit: freshness updates
Changes:
Before
After
 
## Application object
 
When you register/update an application, both an application object and a corresponding [service principal object](#service-principal-object) are created/updated for that tenant. The application object *defines* the application's identity configuration globally (across all tenants where it has access), providing a template from which its corresponding service principal object(s) are *derived* for use locally at run-time (in a specific tenant).
 
For more information, see [Application and Service Principal Objects][AAD-App-SP-Objects].
 
 
A credential representing the [resource owner's](#resource-owner) [authorization](#authorization) to access its protected resources, granted to a [client application](#client-application). A client application can use one of the [four grant types defined by the OAuth 2.0 Authorization Framework][OAuth2-AuthZ-Grant-Types] to obtain a grant, depending on client type/requirements: "authorization code grant", "client credentials grant", "implicit grant", and "resource owner password credentials grant". The credential returned to the client is either an [access token](#access-token), or an [authorization code](#authorization-code) (exchanged later for an access token), depending on the type of authorization grant used.
 
The resource owner password credentials grant [shouldn't be used](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/) except in scenarios when other flows can't be used. If you are building a SPA, use the [authorization code flow with PKCE instead of implicit grant](https://devblogs.microsoft.com/identity/migrate-to-auth-code-flow/).
 
## Authorization server
 
 
## Consent
 
The process of a [resource owner](#resource-owner) granting authorization to a [client application](#client-application), to access protected resources under specific [permissions](#permissions), on behalf of the resource owner. Depending on the permissions requested by the client, an administrator or user will be asked for consent to allow access to their organization/individual data respectively. Note, in a [multi-tenant](#multi-tenant-application) scenario, the application's [service principal](#service-principal-object) is also recorded in the tenant of the consenting user.
 
See [consent framework](./application-consent-experience.md) for more information.
 
## Application object
 
When you register/update an application, both an application object and a corresponding [service principal object](#service-principal-object) are created/updated for that tenant. The application object *defines* the application's identity configuration globally (across all tenants where it has access), providing a template from which its corresponding service principal objects are *derived* for use locally at run-time (in a specific tenant).
 
For more information, see [Application and Service Principal Objects][AAD-App-SP-Objects].
 
 
A credential representing the [resource owner's](#resource-owner) [authorization](#authorization) to access its protected resources, granted to a [client application](#client-application). A client application can use one of the [four grant types defined by the OAuth 2.0 Authorization Framework][OAuth2-AuthZ-Grant-Types] to obtain a grant, depending on client type/requirements: "authorization code grant", "client credentials grant", "implicit grant", and "resource owner password credentials grant". The credential returned to the client is either an [access token](#access-token), or an [authorization code](#authorization-code) (exchanged later for an access token), depending on the type of authorization grant used.
 
The resource owner password credentials grant [shouldn't be used](https://news.microsoft.com/features/whats-solution-growing-problem-passwords-says-microsoft/) except in scenarios when other flows can't be used. If you're building a SPA, use the [authorization code flow with PKCE instead of implicit grant](https://devblogs.microsoft.com/identity/migrate-to-auth-code-flow/).
 
## Authorization server
 
 
## Consent
 
The process of a [resource owner](#resource-owner) granting authorization to a [client application](#client-application), to access protected resources under specific [permissions](#permissions), on behalf of the resource owner. Depending on the permissions requested by the client, an administrator or user will be asked for consent to allow access to their organization/individual data respectively. Note, in a [multitenant](#multi-tenant-application) scenario, the application's [service principal](#service-principal-object) is also recorded in the tenant of the consenting user.
 
See [consent framework](./application-consent-experience.md) for more information.
+8 / -6 lines changed
Commit: Minor edits
Changes:
Before
After
---
title: Integrate Darwinbox HR With Microsoft Entra ID
description: Learn how to integrate Darwinbox HR with Microsoft Entra ID to automate user provisioning, manage lifecycle workflows, and streamline HR-driven processes.
#customer intent: As an IT admin, I want to integrate Darwinbox HR with Microsoft Entra ID so that I can automate user provisioning and lifecycle workflows.
author: jenniferf-skc
manager: femila
ms.reviewer: rahuln3223
ms.author: jfields
ms.custom: ai-gen-description
ai-usage: ai-assisted
---
 
 
## Install connectors in Darwinbox Studio
Open Darwinbox studio and navigate to Connector Library. Search for and install the โ€œMicrosoftโ€ and โ€œMicrosoft Entraโ€ connectors:
 
:::image type="content" border="true" source="./media/darwinbox-hr-integration-tutorial/darwinbox-studio.png" alt-text="Screenshot of Darwinbox Studio.":::
 
## Create single-tenant app registration
Next, create a single-tenant app registration and provide the credentials to Darwinbox so they can perform actions like creating the provisioning job and sending user data to your Entra tenant.
---
title: Integrate Darwinbox HR With Microsoft Entra ID
description: Learn how to integrate Darwinbox HR with Microsoft Entra ID to automate user provisioning, manage lifecycle workflows, and streamline HR-driven processes.
author: jenniferf-skc
manager: femila
ms.reviewer: rahuln3223
ms.author: jfields
ms.custom: ai-gen-description
ai-usage: ai-assisted
 
#customer intent: As an IT admin, I want to integrate Darwinbox HR with Microsoft Entra ID so that I can automate user provisioning and lifecycle workflows.
---
 
 
## Install connectors in Darwinbox Studio
Open Darwinbox studio and navigate to Connector Library. Search for and install the โ€œMicrosoftโ€ and โ€œMicrosoft Entraโ€ connectors:
 
:::image type="content" border="true" source="./media/darwinbox-hr-integration-tutorial/darwinbox-studio.png" alt-text="Screenshot of the Darwinbox Studio.":::
 
## Create single-tenant app registration
+5 / -5 lines changed
Commit: freshness updates
Changes:
Before
After
---
title: Tutorial - Web app accesses storage with managed identities
description: In this tutorial, you learn how to access Azure Storage from a web app in Azure App Service by using managed identities.
author: rwike77
manager: CelesteDG
ms.author: ryanwi
ms.custom: azureday1, devx-track-azurecli, devx-track-azurepowershell, subject-rbac-steps
ms.date: 02/07/2024
ms.devlang: csharp
ms.reviewer: stsoneff
ms.service: azure-app-service
 
# Access Azure Storage from a web app using managed identities
 
Learn how to access Azure Storage for a web app (not a signed-in user) running on Azure App Service by using managed identities.
 
:::image type="content" alt-text="Diagram that shows how to access storage." source="./media/multi-service-web-app-access-storage/web-app-access-storage.svg" border="false":::
 
You want to add access to the Azure data plane (Azure Storage, Azure SQL Database, Azure Key Vault, or other services) from your web app. You could use a shared key, but then you have to worry about operational security of who can create, deploy, and manage the secret. It's also possible that the key could be checked into GitHub, which hackers know how to scan for. A safer way to give your web app access to data is to use [managed identities](~/identity/managed-identities-azure-resources/overview.md).
 
---
title: Tutorial - Access Storage from a Web App with managed identities
description: Learn how to access Azure Storage from a web app in Azure App Service using managed identities. Simplify security and avoid managing secrets.
author: rwike77
manager: CelesteDG
ms.author: ryanwi
ms.custom: azureday1, devx-track-azurecli, devx-track-azurepowershell, subject-rbac-steps
ms.date: 05/12/2025
ms.devlang: csharp
ms.reviewer: stsoneff
ms.service: azure-app-service
 
# Access Azure Storage from a web app using managed identities
 
Learn how to access Azure Storage from a web app (not a signed-in user) running on Azure App Service by using managed identities. Simplify security and avoid managing secrets.
 
:::image type="content" alt-text="Screenshot of a diagram showing how a web app accesses Azure Storage using managed identities." source="./media/multi-service-web-app-access-storage/web-app-access-storage.svg" border="false":::
 
You want to add access to the Azure data plane (Azure Storage, Azure SQL Database, Azure Key Vault, or other services) from your web app. You could use a shared key, but then you have to worry about operational security of who can create, deploy, and manage the secret. It's also possible that the key could be checked into GitHub, which hackers know how to scan for. A safer way to give your web app access to data is to use [managed identities](~/identity/managed-identities-azure-resources/overview.md).
 
+5 / -5 lines changed
Commit: added link to Yubikey support topic and updated intro per AI
Changes:
Before
After
ms.service: entra-id
ms.subservice: authentication
ms.topic: conceptual
ms.date: 04/15/2025
 
author: justinha
ms.author: justinha
---
# Passkey (FIDO2) authentication matrix with Microsoft Entra ID
 
Microsoft Entra ID allows passkeys (FIDO2) to be used for multifactor passwordless authentication. This article covers which native apps, web browsers, and operating systems support sign-in using passkey with Microsoft Entra ID.
 
For enabling FIDO2 security keys to unlock a Windows device, see [Enable FIDO2 security key sign-in to Windows 10 and 11 devices with Microsoft Entra ID](howto-authentication-passwordless-security-key-windows.md).
 
> [!NOTE]
> Microsoft Entra ID currently supports only device-bound passkeys stored on FIDO2 security keys or in Microsoft Authenticator. Microsoft is committed to securing customers and users with passkeys, and plans to support synced passkeys for Microsoft Entra ID.
 
## [**Native apps**](#tab/native)
 
The following sections cover support for passkey (FIDO2) authentication in Microsoft Entra ID for:
ms.service: entra-id
ms.subservice: authentication
ms.topic: conceptual
ms.date: 05/12/2025
 
author: justinha
ms.author: justinha
---
# Passkey (FIDO2) authentication matrix with Microsoft Entra ID
 
This article provides a comprehensive overview of passkey (FIDO2) authentication support in Microsoft Entra ID. It outlines compatibility across web browsers, native apps, and operating systems, enabling passwordless multifactor authentication. You'll also find platform-specific considerations, known issues, and guidance for third-party app and identity provider (IdP) support. Use this information to ensure seamless integration and optimal user experiences with passkeys in your environment.
 
For more information about how to sign in with FIDO2 security keys on a Windows device, see [Enable FIDO2 security key sign-in to Windows 10 and 11 devices with Microsoft Entra ID](howto-authentication-passwordless-security-key-windows.md).
 
> [!NOTE]
> Microsoft Entra ID currently supports only device-bound passkeys stored on FIDO2 security keys or in Microsoft Authenticator. Microsoft is committed to securing customers and users with passkeys, and plans to support synced passkeys for Microsoft Entra ID.
 
## [**Native apps**](#tab/native)
 
The next sections cover support for passkey (FIDO2) authentication in Microsoft Entra ID for:
+4 / -2 lines changed
Commit: logs-051225-authrequirement
Changes:
Before
After
ms.service: entra-id
ms.topic: conceptual
ms.subservice: monitoring-health
ms.date: 02/25/2025
ms.author: sarahlipsey
ms.reviewer: egreenberg14
 
 
- **Multifactor authentication:** When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, more MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Microsoft Entra sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.
 
- **Authentication requirement:** Shows the highest level of authentication needed through all the sign-in steps for the sign-in to succeed.
- Graph API supports `$filter` (`eq` and `startsWith` operators only).
 
- **Sign-in event types:** Indicates the category of the sign-in the event represents.
 
 
ms.service: entra-id
ms.topic: conceptual
ms.subservice: monitoring-health
ms.date: 05/12/2025
ms.author: sarahlipsey
ms.reviewer: egreenberg14
 
 
- **Multifactor authentication:** When a user signs in with MFA, several separate MFA events are actually taking place. For example, if a user enters the wrong validation code or doesn't respond in time, more MFA events are sent to reflect the latest status of the sign-in attempt. These sign-in events appear as one line item in the Microsoft Entra sign-in logs. That same sign-in event in Azure Monitor, however, appears as multiple line items. These events all have the same `correlationId`.
 
- **Authentication requirement:** Shows the highest level of authentication reached during the sign-in attempt, but not the highest level of authentication required.
- For sign-in attempts where MFA is required but primary authentication failed, value is `singleFactorAuthentication` because the attempt wasn't evaluated by Conditional Access to require MFA.
- A subsequent sign-in attempt after the failure where primary authentication is successful and MFA is required, the value is `multiFactorAuthentication`.
- Graph API supports `$filter` (`eq` and `startsWith` operators only).
 
- **Sign-in event types:** Indicates the category of the sign-in the event represents.
Modified by Alexander Pavlovsky on May 13, 2025 2:49 AM
๐Ÿ“– View on learn.microsoft.com
+3 / -3 lines changed
Commit: Update tenant-restrictions-v2.md
Changes:
Before
After
## Block Chrome, Firefox and .NET applications like PowerShell
 
To block you need to set up Windows Defender Application Control (WDAC) as well as enable Windows firewall setting.
 
### Set up Windows Defender Application Control (WDAC) to control access to Microsoft resources
 
Connect-MgGraph : ClientSecretCredential authentication failed: AADSTS5000211: A tenant restrictions policy added to this request by a device or network
administrator does not allow access to 'tenant'.
 
- Enable client signaling using Windows GPO. You need to check 'Enable firewall protection on MIcrosoft endpoints' and WDAC enablement. See [Block Chrome, Firefox and .NET applications like PowerShell](#block-chrome-firefox-and-net-applications-like-powershell).
 
## Tenant Restrictions with Microsoft Enterprise SSO plug-in for Apple devices
 
## Known limitation
Tenant Restrictions v2 is supported on all clouds however TRv2 is not enforced with request going across cross clouds.
 
Tenant Restrictions v2 will not work with [macOS Platform signle sign-on (PSSO)](~/identity/devices/troubleshoot-macos-platform-single-sign-on-extension.md) feature with client signaling via corporate proxy. Customers with TRv2 and PSSO should use Universal TRv2 with GSA client signaling. This is an Apple limitation where PSSO is not compatible with tenant restrictions when headers are injected by an intermediary network solution like proxy that uses a certificate trust chain outside of Apple system root certificates.
 
## Next steps
## Block Chrome, Firefox and .NET applications like PowerShell
 
To block you need to set up Windows Defender Application Control (WDAC) as well as enable Windows Firewall setting.
 
### Set up Windows Defender Application Control (WDAC) to control access to Microsoft resources
 
Connect-MgGraph : ClientSecretCredential authentication failed: AADSTS5000211: A tenant restrictions policy added to this request by a device or network
administrator does not allow access to 'tenant'.
 
- Enable client signaling using Windows GPO. You need to check 'Enable firewall protection on Microsoft endpoints' and WDAC enablement. See [Block Chrome, Firefox and .NET applications like PowerShell](#block-chrome-firefox-and-net-applications-like-powershell).
 
## Tenant Restrictions with Microsoft Enterprise SSO plug-in for Apple devices
 
## Known limitation
Tenant Restrictions v2 is supported on all clouds however TRv2 is not enforced with request going across cross clouds.
 
Tenant Restrictions v2 will not work with [macOS Platform single sign-on (PSSO)](~/identity/devices/troubleshoot-macos-platform-single-sign-on-extension.md) feature with client signaling via corporate proxy. Customers with TRv2 and PSSO should use Universal TRv2 with GSA client signaling. This is an Apple limitation where PSSO is not compatible with tenant restrictions when headers are injected by an intermediary network solution like proxy that uses a certificate trust chain outside of Apple system root certificates.
 
## Next steps
+3 / -2 lines changed
Commit: (AzureCXP) fixes MicrosoftDocs/entra-docs#422406
Changes:
Before
After
#### App and app registration are in different tenants, or you're not an admin
If you do not plan on testing your app in the same tenant you registered it in, or you are not an administrator in your tenant, you cannot consent to the permissions from the [Microsoft Entra admin center](https://entra.microsoft.com). You can still consent to some permissions, however, by triggering a sign-in prompt in a web browser.
 
In your app registration in the [Microsoft Entra admin center](https://entra.microsoft.com), go to **Authentication** > **Platform configurations** > **Add a platform** > **Web**. Add the redirect URI "https://localhost" and select **Configure**.
 
There is no way for non-admin users to pre-consent through the Azure portal, so send the following request in a browser. When you are prompted with the login screen, sign in with a test account you created in a previous step. Consent to the permissions you are prompted with. You may need to repeat this step for each API you want to call and test user you want to use.
 
 
To exclude user accounts:
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-application-administrator).
1. Browse to **Entra ID** > **Conditional Access** > **Policies**.
1. Select the Conditional Access policy that requires MFA.
1. Select **Users or workload identities**.
1. Select the **Exclude** tab and then the **Users and groups** checkbox.
 
#### App and app registration are in different tenants, or you're not an admin
If you do not plan on testing your app in the same tenant you registered it in, or you are not an administrator in your tenant, you cannot consent to the permissions from the [Microsoft Entra admin center](https://entra.microsoft.com). You can still consent to some permissions, however, by triggering a sign-in prompt in a web browser.
 
Go to [Microsoft Entra admin center](https://entra.microsoft.com), Navigate to **Identity** > **Applications** > **App registrations**> Select your application from the list. > go to **Authentication** > **Platform configurations** > **Add a platform** > **Web**. Add the redirect URI "https://localhost" and select **Configure**.
 
 
There is no way for non-admin users to pre-consent through the Azure portal, so send the following request in a browser. When you are prompted with the login screen, sign in with a test account you created in a previous step. Consent to the permissions you are prompted with. You may need to repeat this step for each API you want to call and test user you want to use.
 
 
To exclude user accounts:
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-application-administrator).
1. Browse to **Protection** > **Conditional Access** > **Policies**.
1. Select the Conditional Access policy that requires MFA.
1. Select **Users or workload identities**.
1. Select the **Exclude** tab and then the **Users and groups** checkbox.
+2 / -2 lines changed
Commit: added paren about dir sync account
Changes:
Before
After
ms.service: entra-id
ms.subservice: authentication
ms.topic: conceptual
ms.date: 03/04/2025
 
ms.author: justinha
author: justinha
* Billing Administrator
* Compliance Administrator
* Cloud Device Administrator
* Directory Synchronization Accounts
* Directory Writers
* Dynamics 365 Administrator
* Exchange Administrator
ms.service: entra-id
ms.subservice: authentication
ms.topic: conceptual
ms.date: 05/15/2025
 
ms.author: justinha
author: justinha
* Billing Administrator
* Compliance Administrator
* Cloud Device Administrator
* Directory Synchronization Accounts (an admin role assigned to the Microsoft Entra Connect service)
* Directory Writers
* Dynamics 365 Administrator
* Exchange Administrator
+2 / -2 lines changed
Commit: PR-feedback
Changes:
Before
After
| Language / framework | Project on<br/>GitHub | Package | Getting<br/>started | Sign in users | Access web APIs |
| -------------------- | ---------------------- | ------- | :--------------------: | :-----------: | :-------------: |
| React | [MSAL React](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-react)<sup>2</sup> | [msal-react](https://www.npmjs.com/package/@azure/msal-react) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
| JavaScript | [MSAL.js ](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser)<sup>2</sup> | [msal-browser](https://www.npmjs.com/package/@azure/msal-browser) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
| Angular | [MSAL Angular ](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular)<sup>2</sup> | [msal-angular](https://www.npmjs.com/package/@azure/msal-angular) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
 
<!--Image references-->
 
| Language / framework | Project on<br/>GitHub | Package | Getting<br/>started | Sign in users | Access web APIs |
| -------------------- | ---------------------- | ------- | :--------------------: | :-----------: | :-------------: |
| React | [MSAL React](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-react)<sup>2</sup> | [msal-react](https://www.npmjs.com/package/@azure/msal-react) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
| JavaScript | [MSAL.js](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser)<sup>2</sup> | [msal-browser](https://www.npmjs.com/package/@azure/msal-browser) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
| Angular | [MSAL Angular](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-angular)<sup>2</sup> | [msal-angular](https://www.npmjs.com/package/@azure/msal-angular) | [Quickstart](../../quickstart-register-app.md) | ![Library can request ID tokens for user sign-in.][y] | ![Library can request access tokens for protected web APIs.][y] |
 
<!--Image references-->
 
+2 / -2 lines changed
Commit: PR-feedback
Changes:
Before
After
1. Browse to **Entra ID** > **App registrations**, select your application, and then **Authentication**.
1. In the **Web** platform tile under **Redirect URIs**, select the warning banner indicating that you should migrate your URIs.
 
:::image type="content" source="media/migrate-spa-implicit-to-auth-code/portal-01-implicit-warning-banner.png" alt-text="Implicit flow warning banner on web app tile in the Entra admin center":::
 
1. Select *only* those redirect URIs whose applications will use MSAL.js 2.x, and then select **Configure**.
 
:::image type="content" source="media/migrate-spa-implicit-to-auth-code/portal-02-select-redirect-uri.png" alt-text="Select redirect URI pane in SPA pane in the Entra admin center":::
 
These redirect URIs should now appear in the **Single-page application** platform tile, showing that CORS support with the authorization code flow and PKCE is enabled for these URIs.
 
1. Browse to **Entra ID** > **App registrations**, select your application, and then **Authentication**.
1. In the **Web** platform tile under **Redirect URIs**, select the warning banner indicating that you should migrate your URIs.
 
:::image type="content" source="media/migrate-spa-implicit-to-auth-code/portal-01-implicit-warning-banner.png" alt-text="Implicit flow warning banner on web app tile in the Entra admin center.":::
 
1. Select *only* those redirect URIs whose applications will use MSAL.js 2.x, and then select **Configure**.
 
:::image type="content" source="media/migrate-spa-implicit-to-auth-code/portal-02-select-redirect-uri.png" alt-text="Select redirect URI pane in SPA pane in the Entra admin center.":::
 
These redirect URIs should now appear in the **Single-page application** platform tile, showing that CORS support with the authorization code flow and PKCE is enabled for these URIs.
 
Modified by Pratik Jadhav on May 13, 2025 9:57 PM
๐Ÿ“– View on learn.microsoft.com
+1 / -1 lines changed
Commit: (AzureCXP) fixes MicrosoftDocs/entra-docs#426491
Changes:
Before
After
You can manage the [Microsoft Entra Joined Device Local Administrator](~/identity/role-based-access-control/permissions-reference.md#microsoft-entra-joined-device-local-administrator) role from **Device settings**.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Privileged Role Administrator](~/identity/role-based-access-control/permissions-reference.md#privileged-role-administrator).
1. Browse to **Entra ID** > **Devices** > **All devices** > **Device settings**.
1. Select **Manage Additional local administrators on all Microsoft Entra joined devices**.
1. Select **Add assignments** then choose the other administrators you want to add and select **Add**.
 
You can manage the [Microsoft Entra Joined Device Local Administrator](~/identity/role-based-access-control/permissions-reference.md#microsoft-entra-joined-device-local-administrator) role from **Device settings**.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Privileged Role Administrator](~/identity/role-based-access-control/permissions-reference.md#privileged-role-administrator).
1. Browse to **Identity** > **Devices** > **All devices** > **Device settings**.
1. Select **Manage Additional local administrators on all Microsoft Entra joined devices**.
1. Select **Add assignments** then choose the other administrators you want to add and select **Add**.
 
+1 / -1 lines changed
Commit: Fix broken/incorrect links
Changes:
Before
After
- **Application permissions** are for service- or daemon-type applications that need to access a web API as themselves, without user interaction for sign-in or consent. Unless you've defined application roles for your web API, this option is disabled.
 
1. Under **Select permissions**, expand the resource whose scopes you defined for your web API, and select the permissions the client app should have on behalf of the signed-in user.
- If you used the example scope names specified in the [previous quickstart](./quickstart-configure-app-access-web-apis.md), you should see **Employees.Read.All** and `Employees.Write.All`.
1. Select the permission you created while completing the prerequisites, for example, `Employees.Read.All`.
1. Select **Add permissions** to complete the process.
- **Application permissions** are for service- or daemon-type applications that need to access a web API as themselves, without user interaction for sign-in or consent. Unless you've defined application roles for your web API, this option is disabled.
 
1. Under **Select permissions**, expand the resource whose scopes you defined for your web API, and select the permissions the client app should have on behalf of the signed-in user.
- If you used the example scope names specified in the [previous quickstart](./quickstart-configure-app-expose-web-apis.md), you should see **Employees.Read.All** and `Employees.Write.All`.
1. Select the permission you created while completing the prerequisites, for example, `Employees.Read.All`.
1. Select **Add permissions** to complete the process.
Modified by Pratik Jadhav on May 13, 2025 2:30 PM
๐Ÿ“– View on learn.microsoft.com
+1 / -1 lines changed
Commit: (AzureCXP) fixes MicrosoftDocs/entra-docs#419653
Changes:
Before
After
 
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Groups Administrator](~/identity/role-based-access-control/permissions-reference.md#groups-administrator).
1. Select **Microsoft Entra ID**.
>[!NOTE]
>Group owners can also bulk import members of groups they own.
1. Select **Groups** > **All groups**.
 
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Groups Administrator](~/identity/role-based-access-control/permissions-reference.md#groups-administrator).
1. Navigate to **Identity**.
>[!NOTE]
>Group owners can also bulk import members of groups they own.
1. Select **Groups** > **All groups**.