diff --git a/support/entra/entra-id/app-integration/401-unauthorized-aspnet-core-web-api.md b/support/entra/entra-id/app-integration/401-unauthorized-aspnet-core-web-api.md deleted file mode 100644 index f1aad7753e5..00000000000 --- a/support/entra/entra-id/app-integration/401-unauthorized-aspnet-core-web-api.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -title: Troubleshooting 401 Unauthorized Errors in ASP.NET Core Web API with Microsoft Entra ID Authentication -description: Provides guidance for troubleshooting and resolving 401 Unauthorized errors in an ASP.NET Core Web API that uses Microsoft Entra ID authentication. -ms.date: 04/28/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- - -# 401 Unauthorized errors in ASP.NET Core Web API with Microsoft Entra ID - -When you call an ASP.NET Core Web API that's secured by using Microsoft Entra ID authentication, you might encounter a "401 Unauthorized" error. This article provides guidance for using `JwtBearerEvents` to capture detailed logs to troubleshoot these errors. - -## Symptoms - -You use the `[Authorize]` attribute to [secure your ASP.NET Core Web API](/entra/identity-platform/tutorial-web-api-dotnet-core-build-app?tabs=workforce-tenant), as follows: - -```csharp -[Authorize] -public class MyController : ControllerBase -{ - ... -} - -``` - -Or - -```csharp - -public class MyController : ControllerBase -{ - [Authorize] - public ActionResult Get(int id) - { - return "value"; - } - ... -} -``` - -When you call the web API, a "401 Unauthorized" response is returned, but the message contains no error details. - -## Cause - -The API might return a "401 Unauthorized" response in the following scenarios: - -- The request doesn't include a valid "Authorization: Bearer" token header. -- The token is expired or incorrect: - - The token is issued for a different resource. - - The token claims don't meet the application's token validation criteria, as defined in the [JwtBearerOptions.TokenValidationParameters](/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbeareroptions.tokenvalidationparameters) class. - -## Solution - -To debug and resolve "401 Unauthorized" errors, use the `JwtBearerEvents` callbacks to capture and log detailed error information. Follow these steps to implement a custom error-handling mechanism. - -The `JwtBearerEvents` class has the following callback properties (invoked in the following order) that can help you to debug these "401 Access Denied" or "UnAuthorization" issues: - -- [`OnMessageRecieved`](/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbearerevents.onmessagereceived#Microsoft_AspNetCore_Authentication_JwtBearer_JwtBearerEvents_OnMessageReceived) is called first for every request. -- [`OnAuthenticationFailed`](/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbearerevents.onauthenticationfailed) is called if the token doesn't pass the application's token validation criteria. -- [`OnChallenge`](/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbearerevents.onchallenge) is called last before a "401" response is returned. - -### Step 1: Enable PII logging - -By default, personally identifiable information (PII) logging is disabled. Enable it in the **Configure** method of the Startup.cs file for debugging. - -> [!Caution] -> Use 'Microsoft.IdentityModel.Logging.IdentityModelEventSource.ShowPII = true' only in a development environment for debugging. Do not use it in a production environment. - -```csharp -public void Configure(IApplicationBuilder app, IHostingEnvironment env) -{ - if (env.IsDevelopment()) - { - app.UseDeveloperExceptionPage(); - } - else - { - // The default HSTS value is 30 days. You might want to change this value for production scenarios. See https://aka.ms/aspnetcore-hsts. - app.UseHsts(); - } - // turn on PII logging - Microsoft.IdentityModel.Logging.IdentityModelEventSource.ShowPII = true; - - app.UseHttpsRedirection(); - app.UseAuthentication(); - app.UseMvc(); -} -``` - -### Step 2: Create a utility method to format exception messages - -Add a method to format, and flatten any exception messages for better readability: - -```csharp -public static string FlattenException(Exception exception) -{ - var stringBuilder = new StringBuilder(); - while (exception != null) - { - stringBuilder.AppendLine(exception.Message); - stringBuilder.AppendLine(exception.StackTrace); - exception = exception.InnerException; - } - return stringBuilder.ToString(); -} -``` - -### Step 3: Implement JwtBearerEvents callbacks - -Configure the `JwtBearerEvents` callbacks in the `ConfigureServices` method of *Startup.cs* to handle authentication events and log error details: - -```csharp -public void ConfigureServices(IServiceCollection services) -{ -.... - .AddJwtBearer(options => - { - options.Authority = "https://login.microsoftonline.com/.onmicrosoft.com"; - // if you intend to validate only one audience for the access token, you can use options.Audience instead of - // using options.TokenValidationParameters which allow for more customization. - // options.Audience = "10e569bc5-4c43-419e-971b-7c37112adf691"; - - options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters - { - ValidAudiences = new List { "", "10e569bc5-4c43-419e-971b-7c37112adf691" }, - ValidIssuers = new List { "https://sts.windows.net//", "https://sts.windows.net//v2.0" } - }; - - options.Events = new JwtBearerEvents - { - OnAuthenticationFailed = ctx => - { - ctx.Response.StatusCode = StatusCodes.Status401Unauthorized; - message += "From OnAuthenticationFailed:\n"; - message += FlattenException(ctx.Exception); - return Task.CompletedTask; - }, - - OnChallenge = ctx => - { - message += "From OnChallenge:\n"; - ctx.Response.StatusCode = StatusCodes.Status401Unauthorized; - ctx.Response.ContentType = "text/plain"; - return ctx.Response.WriteAsync(message); - }, - - OnMessageReceived = ctx => - { - message = "From OnMessageReceived:\n"; - ctx.Request.Headers.TryGetValue("Authorization", out var BearerToken); - if (BearerToken.Count == 0) - BearerToken = "no Bearer token sent\n"; - message += "Authorization Header sent: " + BearerToken + "\n"; - return Task.CompletedTask; - }, -#For completeness, the sample code also implemented the OnTokenValidated property to log the token claims. This method is invoked when authentication is successful - OnTokenValidated = ctx => - { - Debug.WriteLine("token: " + ctx.SecurityToken.ToString()); - return Task.CompletedTask; - } - }; - }); -... -} -``` - -### Sample results - -When you implement `JwtBearerEvents` callbacks, if a "401 Unauthorized" error occurs, the response output should include such details as the following example: - -```Output -OnMessageRecieved: - -Authorization Header sent: no Bearer token sent. -``` - -If you use the API development tool to debug the request, you should receive error details, as shown in the following screenshot. - -:::image type="content" source="media/401-unauthorized-aspnet-core-web-api/wrong-token.png" alt-text="Screenshot of error details in the API development tool." lightbox="media/401-unauthorized-aspnet-core-web-api/wrong-token.png"::: - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/404-not-found-error-manage-objects-microsoft-graph.md b/support/entra/entra-id/app-integration/404-not-found-error-manage-objects-microsoft-graph.md deleted file mode 100644 index c187f22636c..00000000000 --- a/support/entra/entra-id/app-integration/404-not-found-error-manage-objects-microsoft-graph.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: 404 Error When Managing Objects Using Microsoft Graph -description: Provides a solution to a 404 error when you try to manage a Microsoft Entra object that was just created using Microsoft Graph. -ms.date: 01/07/2025 -ms.reviewer: kakapans, v-weizhu -ms.service: entra-id -ms.custom: sap:Problem with querying or provisioning resources ---- -# 404 error when managing objects using Microsoft Graph - -This article provides a solution to a 404 (object not found) error that occurs when you try to manage a Microsoft Entra object that was just created using Microsoft Graph. - -## Symptoms - -Suppose you create an object, such as a user, group, or application, in Microsoft Entra ID using Microsoft Graph. When trying to manage the object, such as getting, updating, or patching it, shortly after its creation, you receive a 404 (object not found) error.  - -## Cause - -The [Microsoft Entra ID architecture](/entra/architecture/architecture) ensures that all data is replicated across geographically distributed data centers. This issue occurs due to a replication delay in propagating the newly created object across all data centers. This replication process might take several minutes to complete. - -As shown in the following diagram, when your application makes a request via Microsoft Graph to create a user in Microsoft Entra ID, the service begins the replication process and returns an object for that user, which includes the user's ID and other relevant data used in your request. If your application immediately tries to update this user, it might connect to a replica that hasn't yet been updated with the new user object. So, you receive a 404 error because the user isn't found on that replica. - - :::image type="content" source="media/404-not-found-error-manage-objects-microsoft-graph/404-not-found-error-diagram.png" alt-text="Diagram that explains the cause of the 404 error." border="false"::: - -## Solution - -To resolve this issue, wait some time and retry the update request. If the 404 error still occurs after retrying, double your waiting time and try again. By allowing sufficient time for replication, you can prevent this error from happening again. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/android-app-authentication-fails-after-published-to-google-play-store.md b/support/entra/entra-id/app-integration/android-app-authentication-fails-after-published-to-google-play-store.md deleted file mode 100644 index 1421c0626b6..00000000000 --- a/support/entra/entra-id/app-integration/android-app-authentication-fails-after-published-to-google-play-store.md +++ /dev/null @@ -1,158 +0,0 @@ ---- -title: Android App Authentication Fails After Being Published to Google Play Store -description: Provides a solution to an authentication failure with an Android app published to the Google Play Store. -ms.reviewer: markbukovich, v-weizhu -ms.service: entra-id -ms.date: 03/25/2025 -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- - -# Authentication fails after an Android app is published to the Google Play Store - -This article provides a solution to an authentication failure that occurs during signing in after users install an Android app published to the Google Play Store. - -## Symptoms - -Consider the following scenario: - -- You have successfully implemented Microsoft Entra authentication in your Android app with the Microsoft Authentication Library (MSAL). -- The app has been built and executed and has passed all QA testing. -- You publish the app to the Google Play Store. - -In this case, after users install the app, authentication doesn't work when signing in to the app. - -If you expose authentication error messages to users, or if you let them send error messages to your team, you might encounter an error message like the following text: - -> The redirect URI in the configuration file doesn't match with the one generated with the package name and signature hash. Please verify the uri in the config file and your app registration in Azure portal. - -Another possible scenario for this issue is: - -During development and QA testing, you set up your app to use a supported broker to handle authentication and single sign-on (SSO). However, after the app is deployed through Google Play and installed, the app no longer uses the broker for authentication. - -## Cause - -When an Android application is built for installation on a device, it's built as an APK compressed package and then signed by a certificate. This certificate signing ensures that the person who built the application is the one who owns the private signing key. This prevents hackers from making harmful modifications to the application, as they can't sign their versions with the original private key. - -Previously, Android developers owned and maintained their private signing keys. Currently, Google Play Services generates and maintains the private signing key for Android developers, ensuring secure storage by Google. The developer still maintains an upload key so that Google Play Services can verify the authenticity of an uploaded app bundle, but the actual signing is performed by the Google-owned signing certificate when users install the app on their devices. - -The MSAL for Android Native and Microsoft Supported Authentication Brokers use the public signature hash of an installed application to identify it when interacting with the Android operating system during authentication. - -The public signature hash of an application installed via Google Play differs from the one installed before publishing to Google Play. Thus, MSAL will be configured with the incorrect signature hash. - -## Solution - -To resolve this issue, do the following things: - -- [Get a new signature hash with the MSAL Package Inspector tool or from the Google Play Console](#get-a-new-signature-hash-with-the-msal-package-inspector-tool-or-from-the-google-play-console). -- [Add a new redirect URI to the app registration in the Azure portal with the new signature hash](#add-a-new-redirect-uri-to-the-app-registration-in-the-azure-portal-with-the-new-signature-hash). -- [Update the MSAL configuration within the application code to use the new redirect URI and signature hash](#update-the-msal-configuration-within-the-application-code-to-use-the-new-redirect-uri-and-signature-hash). - -### Get a new signature hash with the MSAL Package Inspector tool or from the Google Play Console - -You can get a new signature hash by using the MSAL Package Inspector tool or from the Google Play Console. - -To install and use the MSAL Package Inspector, see [Package Inspector for MSAL Android Native Guide](package-inspector-msal-android-native.md). - -To get the signature hash from the Google Play Console, follow these steps: - -1. Go to the Google Play Console and sign in with your Google Developer account. -2. Once you're in the Google Play Console, select the affected app. -3. On the left navigation, under the **Release** category, expand **Setup**, and select **App Integrity**. -4. Select the **App signing** tab. You'll see the fingerprint of the app signing key in three different variations. -5. Copy the **SHA-1 certificate fingerprint** and paste it into the PowerShell script in step 6 as the value of the `$Thumbprint` variable. -6. Run the following script to obtain the base64 encoded fingerprint that MSAL needs: - - ```powershell - $Thumbprint = "paste your fingerprint here" - $Thumbprint = $Thumbprint.Replace(":", "") - - $Bytes = [byte[]]::new($Thumbprint.Length / 2) - - For($i=0; $i -lt $Thumbprint.Length; $i+=2){ - $Bytes[$i/2] = [convert]::ToByte($Thumbprint.Substring($i, 2), 16) - } - - $hashedString =[Convert]::ToBase64String($Bytes) - - Write-Host $hashedString - ``` - - :::image type="content" source="media/android-app-authentication-fails-after-published-to-google-play-store/google-play-console-app-signing.png" alt-text="Screenshot that shows how to get the signature hash from the Google Play Console." lightbox="media/android-app-authentication-fails-after-published-to-google-play-store/google-play-console-app-signing.png"::: - -### Add a new redirect URI to the app registration in the Azure portal with the new signature hash - -> [!NOTE] -> We recommend adding a new redirect URI rather than modifying the existing one. Your app registration can contain many redirect URIs. Additionally, modifying the existing redirect URI might result in problems with the development version of your app. This can cause issues during troubleshooting, development updates, and so on. - -1. Sign in to the Azure portal and navigate to the **App registrations** page. -2. Select the app registration for your Android app. -3. Under **Manage**, select **Authentication**. -4. Under **Platform configurations**, select **Add a platform**. -5. Under **Configure platforms**, select **Android**. - - :::image type="content" source="media/android-app-authentication-fails-after-published-to-google-play-store/app-reg-platform-config.png" alt-text="Screenshot that shows how to configure the Android platform."::: -6. Enter the package name of your Android app. Also, generate and enter the signature hash. - - :::image type="content" source="media/android-app-authentication-fails-after-published-to-google-play-store/app-registrations-configure-android-app.png" alt-text="Screenshot that shows how to configure an Android app."::: - - > [!NOTE] - > It's fine to use the same package name in multiple Android redirect URIs as long as the signature hash is different. -7. Select **Configure** to complete the platform configuration. - -### Update the MSAL configuration within the application code to use the new redirect URI and signature hash - -Update the MSAL configuration file and Android Manifest file in the application code. - -- MSAL configuration file: - - Only change the redirect URI. Copy and paste it directly from the Azure portal. In the Azure portal, the signature hash portion of the redirect URI is HTTP encoded. It should remain HTTP encoded. - - ```json - { - "client_id": "", - "authorization_user_agent": "DEFAULT", - "redirect_uri": "" - "broker_redirect_uri_registered": true, - "authorities": [ - { - "types": "AAD", - "audience": { - "type": "AzureADMyOrg", - "tenant_id": "" - } - } - ], - "logging":{ - "log_level": "VERBOSE", - "logcat_enabled": true - } - } - ``` - -- Android Manifest file: - - Only change the `android:path` property in the `com.microsoft.identity.client.BrowserTabActivity` activity. Paste the signature hash as the value of this property. - - ```xml - - - - - - - - - ``` - - - > [!NOTE] - > - Make sure to include the forward slash in front of the signature hash. - > - Unlike the redirect URI, the signature hash here isn't HTTP encoded. - -[!INCLUDE [Third-party information disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/app-doesnt-appear.md b/support/entra/entra-id/app-integration/app-doesnt-appear.md deleted file mode 100644 index e6c4ac2f5ed..00000000000 --- a/support/entra/entra-id/app-integration/app-doesnt-appear.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Application does not appear after clicking the add button -description: Understand why an application does not appear after clicking the add button. -ms.date: 02/18/2024 -author: bernawy -ms.author: bernaw -editor: v-jsitser -ms.reviewer: v-leedennis, jarrettr -ms.service: entra-id -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Enterprise Applications ---- -# Application does not appear after clicking the add button - -The process of adding an application to Microsoft Entra ID may sometimes fail due to transient issues, networking problems, or a known issue. If you encounter an error when clicking the Add button, you’ll see a Notification in an Error state, which indicates that there was an error when creating the application. To learn more about the error or share it with a support engineer, you can follow the steps in [How to see the details of a portal notification](./send-notification-details.md). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/app-takes-long-time-appear.md b/support/entra/entra-id/app-integration/app-takes-long-time-appear.md deleted file mode 100644 index ee82241f6fa..00000000000 --- a/support/entra/entra-id/app-integration/app-takes-long-time-appear.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Application takes a long time to appear after clicking the "add" button -description: Understand why an application takes a long time to appear after clicking the "add" button. -ms.date: 02/18/2024 -author: bernawy -ms.author: bernaw -editor: v-jsitser -ms.reviewer: v-leedennis, jarrettr -ms.service: entra-id -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Enterprise Applications ---- -# Application takes a long time to appear after clicking the "add" button - -If you experience a delay in the appearance of your application after clicking the "add" button, it is possible that it may take 1-2 minutes (and sometimes longer) for the application to appear in your directory. While this is not the expected performance, you can monitor the progress of the application addition by clicking on the Notifications icon (the bell) in the upper right corner of the Azure portal and looking for an In Progress or Completed notification labeled **Adding application**. - -If your application is not added or you encounter an error when clicking the Add button, you will see a Notification in an Error state. To obtain more information about the error and learn more or share with a support engineer, you can follow the steps in [How to see the details of a portal notification](./send-notification-details.md). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/application-delegated-permission-access-tokens-identity-platform.md b/support/entra/entra-id/app-integration/application-delegated-permission-access-tokens-identity-platform.md deleted file mode 100644 index c4a90749854..00000000000 --- a/support/entra/entra-id/app-integration/application-delegated-permission-access-tokens-identity-platform.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Application and Delegated Permissions for Access Tokens -description: Describes application and delegated permissions for access tokens in the Microsoft identity platform. -ms.reviewer: bachoang, v-weizhu -ms.service: entra-id -ms.date: 01/15/2025 -ms.custom: sap:App registrations ---- -# Application and delegated permissions for access tokens in the Microsoft identity platform - -This article introduces the differences between application and delegated permissions for access tokens in the Microsoft identity platform to help diagnose issues when applications call web APIs. - -## Overview - -As described in the [Overview of permissions and consent in the Microsoft identity platform](/entra/identity-platform/permissions-consent-overview) and [Glossary: Microsoft identity platform](/entra/identity-platform/developer-glossary), there are two types of permissions for an access token: delegated permissions and application permissions. Delegated permissions are granted to a signed-in user, whereas application permissions are granted directly to an application. The key difference is that delegated permissions require user sign-in, while application permissions don't; instead, the application authenticates to Microsoft Entra ID using its own application identity (client ID and secret/assertion). - -Regardless of permission types, you must [configure API permissions](/entra/identity-platform/quickstart-configure-app-access-web-apis#add-permissions-to-access-your-web-api) on the Microsoft Entra **App Registration** page: - -* Select **Application permissions** if your application doesn't need any user to sign in. -* Select **Delegated permissions** if your application requires a user to sign in so that the access token can be issued for that sign-in. - -> [!NOTE] -> When you select **Application permissions**, admin consent must be granted for the permission to function correctly. - -## Permission type tokens issued from OAuth2 authentication flows - -Microsoft Entra ID supports various OAuth2 authentication flows. The kind of authentication flow that an application uses results in specific types of permissions in an access token. - -Application permission tokens can only be obtained from the [client credentials grant flow](/entra/identity-platform/v2-oauth2-client-creds-grant-flow). - -Delegated permission tokens can only be obtained from the following flows: - -* [Implicit grant flow](/azure/active-directory/develop/v2-oauth2-implicit-grant-flow) -* [Authorization code grant flow](/azure/active-directory/develop/v2-oauth2-auth-code-flow) -* [On-Behalf-Of flow](/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow) -* [Device authorization grant flow](/azure/active-directory/develop/v2-oauth2-device-code) -* [Resource Owner Password Credentials grant flow](/azure/active-directory/develop/v2-oauth2-device-code) - -## Identify the permission type for an access token - -To determine whether an access token is a delegated or application permission token, inspect the token claims using a tool like [jwt.ms](https://jwt.ms/). - -For application permission tokens, the permissions are in the `roles` claim: - -```json -"oid": "" -"roles": [ - "User.Read.All" -], -"sub": "" -``` - -> [!NOTE] -> The `scp` claim is absent in application permission tokens. - -For delegated permission tokens, the permissions are in the `scp` claim: - -```json -"scp": "Directory.Read.All User.Read", -"sub": "", -``` - -> [!NOTE] -> The `roles` claim might still appear in a delegated permission token, but it lists the roles assigned to the user in the API app. - -## Identify the permission type an API supports - -Understanding what type of permissions an API supports is essential. Many errors such as 400, 401, 403, and 500 occur when applications call different APIs (for example, Microsoft Graph and Power BI) with incorrect permission type tokens. For an API, different REST endpoints might require different permission types. You can refer to the API endpoint documentation to check the supported permission type. You also need to evaluate whether the authentication flow used in the application generates the desired permission tokens. - -### Example scenario - -Power BI API: While Power BI supports both delegated and application permissions, some tasks, like viewing reports (requiring the **Report.Read.All** permission), can only be performed with a delegated token. On the **App Registration** page, **Application permissions** only support two permissions: **Tenant.Read.All** and **Tenant.ReadWrite.All.** - -:::image type="content" source="media/application-delegated-permission-access-tokens-identity-platform/application-permissions-power-bi-api.png" alt-text="Screenshot that shows application permissions for the Power BI API."::: - -In contrast, **Delegated permissions** offer a richer feature set: - -:::image type="content" source="media/application-delegated-permission-access-tokens-identity-platform/delegated-permissions-power-bi-api.png" alt-text="Screenshot that shows delegated permissions for the Power BI API."::: - -## Troubleshoot issues when calling Microsoft Graph REST endpoints - -Users often encounter issues when their applications call Microsoft Graph REST endpoints. The requests work successfully in Microsoft Graph Explorer but fail in their applications. To troubleshoot these issues, check the following things: - -* Check the permission type the access token has. Microsoft Graph Explorer always uses a delegated permission token. -* Ensure the same user account is used to sign in to Microsoft Graph Explorer and the application. -* Verify if the endpoint supports delegated permissions, application permissions, or both. -* Verify that the access token has the correct permissions to call the endpoint. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/application-using-tls-1dot0-1dot1-authentication-fail.md b/support/entra/entra-id/app-integration/application-using-tls-1dot0-1dot1-authentication-fail.md deleted file mode 100644 index e10f6c6a230..00000000000 --- a/support/entra/entra-id/app-integration/application-using-tls-1dot0-1dot1-authentication-fail.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Microsoft Entra Applications Using TLS 1.0/1.1 Fail to Authenticate -description: Provides solutions to authentication errors that occur with Microsoft Entra applications using TLS version 1.0 or 1.1. -ms.reviewer: bachoang, v-weizhu -ms.service: entra-id -ms.date: 05/09/2025 -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# Microsoft Entra applications using TLS 1.0/1.1 fail to authenticate - -This article provides solutions to authentication errors that occur with Microsoft Entra-integrated applications targeting versions earlier than Microsoft .NET Framework 4.7. - -## Symptoms - -Applications using an older version of the .NET Framework might encounter authentication failures with one of the following error messages: - -- > AADSTS1002016: You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD - -- > IDX20804: Unable to retrieve document from: '[PII is hidden]' - -- > IDX20803: Unable to obtain configuration from: '[PII is hidden]' - -- > IDX10803: Unable to create to obtain configuration from: 'https://login.microsoftonline.com/{Tenant-ID}/.well-known/openid-configuration' - -- > IDX20807: Unable to retrieve document from: 'System.String' - -- > System.Net.Http.Headers.HttpResponseHeaders RequestMessage {Method: POST, RequestUri: '\', Version: 1.1, Content: System.Net.Http.FormUrlEncodedContent, Headers: { Content-Type: application/x-www-form-urlencoded Content-Length: 970 }} System.Net.Http.HttpRequestMessage StatusCode UpgradeRequired This service requires use of the TLS-1.2 protocol - -## Cause - -Starting January 31, 2022, Microsoft enforced the use of the TLS 1.2 protocol for client applications connecting to Microsoft Entra services on the Microsoft Identity Platform to ensure compliance with security and industry standards. For more information about this change, see [Enable support for TLS 1.2 in your environment for Microsoft Entra TLS 1.1 and 1.0 deprecation](../ad-dmn-services/enable-support-tls-environment.md) and [Act fast to secure your infrastructure by moving to TLS 1.2!](https://techcommunity.microsoft.com/blog/microsoft-entra-blog/act-fast-to-secure-your-infrastructure-by-moving-to-tls-1-2/2967457) - -Applications running on older platforms or using older .NET Framework versions might not have TLS 1.2 enabled. Therefore, they can't retrieve the OpenID Connect metadata document, resulting in failed authentication. - -## Solution 1: Upgrade the .NET Framework - -Upgrade the application to use .NET Framework 4.7 or later, where TLS 1.2 is enabled by default. - -## Solution 2: Enable TLS 1.2 programmatically - -If upgrading the .NET Framework isn't feasible, you can enable TLS 1.2 by adding the following code to the **Global.asax.cs** file in your application: - -```csharp -using System.Net; - -protected void Application_Start() -{ -ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3; // only allow TLS 1.2 and SSL 3 -// The rest of your startup code goes here -} -``` - -## Solution 3: Change web.config to enable TLS 1.2 - -If .NET Framework 4.7.2 is available, you can enable TLS 1.2 by adding the following configuration to the **web.config** file: - -```json - -    - -``` - -> [!NOTE] -> If using .NET Framework 4.7.2 causes breaking changes to your app, this solution might not work. - -## Solution 4: Enable TLS 1.2 before running PowerShell commands - -If you encounter the AADSTS1002016 error while running the PowerShell command `Connect-MSolService`, `Connect-AzureAD`, or `Connect-MSGraph` (from the Microsoft Intune PowerShell SDK module), set the security protocol to TLS 1.2 before executing the commands: - -```powershell -[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 -``` - -## References - -[Transport Layer Security (TLS) best practices with .NET Framework](/dotnet/framework/network-programming/tls) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/asp-dot-net-application-infinite-sign-in-loop.md b/support/entra/entra-id/app-integration/asp-dot-net-application-infinite-sign-in-loop.md deleted file mode 100644 index 65026f4fbd7..00000000000 --- a/support/entra/entra-id/app-integration/asp-dot-net-application-infinite-sign-in-loop.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Infinite Sign-in Loop Between ASP.NET Application and Microsoft Entra ID -description: Helps you resolve an infinite sign-in loop issue between an ASP.NET application and with Microsoft Entra ID when performing sign in. -ms.date: 04/25/2025 -ms.reviewer: bachoang, v-weizhu -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- - -# Infinite sign-in loop between ASP.NET application and Microsoft Entra ID - -This article provides solutions to an issue where an ASP.NET application experiences an infinite redirect loop during signing in with Microsoft Entra ID. - -## Symptoms - -An ASP.NET application running an earlier version of Open Web Interface for .NET (OWIN) middleware fails to recognize an authenticated request from Microsoft Entra ID. It keeps sending the request back to Microsoft Entra ID for signing in, leading to the infinite loop issue. The following error message might be displayed in the browser: - -> We couldn't sign you in. Please try again. - -## Cause - -This issue occurs due to a cookie mismanagement issue (a [known Katana bug](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues)) in the earlier version of OWIN. - -### How to recognize the Katana bug - -Capture a Fiddler trace and examine one of the later redirect frames back to the web application. Note in the following screenshot, the request in frame 58 contains multiple OpenIdConnect.nonce cookies (red-circled). In a working scenario, you should only have one OpenIdConnect.nonce cookie set at the beginning before authentication. After the request is successfully authenticated, this nonce cookie is destroyed and ASP.NET sets its own session cookie. Because of this bug, you see a buildup of these nonce cookies. - -:::image type="content" source="media/asp-dot-net-application-infinite-sign-in-loop/openidconnet-nonce-cookies.png" alt-text="Screenshot that shows multiple OpenIdConnect nonce cookies." lightbox="media/asp-dot-net-application-infinite-sign-in-loop/openidconnet-nonce-cookies.png"::: - -## Solution 1: Upgrade to ASP.NET Core - -The issue is resolved in ASP.NET Core and a later version of Katana OWIN for ASP.NET. To resolve this issue, upgrade your application to use ASP.NET Core. - -If you must continue to use ASP.NET, perform the following actions: - -- Update your application's Microsoft.Owin.Host.SystemWeb package to version 3.1.0.0 or later. -- Modify your code to use one of the new cookie manager classes, for example: - - ```csharp - app.UseCookieAuthentication(new CookieAuthenticationOptions - { - AuthenticationType = "Cookies", - CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager() - }); - ``` - or - - ```csharp - app.UseCookieAuthentication(new CookieAuthenticationOptions() - { - CookieManager = new SystemWebCookieManager() - }); - ``` - -## Solution 2: Correct the redirect URL - -In some cases where the application is hosted under a virtual directory or an application instead of the root of the web site, [solution 1](#solution-1-upgrade-to-aspnet-core) might not work. For more information, see [Infinite re-direct loop after AAD Authentication when redirect is specified](https://stackoverflow.com/questions/44397715/infinite-re-direct-loop-after-aad-authentication-when-redirect-is-specified) and [Microsoft Account OAuth2 sign-on fails when redirect URL is not under the website root](https://github.com/aspnet/AspNetKatana/issues/203). - -For example, suppose you have the following environment: - -- The root of a web site: `https://mysite` – This site runs under *Application Pool 1*. -- An application *test2* under the root: `https://mysite/test2` – This application runs under *Application Pool 2*. -- Your ASP.NET application runs under the *test2* application with the following code: - - ```csharp - public void Configuration(IAppBuilder app) - { - // For more information on how to configure your application, visit https://go.microsoft.com/fwlink/?LinkID=316888 - app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); - app.UseCookieAuthentication(new CookieAuthenticationOptions()); - app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - // Sets the ClientId, authority, RedirectUri as obtained from web.config - ClientId = clientId, - Authority = authority, - RedirectUri = "https://mysite/test2", - // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page - PostLogoutRedirectUri = redirectUri, - Scope = OpenIdConnectScope.OpenIdProfile, - // ResponseType is set to request the id_token - which contains basic information about the signed-in user - ResponseType = OpenIdConnectResponseType.IdToken, - // ValidateIssuer set to false to allow personal and work accounts from any organization to sign in to your application - // To only allow users from a single organizations, set ValidateIssuer to true and 'tenant' setting in web.config to the tenant name - // To allow users from only a list of specific organizations, set ValidateIssuer to true and use ValidIssuers parameter - - // OpenIdConnectAuthenticationNotifications configures OWIN to send notification of failed authentications to OnAuthenticationFailed method - - Notifications = new OpenIdConnectAuthenticationNotifications - { - AuthenticationFailed = OnAuthenticationFailed - } - - } - ); - } - ``` - -- You use the following code to trigger the sign-in flow: - - ```csharp - public void SignIn() - { - if (!Request.IsAuthenticated) - { - HttpContext.GetOwinContext().Authentication.Challenge( - new AuthenticationProperties { RedirectUri = "/" }, - OpenIdConnectAuthenticationDefaults.AuthenticationType); - } - } - ``` - -This scenario can result in an authentication infinite loop with a buildup of multiple OpenIdConnect.nonce cookies. The difference is that ASP.NET doesn't appear to set its authenticated session cookies. To resolve the issue in such scenario, set the redirect URLs in the OpenID Connect initialization code and the `Challenge` method (note the trailing slash in the redirect URL): - -```csharp -app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - // Sets the ClientId, authority, RedirectUri as obtained from web.config - ClientId = clientId, - Authority = authority, - RedirectUri = "https://mysite/test2/", - // PostLogoutRedirectUri is the page that users will be redirected to after sign-out. In this case, it is using the home page - PostLogoutRedirectUri = redirectUri, - Scope = OpenIdConnectScope.OpenIdProfile, -... -``` - -```csharp - public void SignIn() - { - if (!Request.IsAuthenticated) - { - HttpContext.GetOwinContext().Authentication.Challenge( - new AuthenticationProperties { RedirectUri = "/test2/" }, - OpenIdConnectAuthenticationDefaults.AuthenticationType); - } - } -``` - -## References - -- [Infinite redirects with ASP.NET OWIN and OpenID Connect](https://varnerin.info/infinite-redirects-with-aspnet-owin-and-openid-connect/) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/bundle-consent-application-registrations.md b/support/entra/entra-id/app-integration/bundle-consent-application-registrations.md deleted file mode 100644 index 23503288356..00000000000 --- a/support/entra/entra-id/app-integration/bundle-consent-application-registrations.md +++ /dev/null @@ -1,279 +0,0 @@ ---- -title: Enable Bundled Consent for Microsoft Entra ID Applications. -description: Describes how to bundle consent for Microsoft Entra ID applications. -ms.reviewer: willfid -ms.service: entra-id -ms.date: 05/27/2025 -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# Bundled consent for Microsoft Entra ID applications - -This article discusses how to configure bundled consent for Microsoft Entra ID applications. - -## Symptoms - -You have a custom client app and a custom API app, and you create app registrations for both apps in Microsoft Entra ID. You configure bundled consent for both apps. In this scenario, you might receive one of the following error messages when you try to sign in to either app: - -- AADSTS70000: The request was denied because one or more scopes requested are unauthorized or expired. The user must first sign in and grant the client application access to the requested scope. - -- AADSTS650052: The app is trying to access a service\”{app_id}\”(\”app_name\”) that your organization %\”{organization}\” lacks a service principal for. Contact your IT Admin to review the configuration of your service subscriptions or consent to the application in order to create the required service principal. - -## Solution - -### Step 1: Configure knownClientApplications for the API app registration - -Add the custom client app ID to the custom API app registration's `knownClientApplications` property. For more information, see [knownClientApplications attribute](/entra/identity-platform/reference-app-manifest#knownclientapplications-attribute). - -### Step 2: Configure API permissions - -Make sure that: - -- All required API permissions are correctly configured on both the custom client and custom API app registrations. -- The custom client app registration includes the API permissions that are defined in the custom API app registration. - -### Step 3: The sign-in request - -Your authentication request must use the `.default` scope for Microsoft Graph. For Microsoft accounts, the scope must be for the custom API. - -**Example Request for Microsoft accounts and work or school accounts** - -```HTTP -https://login.microsoftonline.com/common/oauth2/v2.0/authorize -?response_type=code -&Client_id=72333f42-5078-4212-abb2-e4f9521ec76a -&redirect_uri=https://localhost -&scope=openid profile offline_access app_uri_id1/.default -&prompt=consent -``` - -> [!NOTE] -> The client will seem to be lacking permission for the API. This condition is expected because the client is listed as `knownClientApplication`. - -**Example request for work or school accounts only** - -```http -GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize -?response_type=code -&client_id=72333f42-5078-4212-abb2-e4f9521ec76a -&redirect_uri=https://localhost -&scope=openid profile offline_access User.Read https://graph.microsoft.com/.default -&prompt=consent -``` - -#### Implementation by using MSAL.NET - -```csharp -String[] consentScope = { "api://ae5a0bbe-d6b3-4a20-867b-c8d9fd442160/.default" }; -var loginResult = await clientApp.AcquireTokenInteractive(consentScope) - .WithAccount(account) - .WithPrompt(Prompt.Consent) - .ExecuteAsync(); -``` - -Consent propagation for new service principals and permissions can take some time to finish. Your application should successfully handle this delay. - -#### Acquire tokens for multiple resources - -If your client app has to acquire tokens for another resource, such as Microsoft Graph, you must implement logic to handle potential delays after users consent to the application. Here are some recommendations: - -- Use the `.default` scope when you request tokens. -- Track acquired scopes until the required one is returned. -- Add a delay if the result still does not have the required scope. - -Currently, if `AcquireTokenSilent` fails, MSAL requires a successful interactive authentication before it allows another silent token acquisition. This restriction applies even if a valid refresh token is available. - -Here's some sample code that uses retry logic: - -```csharp - public static async Task GetTokenAfterConsentAsync(string[] resourceScopes) - { - AuthenticationResult result = null; - int retryCount = 0; - - int index = resourceScopes[0].LastIndexOf("/"); - - string resource = String.Empty; - - // Determine resource of scope - if (index < 0) - { - resource = "https://graph.microsoft.com"; - } - else - { - resource = resourceScopes[0].Substring(0, index); - } - - string[] defaultScope = { $"{resource}/.default" }; - - string[] acquiredScopes = { "" }; - string[] scopes = defaultScope; - - while (!acquiredScopes.Contains(resourceScopes[0]) && retryCount <= 15) - { - try - { - result = await clientApp.AcquireTokenSilent(scopes, CurrentAccount).WithForceRefresh(true).ExecuteAsync(); - acquiredScopes = result.Scopes.ToArray(); - if (acquiredScopes.Contains(resourceScopes[0])) continue; - } - catch (Exception e) - { } - - // Switch scopes to pass to MSAL on next loop. This tricks MSAL to force AcquireTokenSilent after failure. This also resolves intermittent cachine issue in ESTS - scopes = scopes == resourceScopes ? defaultScope : resourceScopes; - retryCount++; - - // Obvisouly something went wrong - if(retryCount==15) - { - throw new Exception(); - } - - // MSA tokens do not return scope in expected format when .default is used - int i = 0; - foreach(var acquiredScope in acquiredScopes) - { - if(acquiredScope.IndexOf('/')==0) acquiredScopes[i].Replace("/", $"{resource}/"); - i++; - } - - Thread.Sleep(2000); - } - - return result; - } -``` - -#### About the custom API that uses the On-behalf-of flow - -Similar to the client app, when your custom API tries to acquire tokens for another resource by using the On-Behalf-Of (OBO) flow, it might fail immediately after consent. To resolve this issue, you can implement retry logic and scope tracking, as in the following sample code: - -```csharp -while (result == null && retryCount >= 6) - { - UserAssertion assertion = new UserAssertion(accessToken); - try - { - result = await apiMsalClient.AcquireTokenOnBehalfOf(scopes, assertion).ExecuteAsync(); - - } - catch { } - - retryCount++; - - if (result == null) - { - Thread.Sleep(1000 * retryCount * 2); - } - } - -If (result==null) return new HttpStatusCodeResult(HttpStatusCode.Forbidden, "Need Consent"); -``` - -If all retries fail, return an error message, and then instruct the client to start a full consent process. - -**Example of client code that assumes your API throws a 403** - -```csharp -HttpResponseMessage apiResult = null; -apiResult = await MockApiCall(result.AccessToken); - -if(apiResult.StatusCode==HttpStatusCode.Forbidden) -{ - var authResult = await clientApp.AcquireTokenInteractive(apiDefaultScope) - .WithAccount(account) - .WithPrompt(Prompt.Consent) - .ExecuteAsync(); - CurrentAccount = authResult.Account; - - // Retry API call - apiResult = await MockApiCall(result.AccessToken); -} -``` - -## Recommendations and expected behavior - -Ideally, you would create a separate flow that takes the following actions: -- Guides users through the consent process -- Provisions your app and API in their tenant or Microsoft account -- Completes consent in a single step that's separate from signing in - -If you don't separate this flow, and instead combine it with your app's sign-in experience, the process can become confusing. Users might encounter multiple consent prompts. To improve the experience, consider adding a message in your app to inform users that they might be asked to consent more than one time： - -- For Microsoft accounts, expect at least two consent prompts: one for the client app and one for the API. -- Typically, for work or school accounts, only one consent prompt is required. - -The following is an end-to-end code sample that demonstrates a smooth user experience. This code supports all account types and prompts for consent only when necessary. - -```csharp -string[] msGraphScopes = { "User.Read", "Mail.Send", "Calendar.Read" } -String[] apiScopes = { "api://ae5a0bbe-d6b3-4a20-867b-c8d9fd442160/access_as_user" }; -String[] msGraphDefaultScope = { "https://graph.microsoft.com/.default" }; -String[] apiDefaultScope = { "api://ae5a0bbe-d6b3-4a20-867b-c8d9fd442160/.default" }; - -var accounts = await clientApp.GetAccountsAsync(); -IAccount account = accounts.FirstOrDefault(); - -AuthenticationResult msGraphTokenResult = null; -AuthenticationResult apiTokenResult = null; - -try -{ - msGraphTokenResult = await clientApp.AcquireTokenSilent(msGraphScopes, account).ExecuteAsync(); - apiTokenResult = await clientApp.AcquireTokenSilent(apiScopes, account).ExecuteAsync(); -} -catch (Exception e1) -{ - - string catch1Message = e1.Message; - string catch2Message = String.Empty; - - try - { - // First possible consent experience - var result = await clientApp.AcquireTokenInteractive(apiScopes) - .WithExtraScopesToConsent(msGraphScopes) - .WithAccount(account) - .ExecuteAsync(); - CurrentAccount = result.Account; - msGraphTokenResult = await clientApp.AcquireTokenSilent(msGraphScopes, CurrentAccount).ExecuteAsync(); - apiTokenResult = await clientApp.AcquireTokenSilent(apiScopes, CurrentAccount).ExecuteAsync(); - } - catch(Exception e2) - { - catch2Message = e2.Message; - }; - - if(catch1Message.Contains("AADSTS650052") || catch2Message.Contains("AADSTS650052") || catch1Message.Contains("AADSTS70000") || catch2Message.Contains("AADSTS70000")) - { - // Second possible consent experience - var result = await clientApp.AcquireTokenInteractive(apiDefaultScope) - .WithAccount(account) - .WithPrompt(Prompt.Consent) - .ExecuteAsync(); - CurrentAccount = result.Account; - msGraphTokenResult = await GetTokenAfterConsentAsync(msGraphScopes); - apiTokenResult = await GetTokenAfterConsentAsync(apiScopes); - } -} - -// Call API - -apiResult = await MockApiCall(apiTokenResult.AccessToken); -var contentMessage = await apiResult.Content.ReadAsStringAsync(); - -if(apiResult.StatusCode==HttpStatusCode.Forbidden) -{ - var result = await clientApp.AcquireTokenInteractive(apiDefaultScope) - .WithAccount(account) - .WithPrompt(Prompt.Consent) - .ExecuteAsync(); - CurrentAccount = result.Account; - - // Retry API call - apiResult = await MockApiCall(result.AccessToken); -} -``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-entra-id-app.md b/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-entra-id-app.md deleted file mode 100644 index b97b9383859..00000000000 --- a/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-entra-id-app.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Use Fiddler to Collect HTTPS Traffic from Microsoft Entra ID Apps -description: Provides instructions to use Fiddler to collect HTTPS traffic from Microsoft Entra ID apps -ms.date: 03/20/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Enterprise Applications ---- -# Collect HTTPS traffic using Fiddler for Microsoft Entra ID apps - -This article provides instructions to use Fiddler to collect HTTPS traffic to troubleshoot Microsoft Entra ID apps. - -## Collect HTTPS traffic - -1. Download and install [Fiddler](https://www.telerik.com/fiddler/fiddler-classic) on the device that's used to reproduce the problem. - - > [!NOTE] - > Fiddler is third-party software, not owned by Microsoft. -1. On the **Tool** menu, select **Options**. -1. On the **HTTPS** tab, select **Decrypt HTTPS Traffic**. If you're prompted to install the Fiddler certificate, select **Yes**. - - :::image type="content" source="media/capture-https-traffic-http-fiddler-entra-id-app/enable-https-decrypt.png" alt-text="Screenshot of the Decrypt HTTPS Traffic option." ::: -1. Restart Fiddler. -1. Prepare your environment for traffic collection. Depending on the type of application you're troubleshooting, follow these steps: - - **For browser-based applications**: - - Use private browsing mode or clear the browser cache on the device that you'll use for testing. This action makes sure that any outdated or unnecessary files from previous sessions are cleared. It also lets the web app load the latest versions of essential files, such as JavaScript and CSS stylesheets. Having the latest files is especially important when you test changes or updates to the web app because it prevents old cached files from interfering with the current version. - - **For non-browser-based applications**: - - Start the client application that you're testing. - -1. Reproduce the issue. You should see HTTPS traffic appearing in the Fiddler window. -1. On the **File** menu, select **Save** > **All Sessions** to save the sessions as SAZ files. - -[!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-python-app.md b/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-python-app.md deleted file mode 100644 index 1ae5acd585b..00000000000 --- a/support/entra/entra-id/app-integration/capture-https-traffic-fiddler-python-app.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Collect HTTPS Traffic using Fiddler from Python app with Microsoft Entra ID -description: Provide instructions to collect HTTPS traffic by using Fiddler from Microsoft Entra ID apps -ms.date: 03/20/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Enterprise Applications ---- -# Collect HTTPS traffic by using Fiddler from Python apps - -Capturing encrypted HTTPS web traffic in Python by using Fiddler can be challenging because Python uses its own trusted certificate store instead of the operating system certificate store. Additionally, by default, Python doesn't use a proxy in certain scenarios. This article explains how to capture SSL traffic by using the Fiddler for Python app in different scenarios. - -## ADAL for Python - -When you use Fiddler to capture HTTPS traffic in a Python app that integrates Azure Active Directory Authentication Library (ADAL), you might receive SSL error messages. This issue occurs because Python doesn't trust the Fiddler certificate. You can use either of two methods to work around this issue. - -> [!Note] -> Disabling SSL verification presents a security risk. You should use this method only to troubleshoot. You should not use it in production environments. - -- Set an environment variable at the beginning of your Python app before the `AuthenticationContext` object is initialized: - - ```python - import os - ... - os.environ["ADAL_PYTHON_SSL_NO_VERIFY"] = "1" - ``` -- Pass the `verify_ssl=False` flag to the AuthenticationContext method: - - ```python - context = adal.AuthenticationContext(authority, verify_ssl=False) - ``` - -## MSAL for Python -When you use the Microsoft Authentication Library (MSAL) for Python, you can disable SSL verification as follows: - -```python -app = msal.PublicClientApplication( client_id=appId, authority="https://login.microsoftonline.com/" + tenantId, verify=False ) -``` -## Python Requests module - -By default, the Requests module doesn't use a proxy. You must force the request to go through the Fiddler proxy, per the following example: - -```python -import requests - -… -access_token = token.get('accessToken') -endpoint = "api_endpoint" -headers = {"Authorization": "Bearer " + access_token} -json_output = requests.get( - endpoint, - headers=headers, - proxies={"http": "http://127.0.0.1:8888", "https": "http://127.0.0.1:8888"}, - verify=False -).json() -``` -## Azure Active Directory SDK for Python (GraphRbacManagementClient) - -The following example shows how to disable SSL verification: - -```python -from azure.graphrbac import GraphRbacManagementClient -from azure.common.credentials import UserPassCredentials - -credentials = UserPassCredentials( - , # Your user name - , # Your password - resource=”https://graph.windows.net”, - verify=False -) -tenant_id = -graphrbac_client = GraphRbacManagementClient(credentials, tenant_id) -graphrbac_client.config.connection.verify=False -res = graphrbac_client.users.get() -print(res.display_name) -``` - -[!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/confidential-client-application-authentication-error-aadsts7000218.md b/support/entra/entra-id/app-integration/confidential-client-application-authentication-error-aadsts7000218.md deleted file mode 100644 index e24b84673dc..00000000000 --- a/support/entra/entra-id/app-integration/confidential-client-application-authentication-error-aadsts7000218.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Invalid Client Error AADSTS7000218 When Authenticating to Microsoft Entra ID -description: Provides a solution to the AADSTS7000218 error when a confidential client application authenticates to Microsoft Entra ID. -ms.date: 04/30/2025 -ms.reviewer: bachoang, v-weizhu -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- - -# Error AADSTS7000218 when a confidential client application authenticates to Microsoft Entra ID - -This article provides a solution to the AADSTS7000218 error that occurs when a confidential client application authenticates to Microsoft Entra ID. - -## Symptoms - -When a confidential client application authenticates to Microsoft Entra ID to get an access token, the following error message is displayed: - -```output -{ - "error": "invalid_client", - "error_description": "AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.\r\nTrace ID: xxx\r\nCorrelation ID: xxx\r\nTimestamp: 2019-08-18 20:38:28Z", - "error_codes": [7000218], - ... -} -``` - -## Cause - -This issue occurs because the application doesn't provide the credentials (client secret or assertion) that the token endpoint expects. A confidential client must provide its credentials when authenticating to Microsoft Entra ID. - -## Resolution - -To resolve this issue, include the client secret or assertion in the token request. - -In some authentication flow scenarios, such as the [OAuth 2 Resource Owner Password Credentials (ROPC)](/entra/identity-platform/v2-oauth-ropc) grant flow or [OAuth 2 device authorization grant flow](/entra/identity-platform/v2-oauth2-device-code), where you don't expect the client application to be confidential, allow public client flows in the **App registrations**: - -1. In the [Azure portal](https://portal.azure.com/), in **App registrations**, select your application, and then select **Authentication**. -2. Select **Advanced settings** > **Allow public client flows**. -3. For **Enable the following mobile and desktop flows**, select **Yes**. - - :::image type="content" source="media/confidential-client-application-authentication-error-aadsts7000218/allow-public-client-flows.png" alt-text="Screenshot that shows the 'Enable the following mobile and desktop flows' option." lightbox="media/confidential-client-application-authentication-error-aadsts7000218/allow-public-client-flows.png"::: - -Changing the default client type from confidential to public causes security implications. For more information, see [What's the security implication of changing the default client type from confidential to public in Azure AD?](https://blogs.aaddevsup.xyz/2020/09/whats-the-security-implication-of-changing-the-default-client-type-from-confidential-to-public-in-azure-ad/) - -## Understand client types in Microsoft Entra ID - -As defined in the [OAuth 2.0 specification](https://tools.ietf.org/html/rfc6749), client applications are categorized into two types: - -- Confidential client: A client that can securely store a secret used to authenticate to Microsoft Entra ID. - - For example, the client is a web application whose code and secrets are stored on a server that isn't exposed to the public. Only an admin can access the application's confidential information. -- Public client: A client that can't store any secret. - - For example, a public client is a mobile or desktop application running in an insecure or unmanaged environment. - -In the Microsoft Entra App Registration model, a registered application can be both a public client and a confidential client, depending on the context in which the application is used. This is because an application might have a part used as a public client, while other parts are designed to be used as a confidential client. Depending on workflows, the application developer must decide if the application should act as a public or confidential client. A confidential client is expected in certain OAuth2 grant flows, such as the Client Credentials flow, Authorization Code flow, or On-Behalf-Of flow. It uses a flow to request a token. - -## How Microsoft Entra ID determines the client type - -- Method 1: Use the type of the redirect URI (reply URL) - - Microsoft Entra ID checks the redirect URI (reply URL) provided in the request and cross-checks it with the redirect URI registered in the App Registrations. - - A redirect URI of type **Web** classifies the application as a confidential client. - - :::image type="content" source="media/confidential-client-application-authentication-error-aadsts7000218/web-client-type.png" alt-text="Screenshot that shows a Web-type redirect URI." lightbox="media/confidential-client-application-authentication-error-aadsts7000218/web-client-type.png"::: - - A redirect URI of type **Mobile and desktop applications** classifies the application as a public client. - - :::image type="content" source="media/confidential-client-application-authentication-error-aadsts7000218/public-client-type.png" alt-text="Screenshot that shows a public-type redirect URI." lightbox="media/confidential-client-application-authentication-error-aadsts7000218/public-client-type.png"::: - -- Method 2: Use the **Enable the following mobile and desktop flows** option (when no reply URL is provided) - - In some OAuth 2.0 flows, such as the [OAuth 2 Resource Owner Password Credentials (ROPC)](/azure/active-directory/develop/v2-oauth-ropc) grant flow, [OAuth 2 device authorization grant flow](/entra/identity-platform/v2-oauth2-device-code) and Integrated Windows Authentication, no reply URL is provided in the token request. In these cases, Microsoft Entra ID uses the app registration's **Enable the following mobile and desktop flows** to determine whether the client is confidential or public. - - - If **Enable the following mobile and desktop flows** is set to **Yes**, the client is public. - - If it's set to **No**, the client is confidential. - -### How to identify the grant type and redirect URI used by an application - -Review the application code or capture a [Fiddler](https://blogs.aaddevsup.xyz/2018/09/capture-https-traffic-with-http-fiddler/) trace to inspect the `grant_type` and `redirect_uri` parameters sent in the POST request to the Microsoft Entra ID's token endpoint: - -- V1 endpoint: `https://login.microsoftonline.com//oauth2/token` -- V2 endpoint: `https://login.microsoftonline.com//oauth2/v2.0/token` - -Here's an example of a Fiddler trace: - -:::image type="content" source="media/confidential-client-application-authentication-error-aadsts7000218/post-request.png" alt-text="Screenshot that shows a POST request in Fiddler."::: - -:::image type="content" source="media/confidential-client-application-authentication-error-aadsts7000218/grant-type.png" alt-text="Screenshot that shows a grant type."::: - -Common OAuth 2.0 flows and their associated `grant_type` values are listed as follows: - -| OAuth 2.0 flow | grant_type value | -| --- | --- | -| [ROPC](/entra/identity-platform/v2-oauth-ropc) | `password` | -| [Device Code](/entra/identity-platform/v2-oauth2-device-code) | `urn:ietf:params:oauth:grant-type:device_code` | -| [Authorization Code](/entra/identity-platform/v2-oauth2-auth-code-flow) | `authorization_code` | -| [Client Credentials](/entra/identity-platform/v2-oauth2-client-creds-grant-flow) | `client_credentials` | -| [On-Behalf-Of](/entra/identity-platform/v2-oauth2-on-behalf-of-flow) | `urn:ietf:params:oauth:grant-type:jwt-bearer` | -| [SAML Bearer Assertion](/entra/identity-platform/v2-saml-bearer-assertion) | `urn:ietf:params:oauth:grant-type:saml1_1-bearer` | - -## References - -[Microsoft Authentication Library (MSAL) Client Applications](https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Client-Applications) - -[!INCLUDE [Third-party information disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/customize-authentication-session-expiration.md b/support/entra/entra-id/app-integration/customize-authentication-session-expiration.md deleted file mode 100644 index 186dc125076..00000000000 --- a/support/entra/entra-id/app-integration/customize-authentication-session-expiration.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -title: Configure ASP.NET or ASP.NET Core App Session to Last Longer Than Entra ID Tokens -description: Discusses how to configure ASP.NET or ASP.NET Core App session to last longer than Microsoft Entra ID token. -ms.date: 05/31/2025 -ms.reviewer: willfid -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# Customize middleware authentication ticket to extend user sign-in duration - -By default, Microsoft Entra ID tokens (ID tokens, access tokens, and SAML tokens) expire after one hour. Also by default, ASP.NET and ASP.NET Core middleware set their authentication tickets to the expiration of these tokens. If you don't want your web application to redirect users to Microsoft Entra ID to have them sign in again, you can customize the middleware authentication ticket. - -This customization can also help resolve AJAX-related issues, such as coss-origin resource sharing (CORS) errors to login.microsoftonline.com. These issues often occur when your app functions as both a web application and a web API. -## For ASP.NET - -In the `ConfigureAuth` method of the `Startup.Auth.cs` file, update the `app.UseCookieAuthentication()` method to: - -```csharp -app.UseCookieAuthentication(new CookieAuthenticationOptions() -{ - CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager(), - Provider = new CookieAuthenticationProvider() - { - OnResponseSignIn = (context) => - { - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - } - } -}); -``` - -Then, decouple the token lifetime from the web app: - -```csharp -app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - UseTokenLifetime = false, - ... -``` - -## For ASP.NET Core - -In ASP.NET Core, you have to add the `OnTokenValidated` event to update the ticket properties. This addition sets the ticket expiration time to occur before the application redirects to Microsoft Entra ID for reauthentication. - -```csharp -services.Configure(AzureADDefaults.OpenIdScheme, options => -{ - // decouple the token lifetime from the Web App - options.UseTokenLifetime = false; - - // other configurations... - // ... - - var onTokenValidated = options.Events.OnTokenValidated; - options.Events ??= new OpenIdConnectEvents(); - options.Events.OnTokenValidated = async context => - { - await onTokenValidated(context); - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - }; -}); -``` - -### Examples - -Here are a few examples of how to do make this setting: - -If you're using code similar to the following example to add Microsoft Entra ID authentication: - -```csharp -services.AddAuthentication(AzureADDefaults.AuthenticationScheme) - .AddAzureAD(options => Configuration.Bind("AzureAd", options)) -``` - -Then add the following code: - -```csharp -services.Configure(AzureADDefaults.OpenIdScheme, options => -{ - // decouple the id_token lifetime from the Web App - options.UseTokenLifetime = false; - - //… - - var onTokenValidated = options.Events.OnTokenValidated; - options.Events ??= new OpenIdConnectEvents(); - options.Events.OnTokenValidated = async context => - { - await onTokenValidated(context); - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - }; -}); -``` - -Your configuration in Startup.cs should resemble the following example: - -```csharp -public void ConfigureServices(IServiceCollection services) -{ - //... - - services.AddAuthentication(AzureADDefaults.AuthenticationScheme) - .AddAzureAD(options => Configuration.Bind("AzureAd", options)) - .AddCookie(); - - //... - - services.Configure(AzureADDefaults.OpenIdScheme, options => - { - // decouple the token lifetime from the Web App - options.UseTokenLifetime = false; - - //... - var onTokenValidated = options.Events.OnTokenValidated; - options.Events ??= new OpenIdConnectEvents(); - options.Events.OnTokenValidated = async context => - { - await onTokenValidated(context); - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - }; - }); - - //... -} -``` - -If you're using `Microsoft.Identity.Web` to add your Microsoft Entra ID configuration: - -```csharp -//… -using Microsoft.Identity.Web; -//… -public class Startup -{ - // ... - public void ConfigureServices(IServiceCollection services) - { - // ... - services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) - .AddMicrosoftIdentityWebApp(options => - { - Configuration.Bind("AzureAD", options); - - // decouple the token lifetime from the Web App - options.UseTokenLifetime = false; - - var onTokenValidated = options.Events.OnTokenValidated; - options.Events ??= new OpenIdConnectEvents(); - - options.Events.OnTokenValidated = async context => - { - await onTokenValidated(context); - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - }; - }); - // ... -} -``` - -If you're implementing your own custom `OpenIdConnectOptions` to configure Microsoft Entra ID authentication: - -```csharp -services.Configure(options => -{ - //… - options.Events.OnTokenValidated = async context => - { - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - }; -}); -``` - -If you're integrating an ASP.NET Core WS-Fed application: - -```csharp -public void ConfigureServices(IServiceCollection services) -{ - services.AddAuthentication(WsFederationDefaults.AuthenticationScheme) - .AddCookie() - .AddWsFederation(options => - { - options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme; - - // decouple the token lifetime from the Web App - options.UseTokenLifetime = false; - - // MetadataAddress for your Azure Active Directory instance. - options.MetadataAddress = "https://login.microsoftonline.com/common/federationmetadata/2007-06/federationmetadata.xml"; - - // Wtrealm is the app's identifier in the Active Directory instance. - // For ADFS, use the relying party's identifier, its WS-Federation Passive protocol URL: - options.Wtrealm = "https://localhost:44307/"; - - // For AAD, use the Application ID URI from the app registration's Overview blade: - options.Wtrealm = "https://contoso.onmicrosoft.com/wsfedapp"; - - // Set the Authentication Ticket to expire at a custom time - var onTokenValidated = options.Events.OnTokenValidated; - options.Events ??= new OpenIdConnectEvents(); - - options.Events.OnSecurityTokenValidated = async context => - { - context.Properties.ExpiresUtc = DateTimeOffset.UtcNow.AddHours(12); - } -``` -## More information - -These settings control the expiration of the authentication ticket that determines how long a user stays signed in. You can configure this expiration to suit your requirement. - -> [!NOTE] -> If you modify the ticket expiration, users might still have access to your application even if they're deleted or disabled in Microsoft Entra ID. This condition remains true until the ticket expires. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/enable-msal4j-logging-spring-boot-webapp.md b/support/entra/entra-id/app-integration/enable-msal4j-logging-spring-boot-webapp.md deleted file mode 100644 index 1280485ecd0..00000000000 --- a/support/entra/entra-id/app-integration/enable-msal4j-logging-spring-boot-webapp.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Enable MSAL4J Logging in a Spring Boot Web Application in Microsoft Entra ID -description: Discusses how to enable MSAL4J logging in a Spring Boot web application in Microsoft Entra. -ms.date: 03/10/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Microsoft Entra App Integration and Development ---- - -# Enable MSAL4J logging in a Spring Boot web application - -This article provides step-by-step instructions to enable [Microsoft Authentication Library for Java](https://github.com/AzureAD/microsoft-authentication-library-for-java) (MSAL4J) logging by using the [Logback framework](https://logback.qos.ch/) in a Spring Boot web application. - -## Code sample - -The complete code sample and configuration guide for this implementation are available on [GitHub](https://github.com/bachoang/MSAL4J_SpringBoot_Logging/tree/main/msal-b2c-web-sample). - -## Enable MSAL4J logging - -1. Add the following dependency to your Pom.xml file to include the Logback framework: - - ```xml - - ch.qos.logback - logback-classic - 1.2.3 - - ``` - -2. In your app project, create a file in the **src/main/resources** folder, and name the file **Logback.xml**. Then, add the following content: - - ```xml - - - - - %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n - - - - - - - ``` - - This Appender configuration logs messages to the console. You can adjust the logging level to `error`, `warn`, `info`, or `verbose` based on your preference. For more information, see [LogBack: Appenders](https://logback.qos.ch/manual/appenders.html). -3. Set the **logging.config** property to the location of the **Logback.xml** file before the main method: - - ```java - @SpringBootApplication - public class MsalB2CWebSampleApplication { - - static { System.setProperty("logging.config", "C:\\Users\\\\src\\main\\resources\\logback.xml");} - public static void main(String[] args) { - // Console.log("main"); - // System.console().printf("hello"); - // System.out.printf("Hello %s!%n", "World"); - System.out.printf("%s%n", "Hello World"); - SpringApplication.run(MsalB2CWebSampleApplication.class, args); - } - } - ``` - -## Configuration for running the code sample - -### Enable HTTPs support - -This code sample is set up to run on the local server (localhost) by using the HTTPS protocol. Follow the steps in [Configure the sample to use your Azure AD B2C tenant](https://github.com/bachoang/MSAL4J_SpringBoot_Logging/tree/main/msal-b2c-web-sample#step-2--configure-the-sample-to-use-your-azure-ad-b2c-tenant) to generate a self-signed certificate. Put the **keystore.p12** file in the resources folder. - -### App registration configuration - -To configure app registration in Azure AD B2C, follow these steps: - -1. Create two app registrations in your Azure AD B2C tenant: One for the web application and the other for the web API. -2. Expose the required scope in the web API. For more information, see [Configure web API app scopes](/azure/active-directory-b2c/configure-authentication-sample-web-app-with-api?tabs=visual-studio#step-22-configure-web-api-app-scopes). -3. Configure the web API scope in the **API Permissions** blade for the web application. -4. Grant admin consent to all configured permissions in the web application. - -For more information, see [Configure authentication in a sample web app that calls a web API by using Azure AD B2C](/azure/active-directory-b2c/configure-authentication-sample-web-app-with-api). - -Example configuration: - - :::image type="content" source="media/enable-msal4j-logging-spring-boot-webapp/app-reg.png" alt-text="Diagram that shows configured app registration." border="true" lightbox="media/enable-msal4j-logging-spring-boot-webapp/app-reg.png"::: - -## Logging output example - -If the app is configured correctly, the logging output should resemble the following output. - - :::image type="content" source="media/enable-msal4j-logging-spring-boot-webapp/log-sample.png" alt-text="Diagram that shows logging output." border="true" lightbox="media/enable-msal4j-logging-spring-boot-webapp/log-sample.png"::: - -[!INCLUDE [third-party-disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] - - diff --git a/support/entra/entra-id/app-integration/error-aadsts50107-guest-redemption-fails.md b/support/entra/entra-id/app-integration/error-aadsts50107-guest-redemption-fails.md deleted file mode 100644 index 43d0bcb4443..00000000000 --- a/support/entra/entra-id/app-integration/error-aadsts50107-guest-redemption-fails.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Guest Invitation Redemption Fails with Error AADSTS50107 -description: Provides a solution to the error AADSTS50107 that occurs when a guest user tries to redeem an invitation via a SAML external trust. -ms.reviewer: laks, joaos, lyzh, v-weizhu -ms.service: entra-id -ms.date: 05/21/2025 -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50107 when a guest user redeems an invitation via SAML external trust - -This article provides a solution to the Microsoft Entra authentication error AADSTS50107. This error occurs when a guest user attempts to redeem an invitation from a tenant that uses a Security Assertion Markup Language (SAML) external trust. - -## Symptoms - -Consider the following scenario: - -- Your tenant has a direct federation trust with an external organization that uses a SAML or WS-Fed identity provider (IdP). -- The external organization invites a user to your tenant as a guest. -- The guest user attempts to redeem the invitation. - -In this scenario, the invitation redemption fails with the following error message: - -> Error: AADSTS50107: The requested federation realm object 'https://abc.contoso.com' does not exist. - -## Cause - -This issue occurs when the issuer URL value in the SAML response doesn't match the one configured in Microsoft Entra ID. The issuer URL in the SAML response corresponds to the URL mentioned in the error message. - -## Resolution - -To resolve this issue, follow these steps: - -1. Ensure that the issuer URL in the external IdP matches the one configured in Microsoft Entra ID. -1. Verify or update the issuer URL in Microsoft Entra ID to align with the one in the SAML response. - - To verify the issuer URL in Microsoft Entra ID, follow these steps: - - 1. Sign in to the Microsoft Entra admin center as an administrator. - 1. Select **Manage** > **External Identities**. - 1. Select **View all identity providers**. - 1. Under the **Custom** tab, select the desired SAML trust (such as `Contoso.com`). - 1. Select **Edit Configuration** for the desired SAML trust. - 1. Check if the issuer URL configured in Microsoft Entra ID matches the `saml:Issuer` value in the SAML response sent by the external IdP. - -For more information, see [Add federation with SAML/WS-Fed identity providers](/entra/external-id/direct-federation). - -## More information - -For a full list of Microsoft Entra authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-aadsts900439-usgclientnotsupportedonpublicendpoint.md b/support/entra/entra-id/app-integration/error-aadsts900439-usgclientnotsupportedonpublicendpoint.md deleted file mode 100644 index fdb33e8f02a..00000000000 --- a/support/entra/entra-id/app-integration/error-aadsts900439-usgclientnotsupportedonpublicendpoint.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Error AADSTS900439 - USGClientNotSupportedOnPublicEndpoint -description: Describes a problem in which you receive the error AADSTS900439 when signing in to an application registered in the Azure Government cloud using a public endpoint. -ms.date: 03/31/2025 -ms.reviewer: bernawy, v-weizhu -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS900439 - USGClientNotSupportedOnPublicEndpoint - -This article provides a solution to the error AADSTS900439 (USGClientNotSupportedOnPublicEndpoint) that occurs when you try to sign in to an application registered in the Azure Government cloud using a public cloud endpoint. - -## Symptoms - -When trying to sign in to an application registered in the Azure Government cloud using a public endpoint, the sign-in fails, and you receive the AADSTS900439 (USGClientNotSupportedOnPublicEndpoint) error. - -## Cause - -Microsoft Entra authority for Azure Government has been updated from `https://login-us.microsoftonline.com` to `https://login.microsoftonline.us`. This change also applies to Microsoft 365 GCC High and Microsoft 365 DoD environments, which Microsoft Entra authority for Azure Government also services. Microsoft Entra ID enforces the correct endpoint for sign-in operations. You can no longer sign in to an application registered in the Azure Government cloud using the public endpoint `https://login-us.microsoftonline.com`. - -For more information, see [Microsoft Entra Authority for Azure Government Endpoint Update](https://devblogs.microsoft.com/azuregov/azure-government-aad-authority-endpoint-update). - -## Solution - -To resolve this issue, ensure you use the correct Azure Government endpoint for sign-in operations. Here are the mappings between Azure services and Azure Government endpoints: - -| Name | Azure Government endpoint | -| --- | --- | -| Portal | `https://portal.azure.us` | -| Microsoft Graph API | `https://graph.microsoft.us` | -| Active Directory Endpoint and Authority | `https://login.microsoftonline.us` | - -For more information, see [Azure Government endpoint mappings](/azure/azure-government/documentation-government-developer-guide#endpoint-mapping). - -## More information - -Each national cloud environment differs from the global Microsoft environment. When you develop applications for these environments, it's important to understand the key differences. For example, registering applications, acquiring tokens, and calling the Microsoft Graph API can be different. - -For more information about registering applications in a national cloud, see [App registration endpoints](/entra/identity-platform/authentication-national-cloud#app-registration-endpoints). - -For more information about acquiring tokens in a national cloud, see [Microsoft Entra authentication endpoints](/entra/identity-platform/authentication-national-cloud#azure-ad-authentication-endpoints). - -For more information about the different Microsoft Graph national cloud deployments and the capabilities that are available to developers within each cloud, see [Microsoft Graph national cloud deployments](/graph/deployments). Here's a sample implementation: [Configure a .NET application to call Microsoft Graph in a national cloud tenant](https://blogs.aaddevsup.xyz/2020/06/configure-net-application-to-call-microsoft-graph-in-a-national-cloud-tenant). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS50003-cert-or-key-not-configured.md b/support/entra/entra-id/app-integration/error-code-AADSTS50003-cert-or-key-not-configured.md deleted file mode 100644 index 2b26d1f635c..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS50003-cert-or-key-not-configured.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Error AADSTS50003 - No signing key configured -description: Describes a problem in which you receive the error AADSTS50003 when signing in to SAML SSO configured app with Microsoft Entra ID. -ms.date: 10/12/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50003 - No signing key configured - -This article describes a problem in which you receive the error message "Error AADSTS50003 - No signing key configured." when trying to sign into a SAML-based single sign-on (SSO) configured app that has been integrated with Microsoft Entra ID. - -## Symptoms - -You receive error `AADSTS50003` when trying to sign into an application that has been setup to use Microsoft Entra ID for identity management using SAML-based SSO. - -## Cause - -The application object is corrupted and Microsoft Entra ID doesn't recognize the certificate configured for the application. - -## Resolution - -To delete and create a new certificate, follow the steps below: - -1. On the SAML-based SSO configuration screen, select **Create new certificate** under the **SAML signing Certificate** section. -1. Select Expiration date and then click **Save**. -1. Check **Make new certificate active** to override the active certificate. Then, click **Save** at the top of the pane and accept to activate the rollover certificate. -1. Under the **SAML Signing Certificate** section, click **remove** to remove the **Unused** certificate. - -## More Information - -For a full list of Active Directory Authentication and authorization error codes see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS50011-redirect-uri-mismatch.md b/support/entra/entra-id/app-integration/error-code-AADSTS50011-redirect-uri-mismatch.md deleted file mode 100644 index e535e0c5a76..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS50011-redirect-uri-mismatch.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Error AADSTS50011 the redirect URI does not match the redirect URIs configured for the application -description: Describes error AADSTS50011 that occurs when you sign in to an OIDC-based SSO application in Microsoft Entra ID. -author: aricrowe57 -ms.date: 02/28/2024 -ms.reviewer: arcrowe -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50011 with OpenID authentication: The redirect URI specified in the request does not match - -This article describes a problem in which an `AADSTS50011` error message is returned when you try to sign in to an application that uses OpenID Connect (OIDC)-based authentication with Microsoft Entra ID. - -## Symptoms - -You receive the following error message when you try to sign in to an application that uses OIDC or OAuth2 authentication protocols with Microsoft Entra ID: - ->Error AADSTS50011 - The redirect URI \ specified in the request does not match the redirect URIs configured for the application \. Make sure the redirect URI sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/redirectUriMismatchError to learn more about how to fix this. - -## Cause - -This error occurs if the redirect URI (reply URL) configured in the application (code) and the Microsoft Entra app registration don't match. - -When a user accesses the application for authentication, the application redirects the user to Microsoft Entra ID with a predefined redirect URI. Once the user is authorized successfully, Microsoft Entra ID verifies the following values: - -- The redirect URI sent from the application -- The redirect URI values in the registered application in Microsoft Entra ID - -If the redirect URI the application sent doesn't match any of the redirect URIs in Microsoft Entra ID, error AADSTS50011 will be returned. If the values match, Microsoft Entra ID sends the user to the redirect URI. - -## Resolution - -To fix the issue, follow these steps to add a redirect URI in Microsoft Entra app registration. - -1. Copy the application ID from the error message. This is the ID of your application that has been registered in Microsoft Entra ID. - ![The screenshot about the application ID in AADSTS50011 error message](media\error-code-AADSTS50011-redirect-uri-mismatch\aadsts50011-error-appid.png) - -1. Go to the [Azure portal](https://portal.azure.com). Make sure you sign in to the portal by using an account that has permissions to update Microsoft Entra Application registration. -1. Navigate to **Microsoft Entra ID**, select **App registrations**, locate the application registration by using the application ID, and then open the app registration page. - - You can also open the page directly by using the following links: - - - If this app is owned by an organization (Microsoft Entra tenant), use `https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/Authentication/appId/`. - - If this app is owned by your personal Microsoft (MSA) account, use `https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationMenuBlade/Authentication/appId//isMSAApp/true`. - -1. On the app registration page, select **Authentication**. In the **Platform configurations** section, select **Add URI** to add the redirect URI displayed in the error message to Microsoft Entra ID. - - ![The screenshot about redirect URI in the AADSTS50011 error message](media\error-code-AADSTS50011-redirect-uri-mismatch\aadsts50011-error-redirecturi.png) - -1. Save the changes and wait three to five minutes for the changes to take effect, and then send the login request again. You should now be able to sign in to the application. If you don't see the Microsoft Entra login page, try clearing the password cache from your browser or use InPrivate browsing. - ->[!Note] ->If the redirect URI sent from the application isn't the desired one, you should update your application code or configuration. - -The following video shows how to fix the redirect URI mismatch error in Microsoft Entra ID: - -> [!VIDEO https://www.youtube.com/embed/a_abaB7494s] - -## More information - -For a complete list of Active Directory authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS50011-reply-url-mismatch.md b/support/entra/entra-id/app-integration/error-code-AADSTS50011-reply-url-mismatch.md deleted file mode 100644 index daac6a184b8..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS50011-reply-url-mismatch.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: Error AADSTS50011 - The reply URL specified in the request does not match the reply URLs configured for the application . -description: Describes a problem in which you receive reply URL does not match error when signing in to SAML-based Single Sign-On configured app. -ms.date: 06/08/2023 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50011 with SAML authentication - The reply URL specified in the request does not match - -This article provides a resolution to the AADSTS50011 error that occurs during federated authentication with Microsoft Entra ID. - -## Symptoms - -You receive error `AADSTS50011` when trying to sign into an application that has been set up to use Microsoft Entra ID for identity management using SAML-based SSO. - ->Error AADSTS50011 - The reply URL does not match the reply URLs configured for the application \. Make sure the reply URL sent in the request matches one added to your application in the Azure portal. Navigate to https://aka.ms/urlMismatchError to learn more about how to fix this." when trying to sign into a SAML-based Single Sign-On (SSO) configured app that has been integrated with Microsoft Entra ID. - -## Cause - -The `AssertionConsumerServiceURL` value in the SAML request doesn't match the Reply URL value or pattern configured in Microsoft Entra ID. The `AssertionConsumerServiceURL` value in the SAML request is the URL you see in the error. - -## Resolution - -To fix the issue, follow these steps: - -1. Ensure that the `AssertionConsumerServiceURL` value in the SAML request matches the Reply URL value configured in Microsoft Entra ID. -2. Verify or update the value in the Reply URL textbox to match the `AssertionConsumerServiceURL` value in the SAML request. - -As an example, refer to the following article for detailed steps about how to configure the values in Microsoft Entra ID: - -- [Tutorial: Microsoft Entra SSO integration with Salesforce](/azure/active-directory/saas-apps/salesforce-tutorial) - ->[!Note] ->The reply URL is also known as Redirect URI. These values depend on what application is being used. You should get the values from the application vendor. - -After you update the Reply URL value in Microsoft Entra ID and it matches the value that sent by the application in the SAML request, you should be able to sign in to the application. - -## More Information - -For a full list of Active Directory Authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS50020-user-account-identity-provider-does-not-exist.md b/support/entra/entra-id/app-integration/error-code-AADSTS50020-user-account-identity-provider-does-not-exist.md deleted file mode 100644 index 50b7ba797e8..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS50020-user-account-identity-provider-does-not-exist.md +++ /dev/null @@ -1,183 +0,0 @@ ---- -title: Error AADSTS50020 - User account from identity provider does not exist in tenant -description: Troubleshoot scenarios in which a guest user unsuccessfully tries to sign in to the resource tenant and error code AADSTS50020 is returned -ms.date: 11/23/2023 -ms.editor: v-jsitser -ms.reviewer: rrajan, haelshab, sungow, v-leedennis -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications, no-azure-ad-ps-ref -keywords: AADSTS50020 -#Customer intent: As a Microsoft Entra administrator, I want to figure out why error code AADSTS50020 occurs so that I can make sure that my guest users from an identity provider can sign in to a resource tenant. ---- -# Error AADSTS50020 - User account from identity provider does not exist in tenant - -This article helps you troubleshoot error code `AADSTS50020` that's returned if a guest user from an identity provider (IdP) can't sign in to a resource tenant in Microsoft Entra ID. - -## Symptoms - -When a guest user tries to access an application or resource in the resource tenant, the sign-in fails, and the following error message is displayed: - -> AADSTS50020: User account 'user@domain.com' from identity provider {IdentityProviderURL} does not exist in tenant {ResourceTenantName}. - -When an administrator reviews the sign-in logs on the home tenant, a "90072" error code entry indicates a sign-in failure. The error message states: - -> User account {email} from identity provider {idp} does not exist in tenant {tenant} and cannot access the application {appId}({appName}) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Microsoft Entra user account. - -### Cause 1： Users log in to Microsoft Entra admin center by using personal Microsoft Accounts - -When you try to log in to Microsoft Entra admin center by using your personal Microsoft Accounts (Outlook, Hotmail or OneDrive), you are connected to the Microsoft Services tenant by default. Within the default tenant, there is no linked directory for performing any actions. This behavior is expected. - -In the prior experience, a directory (for example: UserNamehotmail735.onmicrosoft.com) is created and linked to the personal account, and you can perform actions such as creating user accounts in the directory. The behavior has now been changed. - -### Solution: Create an Azure account with a new tenant - -If you aim to have a directory, you must create an Azure account and a new tenant: - -1. Browse to [https://azure.microsoft.com/en-us/free/](https://azure.microsoft.com/free/), and then select **Start free** . -2. Follow the instructions to create an Azure account. -3. A tenant will be generated alongside the Azure account, and you will be automatically designated as the Global Administrator. This grants you full access to all options within this tenant. - -## Cause 2: Used unsupported account type (multitenant and personal accounts) - -If your app registration is set to a single-tenant account type, users from other directories or identity providers can't sign in to that application. - -### Solution: Change the sign-in audience setting in the app registration manifest - -To make sure that your app registration isn't a single-tenant account type, perform the following steps: - -1. In [the Azure portal](https://portal.azure.com), search for and select **App registrations**. -1. Select the name of your app registration. -1. In the sidebar, select **Manifest**. -1. In the JSON code, find the **signInAudience** setting. -1. Check whether the setting contains one of the following values: - - **AzureADandPersonalMicrosoftAccount** - - **AzureADMultipleOrgs** - - **PersonalMicrosoftAccount** - - If the **signInAudience** setting doesn't contain one of these values, re-create the app registration by having the correct account type selected. You currently can't change **signInAudience** in the manifest. - -For more information about how to register applications, see [Quickstart: Register an application with the Microsoft identity platform](/azure/active-directory/develop/quickstart-register-app). - -## Cause 3: Used the wrong endpoint (personal and organization accounts) - -Your authentication call must target a URL that matches your selection if your app registration's supported account type was set to one of the following values: - -- **Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant)** - -- **Accounts in any organizational directory (Any Microsoft Entra directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)** - -- **Personal Microsoft accounts only** - -If you use `https://login.microsoftonline.com/`, users from other organizations can't access the application. You have to add these users as guests in the tenant that's specified in the request. In that case, the authentication is expected to be run on your tenant only. This scenario causes the sign-in error if you expect users to sign in by using federation with another tenant or identity provider. - -### Solution: Use the correct sign-in URL - -Use the corresponding sign-in URL for the specific application type, as listed in the following table: - -| Application type | Sign-in URL | -| ---------------- | ----------- | -| Multitenant applications | `https://login.microsoftonline.com/organizations` | -| Multitenant and personal accounts | `https://login.microsoftonline.com/common` | -| Personal accounts only | `https://login.microsoftonline.com/consumers` | - -In your application code, apply this URL value in the `Authority` setting. For more information about `Authority`, see [Microsoft identity platform application configuration options](/azure/active-directory/develop/msal-client-application-configuration#authority). - -## Cause 4: Signed in to the wrong tenant - -When users try to access your application, either they're sent a direct link to the application, or they try to gain access through . In either situation, users are redirected to sign in to the application. In some cases, the user might already have an active session that uses a different personal account than the one that's intended to be used. Or they have a session that uses their organization account although they intended to use a personal guest account (or vice versa). - -To make sure that this scenario is the issue, look for the `User account` and `Identity provider` values in the error message. Do those values match the expected combination or not? For example, did a user sign in by using their organization account to your tenant instead of their home tenant? Or did a user sign in to the `live.com` identity provider by using a different personal account than the one that was already invited? - -### Solution: Sign out, then sign in again from a different browser or a private browser session - -Instruct the user to open a new in-private browser session or have the user try to access from a different browser. In this case, users must sign out from their active session, and then try to sign in again. - -## Cause 5: Guest user wasn't invited - -The guest user who tried to sign in was not invited to the tenant. - -### Solution: Invite the guest user - -Make sure that you follow the steps in [Quickstart: Add guest users to your directory in the Azure portal](/azure/active-directory/external-identities/b2b-quickstart-add-guest-users-portal) to invite the guest user. - -## Cause 6: App requires user assignment - -If your application is an enterprise application that requires user assignment, error `AADSTS50020` occurs if the user isn't on the list of allowed users who are assigned access to the application. To check whether your enterprise application requires user assignment: - -1. In the [Azure portal](https://portal.azure.com), search for and select **Enterprise applications**. - -1. Select your enterprise application. - -1. In the sidebar, select **Properties**. - -1. Check whether the **Assignment required** option is set to **Yes**. - -### Solution: Assign access to users individually or as part of a group - -Use one of the following options to assign access to users: - -- To individually assign the user access to the application, see [Assign a user account to an enterprise application](/azure/active-directory/manage-apps/add-application-portal-assign-users#assign-a-user-account-to-an-enterprise-application). - -- To assign users if they're a member of an assigned group or a dynamic group, see [Manage access to an application](/azure/active-directory/manage-apps/what-is-access-management). - -## Cause 7: Tried to use a resource owner password credentials flow for personal accounts - -If a user tries to use the resource owner password credentials (ROPC) flow for personal accounts, error `AADSTS50020` occurs. The Microsoft identity platform supports ROPC only within Microsoft Entra tenants, not personal accounts. - -### Solution: Use an endpoint that's specific to the tenant or organization - -Use a tenant-specific endpoint (`https://login.microsoftonline.com/`) or the organization's endpoint. Personal accounts that are invited to a Microsoft Entra tenant can't use ROPC. For more information, see [Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials](/azure/active-directory/develop/v2-oauth-ropc). - -## Cause 8: A previously deleted user name was re-created by the home tenant administrator - -Error `AADSTS50020` might occur if the name of a guest user who was deleted in a resource tenant is re-created by the administrator of the home tenant. To verify that the guest user account in the resource tenant isn't associated with a user account in the home tenant, use one of the following options: - -### Verification: Check whether the resource tenant's guest user is older than the home tenant's user account - -To check the creation date of the guest user account, you can use Microsoft Graph, Microsoft Entra PowerShell, or the Microsoft Graph PowerShell SDK. - -#### Microsoft Graph - -Issue a request to the [MS Graph API](/graph/api/user-get) to review the user creation date, as follows: - - - -```msgraph-interactive -GET https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}/createdDateTime -``` - -Then, check the creation date of the guest user in the resource tenant against the creation date of the user account in the home tenant. The scenario is confirmed if the guest user was created before the home tenant's user account was created. - -#### Microsoft Entra PowerShell - -Run the [Get-EntraUser](/powershell/module/microsoft.entra/get-entrauser) PowerShell cmdlet to review the user creation date, as follows: - -```powershell -Get-EntraUser -UserId {id | userPrincipalName} | Select-Object id, userPrincipalName, createdDateTime -``` - -Then, check the creation date of the guest user in the resource tenant against the creation date of the user account in the home tenant. The scenario is confirmed if the guest user was created before the home tenant's user account was created. - -#### Microsoft Graph PowerShell SDK - -Run the [Get-MgUser](/powershell/module/microsoft.graph.users/get-mguser) PowerShell cmdlet to review the user creation date, as follows: - -```powershell -$p = @('Id', 'UserPrincipalName', 'CreatedDateTime') -Get-MgUser -UserId {id | userPrincipalName} -Property $p| Select-Object $p -``` - -Then, check the creation date of the guest user in the resource tenant against the creation date of the user account in the home tenant. The scenario is confirmed if the guest user was created before the home tenant's user account was created. - -### Solution: Reset the redemption status of the guest user account - -Reset the redemption status of the guest user account in the resource tenant. Then, you can keep the guest user object without having to delete and then re-create the guest account. You can reset the redemption status by using the Azure portal, Azure PowerShell, or the Microsoft Graph API. For instructions, see [Reset redemption status for a guest user](/azure/active-directory/external-identities/reset-redemption-status). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS50105-user-not-assigned-role.md b/support/entra/entra-id/app-integration/error-code-AADSTS50105-user-not-assigned-role.md deleted file mode 100644 index 3796f4c1079..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS50105-user-not-assigned-role.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Error AADSTS50105 - The signed in user is not assigned to a role for the application. -description: Describes a problem in which you receive the AADSTS50105 error when you sign in to a SAML-based configured app with Microsoft Entra SSO. -ms.date: 07/19/2023 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50105 - The signed in user is not assigned to a role for the application - -This article provides a resolution to the AADSTS50105 error that occurs during federated authentication with Microsoft Entra ID. - -[!INCLUDE [Feedback](../../../includes/feedback.md)] - -## Symptoms - -You receive the following error message when you try to sign in to an application that has been set up to use Microsoft Entra ID for identity management using SAML-based Single Sign-On (SSO): - ->Error AADSTS50105 - The signed in user is not assigned to a role for the application. - -## Cause - -The user hasn't been granted access to the application in Microsoft Entra ID. The user must belong to a group that is assigned to the application, or be assigned directly. - ->[!Note] ->Nested groups are not supported, and the group must be directly assigned to the application. - -## Resolution - -To assign one or more users to an application directly, see [Quickstart: Assign users to an app](/azure/active-directory/manage-apps/add-application-portal-assign-users). - -## More Information - -For a full list of Active Directory authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS650056-misconfigured-app.md b/support/entra/entra-id/app-integration/error-code-AADSTS650056-misconfigured-app.md deleted file mode 100644 index 4f631d5cd8b..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS650056-misconfigured-app.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Error AADSTS650056 - Misconfigured application -description: Provides solutions for the AADSTS650056 misconfiguration error. -ms.date: 05/19/2025 -ms.reviewer: willfid -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS650056: Misconfigured application - -This article provides troubleshooting steps and solutions for the "AADSTS650056: Misconfigured application" error. - -## Symptoms - -When you try to sign in to a web application that uses Microsoft Entra ID, you receive the following error message: - -> AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not listed any permissions for 'AAD Graph' in the requested permissions in the client’s application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant. - -## Cause - -This error typically occurs for one of the following reasons: - -- The Issuer that's provided in the SAMLRequest is not valid. -- The application doesn't have the required permissions to call Microsoft Graph APIs. -- The admin hasn't consented to the permissions for the application on behalf of the tenant. - -## Solution 1: The Issuer provided in the SAMLRequest is not valid （for SAML Authentication flows） - -In the following SAML request example, the Issuer value must match the Identifier (Entity ID) that's configured in the enterprise application. This value is also known as the *Identifier URI* or *App ID URI*. For example, a SAML request might resemble the following request: - -``` - https://www.contoso.com -``` - -In this example, the Identifier URI is `https://www.contoso.com`. - -To fix a mismatch, do one of the following actions: - -- Update the Identifier in the enterprise application so that it matches the Issuer in the SAML request. -- Update the SaaS application configuration on the vendor side so that it passes the correct Issuer. - -## Solution 2: Verify application permissions and consent - -If your organization owns the application, follow these steps: - -1. Sign in to the [Azure portal](https://portal.azure.com), go to the **App registrations** screen, select your app registration, and then select **API permissions**. -2. Make sure that the application has at least the **User.Read** delegated permission from **Microsoft Graph**. -3. Check the **Status** field to determine whether the permissions are consented to. For example: - - If the permission isn't consented to, the value appears as **Pending** or blank. - - If the permission is successfully consented to, the value appears as "Granted for [Tenant Name]." - - Example of a consented permission: - - :::image type="content" source="./media/error-code-AADSTS650056-misconfigured-app/graph-api-permissions.png" alt-text="Screenshot of adding Graph API permissions." ::: - -If your organization isn't the application owner, follow these steps: - -1. Sign in to the application by using a Global Administrator account. You should see a consent screen that prompts you to grant permissions. Make sure that you select the **Consent on behalf of your organization** option before you proceed. - - Example of the consent screen: - - :::image type="content" source="./media/error-code-AADSTS650056-misconfigured-app/consent-permissions.png" alt-text="Screenshot of consent screen" ::: - -2. If you don't see the consent screen, delete the application from the **Enterprise applications** section in Microsoft Entra ID, and then try again to sign in. - -If the error persists, go to the next solution. - -## Solution 3: Manually build the consent URL - -If the application is designed to access a specific resource, you might not be able to use the **Consent** button in the Azure portal. Instead, you might have to manually generate a consent URL, and then open the URL to grant permissions to the application. - -### For the authorization V1 endpoint - -The consent URL resembles the following text: - -```HTTP -https://login.microsoftonline.com/{Tenant-Id}/oauth2/authorize?response\_type=code -&client\_id={App-Id} -&resource={App-Uri-Id} -&scope=openid -&prompt=consent -``` - -For example: - -```HTTP -https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize -?response\_type=code -&client\_id=044abcc4-914c-4444-9c3f-48cc3140b6b4 -&resource=https://vault.azure.net/ -&scope=openid -&prompt=consent -``` -### For the authorization V2 endpoint - -The consent URL resembles the following text: - -```HTTP -https://login.microsoftonline.com/{Tenant-Id}/oauth2/v2.0/authorize -?response_type=code -&client_id={App-Id} -&scope=openid+{App-Uri-Id}/{Scope-Name} -&prompt=consent -``` - -For example: - -```HTTP -https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize -?response_type=code -&client_id=044abcc4-914c-4444-9c3f-48cc3140b6b4 -&scope=openid+https://vault.azure.net/user_impersonation -&prompt=consent -``` - -- If the application accesses itself as the resource, **{App-Id}** and **{App-Uri-Id}** are the same. -- You can get the **{App-Id}** and **{App-Uri-Id}** values from the application owner. -- **{Tenant-Id}** corresponds to your tenant identifier. This value can be either your domain or your directory ID. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS70001-app-not-found-in-directory.md b/support/entra/entra-id/app-integration/error-code-AADSTS70001-app-not-found-in-directory.md deleted file mode 100644 index 0f9fe2a7219..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS70001-app-not-found-in-directory.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: Error AADSTS70001 - Application with Identifier was not found in the directory. -description: Describes a problem in which you receive the error AADSTS70001 when you sign in to SAML sign-on configured app with Microsoft Entra ID. -ms.date: 10/12/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS70001 - Application with Identifier was not found in the directory - -This article describes a problem in which you receive the error message "Error AADSTS70001 - Application with Identifier was not found in the directory." when trying to sign into a SAML-based single sign-on (SSO) configured app that has been integrated with Microsoft Entra ID. - -## Symptoms - -You receive error `AADSTS70001` when trying to sign into an application that has been set up to use Microsoft Entra ID for identity management using SAML-based SSO. - -## Cause - -The `Issuer` attribute sent from the application to Microsoft Entra ID in the SAML request doesn’t match the Identifier value that's configured for the application in Microsoft Entra ID. - -## Resolution - -Ensure that the `Issuer` attribute in the SAML request matches the Identifier value configured in Microsoft Entra ID. - -On the SAML-based SSO configuration page, in the **Basic SAML configuration** section, verify that the value in the Identifier textbox matches the value for the identifier value displayed in the error. If there's a trailing slash at the end of the url, it should be also included. - - - -### Using the Test SSO Function in the Microsoft Entra admin center - -The Microsoft Entra admin center can help you troubleshoot SAML configuration errors. - -:::image type="content" source="media/testing-sso-screen.PNG" alt-text="Screenshot of Testing SSO Feature in Microsoft Entra admin center."::: - -1. In the Microsoft Entra admin center, go to **Enterprise Applications** and click on the application needing troubleshooting. -2. Navigate to the **Single sign-on** page using the left-hand navigation menu -3. Click on **Test this application** to use the Test SSO functionality. -4. Copy and paste the error received into the **Resolving Errors** section and click **Get resolution guidance** -5. View the difference between the Issuer and Identifier found. -6. Correct either the Issuer or Identifier. - -## More Information - -For a full list of Active Directory Authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS75005-not-a-valid-saml-request.md b/support/entra/entra-id/app-integration/error-code-AADSTS75005-not-a-valid-saml-request.md deleted file mode 100644 index 16cae6c2100..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS75005-not-a-valid-saml-request.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Error AADSTS75005 - The request is not a valid Saml2 protocol message -description: Describes a problem in which you receive AADSTS75005 error when signing in to SAML-based single sign-on configured app. -ms.date: 08/26/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS75005 - The request is not a valid Saml2 protocol message - -This article describes a problem in which you receive the error message "Error AADSTS75005 - The request is not a valid Saml2 protocol message." when you try to sign into an apapplication that has been integrated with Microsoft Entra ID. - -## Symptoms - -You receive error `AADSTS75005` when trying to sign into an application that has been set up to use Microsoft Entra ID for identity management using SAML-based SSO. - -## Cause - -Microsoft Entra ID doesn't support the SAML request sent by the application for single sign-on. Some common issues are: - -- Missing required fields in the SAML request. -- SAML request encoded method. - -## Resolution - -1. Capture the SAML request. Follow the tutorial [How to debug SAML-based single sign-on to applications in Microsoft Entra ID](/azure/active-directory/manage-apps/debug-saml-sso-issues) to learn how to capture the SAML request. -1. Contact the application vendor and share the following info: - - SAML request - - [Microsoft Entra Single Sign-on SAML protocol requirements](/azure/active-directory/develop/single-sign-on-saml-protocol) - -The application vendor should validate that they support the Microsoft Entra SAML implementation for single sign-on. - -## More Information - -For a full list of Active Directory Authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS750054-saml-request-not-present.md b/support/entra/entra-id/app-integration/error-code-AADSTS750054-saml-request-not-present.md deleted file mode 100644 index 3f20ab9dbf1..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS750054-saml-request-not-present.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Error AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding. -description: Describes a problem in which you receive an error message when signing in to SAML-based single sign-on configured app that has been configured to use Microsoft Entra ID as an Identity Provider (IdP). The error you receive is Error AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding. -ms.date: 10/12/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding - -This article describes a problem in which you receive the error message "Error AADSTS750054 - SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding." when trying to sign into a SAML-based single sign-on (SSO) configured app that has been integrated with Microsoft Entra ID. - -## Symptoms - -You receive error `AADSTS750054` when trying to sign into an application that has been setup to use Microsoft Entra ID for identity management using SAML-based SSO. - -## Cause - -Microsoft Entra ID wasn't able to identify the SAML request within the URL parameters in the HTTP request. This can happen if the application is not using HTTP redirect binding when sending the SAML request to Microsoft Entra ID. - -## Resolution - -The application needs to send the SAML request encoded into the location header using HTTP redirect binding. For more information about how to implement it, read the section HTTP Redirect Binding in the [SAML protocol specification document](https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf). - -Most often, the error is due to one of the following issues: - -1. Ensure that single-sign on is enabled on the application side. -2. The application must support service provider-initiated single sign-on (sometimes known as SP-initiated SSO). When entering a sign-in URL for an application that only supports identity provider-initiated single sign-on can lead to a bounce back from the application without a SAML response. -3. Verify that the sign-on URL is correctly configured. - - - -### Using the Test SSO Function in the Microsoft Entra admin center - -The Microsoft Entra admin center can help you troubleshoot SAML configuration errors. - -:::image type="content" source="media/testing-sso-screen.PNG" alt-text="Screenshot of Testing SSO Feature in Microsoft Entra admin center."::: - -1. In the Microsoft Entra admin center, go to **Enterprise Applications** and click on the application needing troubleshooting. -2. Navigate to the **Single sign-on** page using the left-hand navigation menu -3. Click on **Test this application** to use the Test SSO functionality. -4. Copy and paste the error received into the **Resolving Errors** section and click **Get resolution guidance** -5. Follow the steps to troubleshoot error `AADSTS750054` - -## More Information - -For a full list of Active Directory Authentication and authorization error codes see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-AADSTS75011-auth-method-mismatch.md b/support/entra/entra-id/app-integration/error-code-AADSTS75011-auth-method-mismatch.md deleted file mode 100644 index 98b20066f65..00000000000 --- a/support/entra/entra-id/app-integration/error-code-AADSTS75011-auth-method-mismatch.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef. -description: Describes a problem in which you receive an error message when signing in to SAML-based single sign-on configured app that has been configured to use Microsoft Entra ID as an Identity Provider (IdP). The error you receive is Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef -ms.date: 08/26/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef - -This article describes a problem in which you receive the error message, "Error - AADSTS75011 Authentication method by which the user authenticated with the service doesn't match requested authentication method AuthnContextClassRef," when you try to sign in to a SAML-based single sign-on (SSO) configured app that has been integrated with Microsoft Entra ID. - -[!INCLUDE [Feedback](../../../includes/feedback.md)] - -## Symptoms - -You receive a `AADSTS75011` error message when you try to sign in to an application that has been set up to use Microsoft Entra ID for identity management by using SAML-based SSO. - -## Cause - -The `RequestedAuthnContext` is in the SAML request. This means the app is expecting the `AuthnContext` specified by the `AuthnContextClassRef`. However, the user has already authenticated prior to access the application and the `AuthnContext` (authentication method) used for that previous authentication is different from the one being requested. For example, a federated user access to MyApps and WIA occurred. The `AuthnContextClassRef` will be `urn:federation:authentication:windows`. Microsoft Entra ID won't perform a fresh authentication request, it will use the authentication context that was passed-through it by the IdP (ADFS or any other federation service in this case). Therefore, there will be a mismatch if the app requests other than `urn:federation:authentication:windows`. Another scenario is when MultiFactor was used: `'X509, MultiFactor`. - -## Resolution - -`RequestedAuthnContext` is an optional value. If possible, ask the application if the value could be removed. - -Another option is to make sure that the `RequestedAuthnContext` value will be honored. This is done by requesting a fresh authentication. By doing this, when the SAML request is processed, a fresh authentication is done and `AuthnContext` is honored. In order to request a Fresh Authentication, the SAML request must contain the value, `forceAuthn="true"`. - -## More information - -For a full list of Active Directory Authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-aadsts-error-codes) - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts220501-unable-to-download-certificate-revocation-list.md b/support/entra/entra-id/app-integration/error-code-aadsts220501-unable-to-download-certificate-revocation-list.md deleted file mode 100644 index 82dff72cd15..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts220501-unable-to-download-certificate-revocation-list.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Microsoft Entra authentication error AADSTS220501 -description: Provides a solution to the Microsoft Entra authentication error AADSTS220501. -ms.reviewer: laks, custorod, v-weizhu -ms.service: entra-id -ms.date: 10/16/2024 -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS220501 - Unable to download Certificate Revocation List - -This article provides a solution to the Microsoft Entra authentication error AADSTS220501 that occurs when you use certificate-based authentication. - -## Symptoms - -When you try to sign in to an application with certificate-based authentication, you receive the error AADSTS220501 with the following message: - -> Unable to download Certificate Revocation List (CRL). Invalid response or no response from CRL Distribution Point {source} - -## Cause - -The Certificate Revocation List (CRL) is inaccessible or has expired. - -## Resolution - -To resolve this issue, follow these steps: - -1. Verify if the CRL file path is accessible publicly by opening the CRL distribution point URL via a web browser. - - Here's an example of a CRL distribution point URL: - - `http://Contoso.com/CRLfilepath/CRLfilename.crl` - - To find the CRL distribution point URL for the tenant, see [Configure certification authorities using the Microsoft Entra admin center](/entra/identity/authentication/how-to-certificate-based-authentication#configure-certification-authorities-using-the-microsoft-entra-admin-center). - -2. If the CRL file path is inaccessible, move the CRL to a publicly available location. - - If the CRL file path is accessible, open the CRL file, go to the **General** tab, and then check the date and time in the **Next Update** field that denotes the expiry date of the CRL. If this date and time is earlier than the current system date, Windows computers will invalidate certificates that are checked against this CRL. You have to renew the CRL manually and replace the expired CRL. - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-error-codes). - -To investigate individual errors, go to https://login.microsoftonline.com/error. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts50000-issuing-token-sign-in-service.md b/support/entra/entra-id/app-integration/error-code-aadsts50000-issuing-token-sign-in-service.md deleted file mode 100644 index bb35f9e1229..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts50000-issuing-token-sign-in-service.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Error AADSTS50000 - There Was an Error Issuing a Token or an Issue with Our Sign-In Service -description: Provides a solution to the AADSTS50000 error that occurs when you try to sign in to an Azure app by using Microsoft Entra ID. -ms.service: entra-id -ms.date: 03/12/2025 -ms.author: bachoang -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS50000 getting a token or signing in to an Azure app - -The AADSTS50000 error can occur during the authentication process or token acquisition flow that uses the token endpoint. These errors can have multiple causes. This article provides common scenarios and resolutions for this error. - -## Symptoms - -When a user tries to sign in to an application that's integrated into Microsoft Entra ID, the user receives the following error message: - -> AADSTS50000: There was an error issuing a token or an issue with our sign-in service. - -## Cause 1: The user password is expired, invalid, or out of sync - -This issue is common in hybrid environments. The user's federated account password might be out of sync between the on-premises Active Directory and Microsoft Entra ID. Additionally, this issue can also occur when a user session is being revoked. - -### Solution for cause 1 - -Reset the user password, and then verify that the new password can successfully authenticate to Microsoft Entra ID. - -## Cause 2: Parameters are incorrectly configured in the token acquisition request - -This problem commonly occurs in the on-behalf-of (OBO) flow. Certain parameters that are required for token acquisition might be missing or invalid. - -### Solution for cause 2 - -Make sure that the client ID is valid and that other required parameters are configured correctly. For more information, see [Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow](/entra/identity-platform/v2-oauth2-on-behalf-of-flow). - -## Cause 3: Consent-related issues - -This issue can occur in an OAuth2 Device code grant flow to the token endpoint. After the user signs in to a browser window and accepts the consent dialog, this error occurs. - -### Solution for cause 3: Verify application consent settings - -1. In the [Azure portal](https://portal.azure.com), make sure that the client application (Service Principal) exists on the tenant's **Enterprise Applications** page. You can search for the application by App ID. -2. Verify that the user can consent to the application. Check the user settings on the **Enterprise Applications** page or review relevant policies that affect user consent. - -## Cause 4: Symmetric signing key is used in the application or service principal object - -Microsoft Identity Platform (v2 endpoint) tokens must be signed by a certificate (asymmetric key). Errors might occur if a symmetric signing key is used. - -### Solution for cause 4 - -#### Step 1: Check whether symmetric key is used in application object - -1. In the Azure portal, go to the **App Registrations**. -2. In the **Manage** section, select **Manifest**. -3. Check whether an entry exists in the `keyCredentials` section that includes `type=Symmetric` and `usage=Sign`. - - :::image type="content" source="./media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png" alt-text="Screenshot that shows the Application Manifest Key Credentials code." lightbox="./media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png"::: - -Alternatively, use the Microsoft Graph PowerShell cmdlet [Get-MgApplication](/powershell/module/azuread/get-azureadapplicationkeycredential) to retrieve key credentials. - -#### Step 2: Check whether symmetric key is used in service principal object - -1. If the application is not found in the **App Registrations** page in the Azure portal, browse to the **Enterprise Applications** page. -2. Locate the application, and then get the **Object ID** of the Service Principal. -3. Use [Get-MgServicePrincipal](/powershell/module/microsoft.graph.applications/get-mgserviceprincipal) to retrieve the key credentials. - -#### Step 3: Remove symmetric signing key - -If the symmetric key exists: - -- Use [Remove-MgApplicationKey](/powershell/module/microsoft.graph.applications/remove-mgapplicationkey) to remove the symmetric key for the app registration. -- Use [Remove-MgServicePrincipalKey](/powershell/module/microsoft.graph.applications/remove-mgserviceprincipalkey) to remove the symmetric key for the service principal object. - -If a signing key is required, use a signing certificate instead. For more information, see [SAML-based single sign-on: Configure a signing certificate](/graph/application-saml-sso-configure-api?tabs=http%2Cpowershell-script#step-6-configure-a-signing-certificate). - -## Cause 5: No delegated permission exposed in the resource application (web API) - -This error might occur in the following scenario: - -- You have a multitenant resource application that's registered in Tenant A. This application exposes only the **Application Permission** type. -- In Tenant B, you have a client application registered. In the **API permission** page for this application, you configure the permission for the resource application that's registered in Tenant A. -- You use an OAuth 2 delegated grant flow (for instance auth code grant flow) to request an access token for the resource app that uses `/.default` as the value of the web API scope. - -### Solution for cause 5 - -Configure the resource application to expose the delegated permission, and then consent to that delegated permission in the client application. diff --git a/support/entra/entra-id/app-integration/error-code-aadsts500011-resource-principal-not-found.md b/support/entra/entra-id/app-integration/error-code-aadsts500011-resource-principal-not-found.md deleted file mode 100644 index 03d0b4066ae..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts500011-resource-principal-not-found.md +++ /dev/null @@ -1,62 +0,0 @@ ---- - -title: Error AADSTS500011 - Resource Principal Not Found -description: Describes a problem in which a user experiences an AADSTS500011 error when trying to sign in to Microsoft Entra ID. -author: custorod -ms.author: custorod -ms.service: entra-id -ms.topic: troubleshooting-problem-resolution -ms.date: 01/16/2025 -ms.subservice: authentication -ms.custom: sap:Issues Signing In to Applications ---- - -# AADSTS500011 - Resource Principal Not Found - -This article describes a problem in which users experiences an "AADSTS500011" error when they try to sign in to Microsoft Entra ID. - -## Symptoms - -When users try to sign in to an application that uses Microsoft Entra ID authentication, they receive the following error message: - -> `AADSTS500011 - The resource principal named [resource URL] was not found in the tenant named [tenant ID]` - -## Cause - -This issue occurs if the resource principal (the application or service) is not found in the tenant. This issue occurs if: - -- The resource application isn't provisioned by the administrator in the tenant. -- The resource application isn't consented to by any user in the tenant. -- The resource URL is not configured correctly. -- The tenant ID is not correct. - -## Resolution - -To resolve this issue, follow these steps: - -1. **Verify resource application provisioning**: - - - Make sure that the application (resource principal) is registered correctly in your Microsoft Entra ID tenant. - - Go to the [Azure portal](https://portal.azure.com), and navigate to Microsoft Entra ID > Enterprise applications. - - Check whether the application is listed and correctly configured. - -1. **Consent to application**: - - Make sure that the resource application has been consented to by an administrator or a user in the tenant. - - Go to the [Azure portal](https://portal.azure.com), and navigate to Microsoft Entra > Enterprise applications. - - Find the application, and make sure that it has the necessary permissions and consent. - -1. **Check resource URL**: - - Verify that the resource URL that appears in the error message matches the resource application that you provisioned in your tenant ID. - - Make sure that the authentication request is sent by using the correct resource URL. - -1. **Check tenant ID**: - - Verify that the tenant ID that appears in the error message is the same as your tenant ID. - - Make sure that the authentication request is sent to the correct Microsoft Entra ID tenant. - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-error-codes). - -To investigate individual errors, go to [https://login.microsoftonline.com/error](https://login.microsoftonline.com/error). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts50017-certificate-based-authentication-failed.md b/support/entra/entra-id/app-integration/error-code-aadsts50017-certificate-based-authentication-failed.md deleted file mode 100644 index fe99061fb33..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts50017-certificate-based-authentication-failed.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Error AADSTS50017 - Validation of Given Certificate for Certificate-Based Authentication Failed -description: Provides solutions to the Microsoft Entra authentication AADSTS50017 error that occurs when you access an application or resource with certificate-based authentication (CBA). -ms.reviewer: laks, joaos, willfid, v-weizhu -ms.service: entra-id -ms.date: 02/25/2025 -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS50017 - Validation of given certificate for certificate-based authentication failed - -This article provides solutions to the Microsoft Entra authentication AADSTS50017 error that occurs when you access an application or resource with certificate-based authentication (CBA). - -## Symptoms - -When you try to access an application or resource with CBA, the sign-in process fails and the following error message is displayed: - -> AADSTS50017: Validation of given certificate for certificate based authentication failed. - -## Cause 1: Certificate chain failures or validation failures - -The AADSTS50017 error might occur because of the following problems: - -- Certificate chain failures due to missing certificate authority (CA) certificates in store. -- Validation failures with Subject Key Identifier (SKI) and Authority Key Identifier (AKI) values. - - In Public Key Infrastructure (PKI), the certificate chain validation process ensures the integrity and authenticity of the certificate chain. The SKI and AKI play crucial roles in this process. The SKI provides a unique identifier for the public key held by the certificate. The AKI is used to identify the CA that issues the certificate. - -To resolve this issue, follow these steps: - -1. Check if issuing certificate is correctly uploaded to the trusted certificate list. - - A certificate chain consists of multiple certificates linked together. The end user's certificate can be issued by a root CA or a non-root CA (intermediate CA). If you have a non-root issuing CA (intermediate CA), both intermediate and root CA certificates must be uploaded to the Microsoft Entra CA trusted store. - -2. Check the SKI value of your certificate and confirm if the AKI value matches any intermediate or root CA certificate that's uploaded to the trusted store. - - If there is no match, your certificate or the missing CA certificate should be changed accordingly. To do this, [configure certificate authorities by using the Microsoft Entra admin center](/entra/identity/authentication/how-to-certificate-based-authentication#configure-certificate-authorities-by-using-the-microsoft-entra-admin-center). - - To get the SKI and AKI values, check the details of your certificate and uploaded issuing CA certificates. - - :::image type="content" source="media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-chain-ski-aki-value.png" alt-text="Screenshot that shows a certificate chain." lightbox="media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-chain-ski-aki-value.png"::: - - |Certificate type|Characteristic| - |---|---| - |Root CA certificate|It has its own SKI. It can issue the intermediate certificates when applicable. It doesn't contain the AKI field.| - |Issuing or intermediate CA certificate (when applicable)|Its AKI points to the Root CA certificate's SKI. It has its own SKI that matches the AKI on a user certificate. It can issue user certificates, and issue intermediate certificates when applicable. Multiple intermediate CA certificates can exist.| - |End-Entity (User or Client) certificate|It has its own SKI. Its AKI points to the issuing CA certificate's SKI.| - -## Cause 2: Invalid certificates - -If any certificates in the certificate chain are missing valid extension identifiers, such as certificate policy extensions, the AADSTS50017 error might occur. - -To resolve this error, validate the certificate policy extensions for all certificates within the certificate chain, including user certificates, intermediate CA certificates, and the root CA certificate. Ensure that the certificate policy extension and its Object Identifiers (OIDs) are consistent and valid across the entire chain. - -To verify the policy OIDs for consistency and validity, retrieve the relevant certificates in chain and validate them as follows: - -:::image type="content" source="media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-policies.png" alt-text="Screenshot that shows certificate policies." lightbox="media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-policies.png"::: - -If any certificates are missing certificate policy extensions, reissue the CA certificate or end user certificate with the appropriate certificate policy extensions embedded. - -For more information about policy extension and other supported extensions, see [Supported Extensions](/windows/win32/seccertenroll/supported-extensions). - -## AADSTS error code reference - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/entra/identity-platform/reference-error-codes). To investigate individual errors, search at https://login.microsoftonline.com/error. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/error-code-aadsts50057-user-account-is-disabled.md b/support/entra/entra-id/app-integration/error-code-aadsts50057-user-account-is-disabled.md deleted file mode 100644 index 3c0384a8993..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts50057-user-account-is-disabled.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Error AADSTS50057 - User account is disabled -description: Provides a solution to an issue where a user experiences the AADSTS500571 error when they try to sign in to an Azure app that can be used with Microsoft Entra ID. -ms.service: entra-id -ms.date: 12/25/2023 -ms.reviewer: custorod, joaos, v-weizhu -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS50057 - User account is disabled - -This article discusses how to resolve the "AADSTS50057" error that occurs when a user tries to sign in to an application that can be used together with Microsoft Entra ID. - -## Symptoms - -When users try to sign in to an application that's integrated into Microsoft Entra ID, they receive an "AADSTS50057" error message ("The user account is disabled."). - -## Cause - -The user object is disabled on the resource tenant. - -## Solution - -Engage the resource tenant owners to determine why the user account is disabled. Then, take the corresponding action, as shown in the following table. - -| Scenario | Action | -|--|--| -| The user account is supposed to be disabled. | No actions should be performed. Access is expectedly blocked. | -| The user account isn't supposed to be disabled, or it was disabled by mistake. | Resource tenant owners should re-enable the account. One of the options to re-enable the account is using PowerShell to set the `-AccountEnabled` parameter to `$true`, as described in the [Set-AzureADUser](/powershell/module/azuread/set-azureaduser#parameters) cmdlet reference. | - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-error-codes). - -To investigate individual errors, go to [https://login.microsoftonline.com/error](https://login.microsoftonline.com/error). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts500571-guest-user-account-is-disabled.md b/support/entra/entra-id/app-integration/error-code-aadsts500571-guest-user-account-is-disabled.md deleted file mode 100644 index ff0f3e6da4f..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts500571-guest-user-account-is-disabled.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Error AADSTS500571 - Guest user account is disabled -description: Resolve a scenario in which a guest user experiences an AADSTS500571 error when they try to sign in to an Azure app that can be used with Microsoft Entra ID. -author: custorod -ms.author: custorod -ms.reviewer: azureidcic, v-leedennis -editor: v-jsitser -ms.service: entra-id -ms.date: 11/02/2023 -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS500571 - Guest user account is disabled - -This article discusses how to resolve an `AADSTS500571` error that occurs when a user tries to sign in to an application that can be used together with Microsoft Entra ID. - -## Symptoms - -When a guest user tries to sign in to an application that's integrated into Microsoft Entra ID, they receive an "AADSTS500571" error message ("The guest user account is disabled"). - -## Cause - -The guest user object is disabled on the resource tenant. - -## Solution - -Engage the resource tenant owners or sponsor to determine the reason that the guest account is disabled. Then, take the corresponding action, as shown in the following table. - -| Scenario | Action | -|--|--| -| The guest account is supposed to be disabled. | No actions should be performed. Access is expectedly blocked. | -| The guest account isn't supposed to be disabled, or it was disabled by mistake. | Resource tenant owners should re-enable the account. One of the options to re-enable the account is by using PowerShell to set the `-AccountEnabled` parameter to `$true`, as described in the [Set-AzureADUser](/powershell/module/azuread/set-azureaduser#parameters) cmdlet reference. | - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-error-codes). - -To investigate individual errors, go to . - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts50173-grant-expired-revoked.md b/support/entra/entra-id/app-integration/error-code-aadsts50173-grant-expired-revoked.md deleted file mode 100644 index 780e1955ad1..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts50173-grant-expired-revoked.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Error code AADSTS50173 - The Provided Grant Has Expired Due to it Being Revoked -description: Discusses how to handle a situation in which a user receives an AADSTS50173 error when trying to sign in to an application. -author: custorod -ms.author: custorod -ms.reviewer: joaos -ms.service: entra-id -ms.topic: troubleshooting-problem-resolution -ms.date: 02/21/2025 -ms.subservice: authentication -ms.custom: sap:Issues signing in to applications ---- - -# Error AADSTS50173 - The provided grant has expired due to it being revoked - -## Symptoms - -When users try to sign in to an application that uses Microsoft Entra ID authentication, they receive the following error message: - -> `AADSTS50173: The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password. The grant was issued on '{authTime}' and the TokensValidFrom date (before which tokens are not valid) for this user is '{validDate}'.` - - -## Cause - -This error occurs if the refresh token that's used for authentication is revoked. This issue occurs if: - -- The user changes or resets their password. -- The refresh token expires. -- An administrator revokes the refresh token. - -For more information, see: - -- [Refresh tokens in the Microsoft identity platform](/entra/identity-platform/refresh-tokens#token-revocation) -- [Revoke user access in Microsoft Entra ID](/entra/identity/users/users-revoke-access) - -## Resolution - -To resolve this issue, follow the applicable steps. - -### For users - -On the application that experiences the issues, try to locate an option to reauthenticate or clear any cached token information. You can also perform these actions by signing out and signing back in to the application (if this step is applicable or available). - -### For application developers - -If the application is using [Microsoft Authentication Library (MSAL)](/entra/identity-platform/msal-overview), follow [this guidance to handle errors and exceptions in MSAL](/entra/msal/dotnet/advanced/exceptions/msal-error-handling). - -If the application isn't using MSAL, follow this guidance to [handle errors and exceptions in MSAL](/entra/msal/dotnet/advanced/exceptions/msal-error-handling), and try to implement a similar approach on the application. The goal is to request that the user reauthenticate and obtain a fresh token. - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/entra/identity-platform/reference-error-codes). - -To investigate individual errors, go to [https://login.microsoftonline.com/error](https://login.microsoftonline.com/error). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts530004-acceptcompliantdevice-setting-not-configured.md b/support/entra/entra-id/app-integration/error-code-aadsts530004-acceptcompliantdevice-setting-not-configured.md deleted file mode 100644 index ac587f8e650..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts530004-acceptcompliantdevice-setting-not-configured.md +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Error AADSTS530004 - AcceptCompliantDevice Setting Isn't Configured -description: Provides solutions to the AADSTS530004 error when a guest user accesses an application or resource in a resource tenant. -ms.reviewer: laks, custorod, joaos, v-weizhu -ms.service: entra-id -ms.date: 12/16/2024 -ms.custom: sap:Issues Signing In to Applications ---- -# Error AADSTS530004 - AcceptCompliantDevice setting isn't configured for this organization - -This article discusses scenarios where the AADSTS530004 error occurs when a guest user accesses an application or resource in a resource tenant and provides solutions. - -## Symptoms - -When a guest user tries to access an application or resource in a resource tenant, the sign-in process fails, and the following error message is displayed: - -> AADSTS530004: AcceptCompliantDevice setting isn't configured for this organization. The administrator needs to configure this setting to allow external user access to protected resources. - -Additionally, when an administrator reviews the sign-in logs in the home tenant, the same error code is displayed. - -## Scenario 1: Conditional Access policy for compliant devices - -When a Conditional Access policy in the resource tenant is set with the **Require device to be marked as compliant** control and the policy is applied to guest users, the AADSTS530004 error can occur. - -To resolve the error, follow these steps: - -1. Create a Cross Tenant Access Policy (XTAP) policy with the [Trust compliant devices](/entra/external-id/cross-tenant-access-settings-b2b-collaboration#to-change-inbound-trust-settings-for-mfa-and-device-claims) setting in the user's home tenant. - -2. Ensure that the guest user's device is authenticated. - - Device authentication might fail under some conditions. For more information, see [Device authentication fails](#device-authentication-fails). - -3. Ensure that the guest user's device is joined to Microsoft Intune or supported mobile device management (MDM) solutions in the home tenant and is compliant. - - > [!NOTE] - > Several third-party device compliance partners are supported for integration with Microsoft Intune. For more information, see [Support third-party device compliance partners in Intune](/mem/intune/protect/device-compliance-partners). For more information about configuring Intune device compliance, see [Monitor results of your Intune Device compliance policies](/mem/intune/protect/compliance-policy-monitor). - -## Scenario 2: Conditional Access policy for hybrid-joined devices - -When a Conditional Access policy in the resource tenant is set with the **Require Microsoft Entra hybrid joined device** control and the policy is applied to guest users, the error can occur. - -To resolve the error, follow these steps: - -1. Create an XTAP policy with the [Trust Microsoft Entra hybrid joined devices](/entra/external-id/cross-tenant-access-settings-b2b-collaboration#to-change-inbound-trust-settings-for-mfa-and-device-claims) setting in the user's home tenant. - -2. Ensure that the guest user's device is authenticated. - - Device authentication might fail under some conditions. For more information, see [Device authentication fails](#device-authentication-fails). - -3. Ensure that the guest user's device is [Microsoft Entra hybrid joined](/entra/identity/devices/how-to-hybrid-join) in the home tenant. - -## Scenario 3: Conditional Access policy for approved client apps - -When a Conditional Access policy in the resource tenant is configured with the **Require approved client app** control and the policy is applied to guest users, the error can occur. - -This scenario isn't supported. To resolve the error, don't apply this control to guest users. - -## Device authentication fails - -Device authentication might fail under one of the following conditions: - -- When accessing using a browser in InPrivate or Incognito mode. -- When using unsupported browsers or devices, particularly on mobiles. -- When browser cookies are disabled. -- When a desktop or native application doesn't support device authentication or doesn't use Microsoft Authentication Broker. - - For more information about Microsoft Authentication Broker on different device platforms, see the following pages: - - - [Windows](/entra/identity/devices/concept-primary-refresh-token) - - [Android](/entra/identity-platform/msal-android-single-sign-on#sso-through-brokered-authentication) - - [iOS](/entra/msal/objc/single-sign-on-macos-ios#sso-through-authentication-broker-on-ios) - - [macOS, iOS and iPadOS](/entra/identity-platform/apple-sso-plugin) - -For more information on supported device platforms, see [Microsoft Entra Conditional Access - Device platforms](/entra/identity/conditional-access/concept-conditional-access-conditions#device-platforms). - -To verify whether the device claim is sent, review the sign-in logs for the failed or successful user in the resource tenant: - -1. Navigate to the sign-in logs for the user and locate the relevant failure or success event. -2. Under the **Device Info** section, check the **Join type** field. This field indicates the device claim that was passed. - -## AADSTS error code reference - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/entra/identity-platform/reference-error-codes). To investigate individual errors, search at https://login.microsoftonline.com/error. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts700003-device-object-not-found.md b/support/entra/entra-id/app-integration/error-code-aadsts700003-device-object-not-found.md deleted file mode 100644 index 7d0377fa366..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts700003-device-object-not-found.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Error AADSTS700003 - Device Object Was Not Found in the Tenant Directory -description: Provides a solution to an issue where you experience the AADSTS700003 error when you try to sign in to an Azure application that can be used with Microsoft Entra ID. -ms.service: entra-id -ms.date: 02/24/2025 -ms.reviewer: jutakata, willfid, bachoang, joaos, modawud, v-weizhu -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS700003 - Device object was not found in the tenant '\' directory - -This article discusses how to resolve the "AADSTS700003" error that occurs when you try to sign in to an application that's integrated into Microsoft Entra ID. - -## Symptoms - -When you try to sign in to an application that's integrated into Microsoft Entra ID, you receive an "AADSTS700003" error with one of the following error messages: - -- > Device object was not found in the tenant '\' directory. -- > Your organization has deleted this device. - -## Cause - -This issue occurs because the device object is deleted on your home tenant. When a device is deleted, the "Delete device" activity type is recorded in the [Microsoft Entra audit log](/entra/identity/monitoring-health/concept-audit-logs). In Microsoft Entra ID, there are three ways to register or join user devices: - -- Microsoft Entra registered -- Microsoft Entra joined -- Microsoft Entra hybrid joined - -Device registration or join creates a [device identity](/entra/identity/devices/overview). This device identity is used in scenarios such as [device-based Conditional Access policies](/entra/identity/conditional-access/concept-conditional-access-grant) and [Mobile Device Management with Microsoft Intune](/mem/endpoint-manager-overview). When you receive the AADSTS700003 error, the device object isn't found in the tenant. - -## Solution - -Engage the home tenant administrators to determine when and why your device object is deleted. Then, take the corresponding action depending on the device registration/join type, as shown in the following table: - -| Device join type | Action | -|--|--| -| Microsoft Entra registered | For Windows 10/11 Microsoft Entra registered devices, go to **Settings** > **Accounts** > **Access Work or School**. Select your work or school account on the screen. Select **Disconnect** to disconnect the device. Then, register the device to Microsoft Entra ID again.

For iOS and Android, you can use the Microsoft Authenticator application and select **Settings** > **Device Registration** > **Unregister device**. Then, register the device to Microsoft Entra ID again.

For macOS, you can use the Microsoft Intune Company Portal application to unenroll the device from management and remove any registration. Then, register the device to Microsoft Entra ID again.

For more information, see [Microsoft Entra register FAQ](/entra/identity/devices/faq#how-do-i-remove-a-microsoft-entra-registered-state-for-a-device-locally).| -| Microsoft Entra joined | Open a PowerShell console with the administrative right on the Windows device, and run the `dsregcmd /forcerecovery` command. Select **Sign in** to sign in with your Microsoft Entra ID account. | -| Microsoft Entra hybrid joined | Open a PowerShell console with the administrative right on the Windows device, and run the `dsregcmd /leave` command. Then, reboot the device and sign in to the device with your domain credential. | - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/azure/active-directory/develop/reference-error-codes). - -To investigate individual errors, go to [https://login.microsoftonline.com/error](https://login.microsoftonline.com/error). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/error-code-aadsts7000110-request-is-ambiguous.md b/support/entra/entra-id/app-integration/error-code-aadsts7000110-request-is-ambiguous.md deleted file mode 100644 index 9fa90893c2c..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts7000110-request-is-ambiguous.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Error AADSTS7000110 - Request is ambiguous, multiple application identifiers found -description: Learn how to resolve an AADSTS7000110 error that occurs when you try to sign in to an Azure app that can be used together with Microsoft Entra ID. -author: custorod -ms.author: custorod -ms.editor: v-jsitser -ms.reviewer: v-leedennis -ms.service: entra-id -ms.date: 01/11/2024 -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS7000110: Request is ambiguous, multiple application identifiers found - -This article discusses how to resolve the `AADSTS7000110` error that occurs when an application tries to obtain or refresh a token from Microsoft Entra ID. - -## Symptoms - -When you try to sign in to an Azure application that can be used together with Microsoft Entra ID, you receive the following `AADSTS7000110` error message: - -> Request is ambiguous, multiple application identifiers found. The client ID used to obtain the grant (e.g. refresh token or authorization code) might not match the client ID passed in this request or client credential. - -## Cause - -The application tried to do one of the following activities: - -- Redeem an OAuth2 authorization code to get an access token or a refresh token that has the wrong application ID (`client_id` parameter). - -- Use a refresh token that was initially issued to the application ID of a different caller. - -## Solution - -Use an OAuth2 authorization code or a refresh token that's from the same application ID (`client_id` parameter). - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/entra/identity-platform/reference-error-codes). - -To investigate individual errors, go to . - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts7000112-application-is-disabled.md b/support/entra/entra-id/app-integration/error-code-aadsts7000112-application-is-disabled.md deleted file mode 100644 index 102c17ac75b..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts7000112-application-is-disabled.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Error AADSTS7000112 - Application is disabled -description: Learn how to resolve the AADSTS7000112 error when you try to sign in to an Azure app that can be used with Microsoft Entra ID. -author: custorod -ms.author: custorod -ms.editor: v-jsitser -ms.reviewer: v-leedennis -ms.service: entra-id -ms.date: 01/11/2024 -ms.custom: sap:Issues Signing In to Applications ---- - -# Error AADSTS7000112 - Application is disabled - -This article discusses how to resolve the `AADSTS7000112` error that occurs when you try to sign in to an application that can be used together with Microsoft Entra ID. - -## Symptoms - -When you try to sign in to an Azure application that's integrated into Microsoft Entra ID, you receive the following `AADSTS7000112` error message: - -> Application '\'(\) disabled. - -## Cause - -The service principal object is disabled on the resource tenant. - -## Solution - -Work together with the resource tenant owners to determine why the service principal object is disabled. Then, use the following table to take the appropriate action. - -| Scenario | Action | -|--|--| -| The service principal is supposed to be disabled. | Don't do anything. Access is intentionally blocked. We don't expect or recommend that resource tenant administrators of first-party applications disable the respective service principal. Microsoft Services automatically provisions and manages the service principals. | -| The service principal isn't supposed to be disabled, or it was disabled mistakenly. | Ask the resource tenant owners to re-enable the service principal. One method to re-enable the service principal is to use PowerShell to set the `-AccountEnabled` parameter to `$true`. For more information, see the [Set-AzureADServicePrincipal](/powershell/module/azuread/set-azureadserviceprincipal#example-1-disable-the-account-of-a-service-principal) cmdlet reference. | - -## More information - -For a full list of authentication and authorization error codes, see [Microsoft Entra authentication and authorization error codes](/entra/identity-platform/reference-error-codes). - -To investigate individual errors, go to . - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/error-code-aadsts7500514-supported-type-saml-response-not-found.md b/support/entra/entra-id/app-integration/error-code-aadsts7500514-supported-type-saml-response-not-found.md deleted file mode 100644 index a65917d1d7f..00000000000 --- a/support/entra/entra-id/app-integration/error-code-aadsts7500514-supported-type-saml-response-not-found.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: AADSTS7500514 - A Supported Type of SAML Response was not Found with PingFederate -description: Describes error code `AADSTS7500514` that's returned if a federated account tries to authenticate by using Microsoft Entra ID. -ms.date: 04/17/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications, has-azure-ad-ps-ref -keywords: AADSTS50020 ---- - -# AADSTS7500514 - A supported type of SAML response was not found with PingFederate - -This article helps you troubleshoot error code `AADSTS7500514` that's returned if a PingFederate federated account tries to authenticate by using Microsoft Entra ID (formerly Azure Active Directory). - -## Symptoms - -When a federated account tries to authenticate by using Microsoft Entra ID from a Microsoft Authentication Library (MSAL)-based or Active Directory Authentication Library (ADAL)-based application, the sign-in fails. The following error message is displayed: - -```output -{ - error: "invalid_request", - error_description: "AADSTS7500514: A supported type of SAML response was not found. The supported response types are 'Response' (in XML namespace 'urn:oasis:names:tc:SAML:2.0:protocol') or 'Assertion' (in XML namespace 'urn:oasis:names:tc:SAML:2.0:assertion'). - .... - error_uri: "https://login.microsoftonline.com/error?code=7500514" -} -``` - -The error typically occurs in the following environment: - -- A federated account that uses [PingFederate](https://www.pingidentity.com/) as the identity provider. -- The identity provider is configured to issue a SAML 1.1 token by using the WS-Trust protocol. -- The application uses one of the following APIs for authentication: - - MSAL `AcquireTokenByUserNamePassword` method. - - ADAL `AcquireToken`(string resource, string clientId, UserCredential userCredential) method. - - Any PowerShell module that uses these MSAL or ADAL methods. - -## Cause - -Because [ADAL is now deprecated](/entra/identity/monitoring-health/recommendation-migrate-from-adal-to-msal), this article focuses on the MSAL. - -This issue occurs if the SAML response from PingFederate doesn't contain the SAML version or uses a format that MSAL can't recognize. Typically, this situation is caused by a misconfiguration on the PingFederate side for Microsoft Entra ID. - -### Root cause analysis: SAML token version detection - -When MASL authenticates a federated account, it determines whether the account is a managed account or a federated account. - -For managed accounts, MSAL uses the [Resource Owner Password Credentials grant flow](/entra/identity-platform/v2-oauth-ropc). For federated accounts, it uses the [SAML Assertion Grant flow](/azure/active-directory/develop/v2-saml-bearer-assertion). - -The SAML Assertion Grant flow has two steps: - -- The client application authenticates to the federated identity provider to obtain a SAML token. -- The client uses the obtained SAML token to get an OAuth 2.0 JWT token from Microsoft Entra ID. - -The authentication error typically occurs in step 1, in which the client application has to parse the SAML response from the identity provider to determine the version of the SAML token. MSAL looks for the following attributes in the identity provider's SAML response: - -- `saml:Assertion` -- `TokenType` - -The following is an example AD FS SAML response from the `/UserNameMixed` endpoint: - -- `saml:Assertion`: major version = 1, minor version = 1 -- `TokenType`: `urn:oasis:names:tc:SAML:1.0:assertion` - -:::image type="content" source="media/error-code-aadsts7500514-supported-type-saml-response-not-found/adfs-saml-response.png" alt-text="Screenshot of ADFS SAML Response." lightbox="media/error-code-aadsts7500514-supported-type-saml-response-not-found/adfs-saml-response.png"::: - -Example of a PingFederate SAML response (SAML Assertion Grant flow step 1): - -:::image type="content" source="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response.png" alt-text="Screenshot of PingFederate SAML Response for SAML Assertion Grant flow step 1." lightbox="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response.png"::: - -When you compare these responses, you find that PingFederate returns a different TokenType value (`http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1`) for the same SAML 1.1 token. However, MSAL doesn't support any TokenType value other than `urn:oasis:names:tc:SAML:1.0:assertion`. - -If the identity provider returns a different or unexpected value in the SAML response, MSAL might incorrectly interpret the token as SAML 2.0. In this case, it uses the corresponding `grant_type` value during step 2 of the SAML Assertion Grant flow. - -Example of the request sent from MSAL application by using PingFederate (SAML Assertion Grant flow step 2): - -:::image type="content" source="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-2.png" alt-text="Screenshot of request sent from MSAL application with PingFederate in SAML Assertion Grant flow step 2." lightbox="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-2.png"::: - -Example of the request that's sent from the MSAL application by using AD FS: - -:::image type="content" source="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-3.png" alt-text="Screenshot of request sent from MSAL application by using AD FS in SAML Assertion Grant flow step 2." lightbox="media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-3.png"::: - -In this step, the value of the `grant_type` parameter must align with the actual version of the SAML token. One of the following values is used by the MSAL application: - -- urn:ietf:params:oauth:grant-type:saml2-bearer - for SAML 2.0 tokens -- urn:ietf:params:oauth:grant-type:saml1_1-bearer - for SAML 1.1 tokens - -In the PingFederate example, MSAL uses the `saml2-bearer` as the `grant_type` based on its misinterpretation of the SAML version. This causes a version mismatch between the `grant_type` parameter and the SAML token that's included in the assertion that causes the authentication error. - -## Solution - -To resolve this issue, make sure that PingFederate is configured to align with Microsoft Entra ID requirements. For step-by-step instructions, review the following articles: - -- [Creating a connection to Microsoft Entra ID](https://docs.pingidentity.com/integrations/azure/azure_ad_and_office_365_integration_guide/pf_azuread_office365_integration_creating_a_connection_to_azure_active_directory.html). - - During Microsoft Entra ID connection setup, pay special attention to the settings in the following steps: - - 1. Configure the connection protocols. - 2. On the **Connection Template** tab, select **Do not use a template for this connection**, and then select **Next**. - 3. On the **Connection Type** tab, select **Browser SSO Profiles**. - 4. In the Protocol list, select **WS-Federation**. - 5. In the **WS-Federation Token Type** list, select **SAML 1.1**. - 6. If you want to support active federation, select the **WS-Trust STS** checkbox. - -- [Configuring WS-Trust STS](https://docs.pingidentity.com/integrations/azure/azure_ad_and_office_365_integration_guide/pf_azuread_office365_integration_configuring_ws_trust_sts.html) - - When you configure WS-Trust STS, make sure that you select **SAML 1.1 for Office 365** as the Default Token Type. - -[!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)] -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/fiddler-capture-ssl-traffic.md b/support/entra/entra-id/app-integration/fiddler-capture-ssl-traffic.md deleted file mode 100644 index 3a6d2968925..00000000000 --- a/support/entra/entra-id/app-integration/fiddler-capture-ssl-traffic.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Capture SSL Traffic with Fiddler -description: Introduces how to make Fiddler to capture SSL traffic in two specific scenarios. -ms.service: entra-id -ms.date: 04/15/2025 -ms.reviewer: bachoang, v-weizhu -ms.topic: how-to -ms.custom: sap:Enterprise Applications ---- -# Capture SSL traffic with Fiddler - -This article provides instructions to use Fiddler to capture Secure Sockets Layer (SSL) traffic to troubleshoot Microsoft Entra apps. - -## Scenario 1: Capture Node.js web traffic with Fiddler - -To capture Node.js web application traffic using Fiddler, you need to proxy Node.js requests through Fiddler. The default proxy is 127.0.0.1:8888. To do so, before running the `npm start` command to start the Node.js server, enable the proxy settings by running the following commands: - -```nodejs -set https_proxy=http://127.0.0.1:8888 -set http_proxy=http://127.0.0.1:8888 -set NODE_TLS_REJECT_UNAUTHORIZED=0 -``` - -> [!NOTE] -> To find out which port Fiddler is listening on, select **Tools** > **Options** > **Connections** from the Fiddler menu. - -## Scenario 2: Capture the Azure Key Vault secrets client (from Azure SDK for .NET) with Fiddler - -To capture Azure Key Vault traffic using Fiddler, set Fiddler as a proxy by setting the `http_proxy` and `https_proxy` environment variables in the application code as follows: - -```csharp - -using Azure.Identity; -using Azure.Security.KeyVault.Secrets; -... -// add these lines in your method to call Azure Key Vault -Environment.SetEnvironmentVariable("HTTP_PROXY", "http://127.0.0.1:8888"); -Environment.SetEnvironmentVariable("HTTPS_PROXY", "http://127.0.0.1:8888"); - -var client = new SecretClient(new Uri(keyVaultUrl), credential); -KeyVaultSecret result = client.GetSecret("MySecret"); -``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/filter-fiddler-traffic-using-domain-name-client-process.md b/support/entra/entra-id/app-integration/filter-fiddler-traffic-using-domain-name-client-process.md deleted file mode 100644 index 51497935a76..00000000000 --- a/support/entra/entra-id/app-integration/filter-fiddler-traffic-using-domain-name-client-process.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -title: Filter Fiddler Traffic Using Domain Names and Client Processes -description: Introduces how to filter traffic that's captured by Fiddler using domain/host names owned by Microsoft Entra and client processes. -ms.service: entra-id -ms.topic: how-to -ms.date: 04/08/2025 -ms.reviewer: bachoang, v-weizhu -ms.custom: sap:Enterprise Applications ---- -# Filter Fiddler traffic using domain names and client processes - -This article explains how to filter traffic that's captured by Fiddler using domain/host names owned by Microsoft Entra and client processes. - -## Prerequisites - -Before filtering, ensure that Fiddler is configured to capture traffic for all processes. In the lower-left corner of the Fiddler window, you can select **All processes** to change the selection. - - :::image type="content" source="media/filter-fiddler-traffic-using-domain-name-client-process/all-processes.png" alt-text="Screenshot that shows the 'All processes' button."::: - -## Filter traffic using Fiddler's built-in filter feature - -To filter traffic using Fiddler's built-in filter feature, follow these steps: - -1. Open Fiddler and navigate to the right panel. -2. Select the **Filters** tab, and then select the **Use Filters** checkbox. -3. Under the **Hosts** section, select **Show only the following Hosts**. -4. In the text box, enter the host name list you want to filter on, separated by semicolons, for example, `localhost;login.microsoftonline.com;graph.microsoft.com`. - - > [!NOTE] - > This text box will display a yellow background while editing the list, indicating unsaved changes. -5. Select the **Actions** button to save the list. The background color will change to white, confirming the list is saved. - - :::image type="content" source="media/filter-fiddler-traffic-using-domain-name-client-process/show-only-the-following-hosts.png" alt-text="Screenshot that shows how to filter traffic based on host names."::: - -Under the **Client Process** section, you can also select a specific process to filter on. This is particularly useful for filtering a standalone application. It might be less effective for capturing browser traffic because multiple processes with the same name can make it difficult to identify the correct one. - -## Filter traffic using JavaScript code in the OnBeforeRequest function - -> [!NOTE] -> This option is used especially for browser-based applications. - -1. In Fiddler, go to **Rules** > **Customize Rules**. This action will open the **CustomRules.js** file in the FiddlerScript editor. -2. Locate the **OnBeforeRequest** function in the FiddlerScript editor. -3. Insert the following JavaScript code at the beginning of the function: - - ```javascript - // begin filter - - // set this to false to disable filter and true to enable filter - var filterOn = true; - - if (filterOn) - { - // hide all requests by default - oSession["ui-hide"] = "true"; - - // list of domain names to filter on - var host = ["localhost", "login.microsoftonline.com", "graph.microsoft.com"]; - - // list of processes to filter on - var processlist = ["chrome", "microsoftedgecp", "iisexpress", "powershell"]; - - for (var j = 0; j < processlist.length; j++) - { - if (oSession.LocalProcess.Contains(processlist[j])) - { - for (var i = 0; i < host.length; i++) - { - if (oSession.HostnameIs(host[i])) - { - oSession["ui-hide"] = null; - } - } - } - } - } - - // end filter - ``` - - :::image type="content" source="media/filter-fiddler-traffic-using-domain-name-client-process/add-javascript-code-onbeforerequest-function.png" alt-text="Screenshot that shows the JavaScript code added in the OnBeforeRequest function." lightbox="media/filter-fiddler-traffic-using-domain-name-client-process/add-javascript-code-onbeforerequest-function.png"::: - - Here are the explanations of some variables in the JavaScript code: - - - `filterOn`: Set it to `true` to enable the filter and `false` to disable it. - - `host`: Contains the list of domain names to filter on. - - `processlist`: Contains the list of process names to filter on. - -4. Save the changes to the **CustomRules.js** file. - -## References - -- [Modifying a Request or Response](http://docs.telerik.com/fiddler/KnowledgeBase/FiddlerScript/ModifyRequestOrResponse) -- [FiddlerScript Cookbook](http://fiddlerbook.com/Fiddler/dev/ScriptSamples.asp) -- [Understanding FiddlerScript](https://www.telerik.com/blogs/understanding-fiddlerscript) - -[!INCLUDE [Azure Help Support](../../../includes/third-party-disclaimer.md)] -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token.md b/support/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token.md deleted file mode 100644 index 15572c04762..00000000000 --- a/support/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token.md +++ /dev/null @@ -1,422 +0,0 @@ ---- -title: Get Signed-in User Group List from a Group Overage Claim -description: Provides a sample project to introduce how to get the signed-in user group list when a group overage claim is displayed in access tokens. -ms.topic: how-to -ms.reviewer: daga, v-weizhu -ms.service: entra-id -ms.date: 03/14/2025 -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# How to get the signed-in user group list when a group overage claim is displayed in access tokens - -When you configure the `groups` claim in an access token for your application, Microsoft Entra ID has a maximum number of groups that can be returned in the access token. When the limit is exceeded, Azure provides a group overage claim, which is a URL that can be used to get the full group list for the currently signed-in user. This URL uses the Microsoft Graph endpoint. For more information about the `groups` claim, see [Access tokens in the Microsoft identity platform](/entra/identity-platform/access-tokens). - -For JSON web tokens (JWT), Azure limits the number of groups that can be present in the token to 200. When requesting an access token for a resource that has the `groups` claim configured, if you're a member of more than 200 groups, you'll get a group overage claim instead of getting the actual groups. - -This article introduces how to get the actual user group list from a group overage claim by using a sample project. - -## Configure the groups claim for your application - -You can configure the `groups` claim for your application by using the optional claims. For more information, see [Configure and manage optional claims in ID tokens, access tokens, and SAML tokens](/entra/identity-platform/optional-claims). - -If the application is a first-party app (Microsoft app), you can't configure the `groups` claim. You can only configure it with your own app registration. If you want to configure the `groups` claim for a client application, you must configure it in an ID token. - -## Download the sample project - -Download the sample project [MSAL.Net_GroupOveragesClaim](https://github.com/RayGHeld/MSAL.Net_GroupOveragesClaim). It shows how to get the group list from a group overage claim. - -## Before running the sample project - -- Configure an app registration for the sample project. - - The sample project will perform both the public client flow and the confidential client flow, so you need to configure a web redirect (for the public client flow) and a client secret (for the confidential client flow). Because the confidential client must go to the `users` endpoint and look up the groups based on the user ID, which can be obtained from the initial sign-in token, the confidential client version needs the Microsoft Graph application permission of `Group.Read.All`. The public client just goes to the `me` endpoint since there's a user context. - -- Configure the sample project to work with your tenant by updating the **appsettings.json** file with the appropriate values: - - ```json - { - "Azure": { - "ClientId": "{client_id}", - "TenantId": "{tenant_id}", - "CallbackPath": "http://localhost", - "ClientSecret": "{client_secret}", - "AppScopes": [ "https://database.windows.net/.default" ], - "GraphScopes": [ "User.Read" ] - } - } - ``` - - Here are explanations of the settings in the **appsettings.json** file: - - - `AppScopes` - - You must have a scope for which the `groups` claim has been configured. - - Typically, this is an API in your tenant. But in this case, adding Azure SQL Database with the **user_impersonation** permission works for this scenario. The scope you have added works for that API. This is because the `groups` claim has been configured on that API. - - :::image type="content" source="media/get-signed-in-users-groups-in-access-token/add-azure-sql-database.png" alt-text="Screenshot that shows the Azure SQL Database API."::: - - - `GraphScopes` - - Add the application permissions **Group.Read.All** (needed to get the group display name) and **User.Read.All** (needed to get the group list using the client credentials flow). You must provide admin consent for those permissions. The delegated permission **User.Read** should already be there. If not, add it. - - :::image type="content" source="media/get-signed-in-users-groups-in-access-token/add-application-permissions.png" alt-text="Screenshot that shows the added application permissions."::: - - - Once the app registration for this sample project is configured, add the client ID (application ID), client secret, and tenant ID into the **appsettings.json** file. - -- Run PowerShell scripts in the **Create_TestGroup.ps1.txt** file to create test groups (if needed). - - The sample project has a text file called **Create_TestGroup.ps1.txt**. To run PowerShell scripts in this file, remove the .txt extension. Before running it, you need an object ID of a user to add to the test groups. You must be in a directory role that can create groups and add users to the groups. The sample project will create 255 groups in the format of `TEST_0001`, `TEST_0002`, and so on. The object ID that you provide for each group will be added. At the end of the script, it will sign you into Azure, run the command to create the test groups, and then sign you out. - - > [!NOTE] - > There's a sample cleanup method that is commented out on line 53: - > - > ```PowerShell - > Connect-AzureAD - > Create-TestGroups -deleteIfExists $false - > #Delete-TestGroups - > Disconnect-AzureAD - > ``` - -## Get the full user groups list using the group overage claim - -1. Run the sample application. -2. Sign in to the application. - - Authentication occurs in a browser because the sample application is a .NET console application. -3. After signing in, close the browser and you'll be returned to the console application. -4. After the access token is presented in the console window, copy the access token to the clipboard and paste it into https://jwt.ms to view the encoded token. It's just a user token. - - If the user is a member of too many groups, the console window will display the original group overage claim and the new group overage claim for that token. The new group overage claim will be used in the .NET HTTP client request rather than the Graph .NET SDK request. - - :::image type="content" source="media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png" alt-text="Screenshot of the methods used to get the full list of the user groups." lightbox="media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png"::: - -5. Select the access token type you want to get for Microsoft Graph. You can get an access token by using a user token for the currently signed-in user (refresh token flow) or an application token using the client credentials grant flow. -6. Select the `.NET HTTP Request` or the `Graph .NET SDK` to get the full list of the user groups. - - :::image type="content" source="media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png" alt-text="Screenshot of the methods used to get the full list of the user groups." lightbox="media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png"::: - - The groups will appear in the console window: - - :::image type="content" source="media/get-signed-in-users-groups-in-access-token/groups-list.png" alt-text="Screenshot of the full list of the user groups."::: - -## About the code - -### Get_GroupsOverageClaimURL method - -The sample project uses MSAL.NET (`Microsoft.Identity.Client`) to authenticate users and obtain access tokens. `System.Net.Http` is used for the HTTP client, and Microsoft.Graph SDK is used for the graph client. To parse the JSON file, `System.Text.Json` is used. To get the claims from the token, `System.IdentityModel.Tokens.Jwt` is used. The `JwtSecurityToken` provider is used to retrieve the group overage claim in the token. - -If the token contains the claims `claim_names` and `claim_sources`, it indicates the presence of a group overage claim within the token. In this case, use the user ID (oid) and the two claims to construct the URL to the group list and output the original value in the console window. If either of the two claim values doesn't exist, the `try/catch` block will handle the error and return a `string.empty` value. This indicates that there's no group overage claim in the token. - -```csharp -/// - /// Looks for a group overage claim in an access token and returns the value if found. - /// - /// - /// - private static string Get_GroupsOverageClaimURL(string accessToken) - { - JwtSecurityToken token = new JwtSecurityTokenHandler().ReadJwtToken(accessToken); - string claim = string.Empty; - string sources = string.Empty; - string originalUrl = string.Empty; - string newUrl = string.Empty; - - try - { - // use the user id in the new graph URL since the old overage link is for Azure AD Graph which is being deprecated. - userId = token.Claims.First(c => c.Type == "oid").Value; - - // getting the claim name to properly parse from the claim sources but the next 3 lines of code are not needed, - // just for demonstration purposes only so you can see the original value that was used in the token. - claim = token.Claims.First(c => c.Type == "_claim_names").Value; - sources = token.Claims.First(c => c.Type == "_claim_sources").Value; - originalUrl = sources.Split("{\"" + claim.Split("{\"groups\":\"")[1].Replace("}","").Replace("\"","") + "\":{\"endpoint\":\"")[1].Replace("}","").Replace("\"", ""); - - // make sure the endpoint is specific for your tenant -- .gov for example for gov tenants, etc. - newUrl = $"https://graph.microsoft.com/v1.0/users/{userId}/memberOf?$orderby=displayName&$count=true"; - - Console.WriteLine($"Original Overage URL: {originalUrl}"); - //Console.WriteLine($"New URL: {newUrl}"); - - - } catch { - // no need to do anything because the claim does not exist - } - - return newUrl; - } -``` - -### Program.cs file - -In this file, there's a public client application configuration for user sign-in and getting access tokens, and a confidential client application for application sign-in and getting access tokens (the client credentials grant flow). `ManualTokenProvider` is used for the Graph service client to pass an access token to the service instead of having Graph obtain it. - -There's also an **appsettings.json** file and a class (**AzureConfig.cs**) to store those settings at runtime. The public static property `AzureSettings` retrieves settings from the configuration file using a configuration builder, similar to ASP.NET Core applications. This feature must be added as it's not native to a console application. - -```csharp -static AzureConfig _config = null; - public static AzureConfig AzureSettings - { - get - { - // Only load this when the app starts. - // To reload, you will have to set the variable _config to null again before calling this property. - if (_config == null) - { - _config = new AzureConfig(); - IConfiguration builder = new ConfigurationBuilder() - .SetBasePath(System.IO.Directory.GetCurrentDirectory()) - .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) - .Build(); - - ConfigurationBinder.Bind(builder.GetSection("Azure"), _config); - } - - return _config; - } - } -``` - -### Authentication provider - -For the `Authentication` provider for the Graph service client, the sample project uses a custom manual token provider to set the access token for the client that has already obtained access tokens using MSAL. - -```csharp -using Microsoft.Graph; - -using System; -using System.Collections.Generic; -using System.Net.Http; -using System.Net.Http.Headers; -using System.Text; -using System.Threading.Tasks; - -namespace MSAL.Net_GroupOveragesClaim.Authentication -{ - class ManualTokenProvider : IAuthenticationProvider - { - string _accessToken; - - public ManualTokenProvider ( string accessToken) - { - _accessToken = accessToken; - } - - async Task IAuthenticationProvider.AuthenticateRequestAsync(HttpRequestMessage request) - { - request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", _accessToken); - request.Headers.Add("ConsistencyLevel", "eventual"); - } - } -} -``` - -### Get_Groups_HTTP_Method - -This method calls the `Graph_Request_viaHTTP` method to get the list of groups and then displays that list in the console window. - -```csharp -/// - /// Entry point to make the request to Microsoft graph using the .Net HTTP Client - /// - /// - /// - private static async Task Get_Groups_HTTP_Method(string graphToken, string url) - { - List groupList = new List(); - - groupList = await Graph_Request_viaHTTP(graphToken, url); - foreach (Group g in groupList) - { - Console.WriteLine($"Group Id: {g.Id} : Display Name: {g.DisplayName}"); - } - } -``` - -```csharp -/// - /// Calls Microsoft Graph via a HTTP request. Handles paging in the request - /// - /// - /// List of Microsoft Graph Groups - private static async Task> Graph_Request_viaHTTP(string user_access_token, string url) - { - string json = string.Empty; - //string url = "https://graph.microsoft.com/v1.0/me/memberOf?$orderby=displayName&$count=true"; - List groups = new List(); - - // todo: check for the count parameter in the request and add if missing - - /* - * refer to this documentation for usage of the http client in .net - * https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=net-5.0 - * - */ - - // add the bearer token to the authorization header for this request - _httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue( "Bearer", user_access_token); - - // adding the consistencylevel header value if there is a $count parameter in the request as this is needed to get a count - // this only needs to be done one time so only add it if it does not exist already. It is case sensitive as well. - // if this value is not added to the header, the results will not sort properly -- if that even matters for your scenario - if(url.Contains("&$count", StringComparison.OrdinalIgnoreCase)) - { - if (!_httpClient.DefaultRequestHeaders.Contains("ConsistencyLevel")) - { - _httpClient.DefaultRequestHeaders.Add("ConsistencyLevel", "eventual"); - } - } - - // while loop to handle paging - while(url != string.Empty) - { - HttpResponseMessage response = await _httpClient.GetAsync(new Uri(url)); - url = string.Empty; // clear now -- repopulate if there is a nextlink value. - - if (response.IsSuccessStatusCode) - { - json = await response.Content.ReadAsStringAsync(); - - // Console.WriteLine(json); - - using (JsonDocument document = JsonDocument.Parse(json)) - { - JsonElement root = document.RootElement; - // check for the nextLink property to see if there is paging that is occuring for our while loop - if (root.TryGetProperty("@odata.nextLink", out JsonElement nextPage)) - { - url = nextPage.GetString(); - } - JsonElement valueElement = root.GetProperty("value"); // the values - - // loop through each value in the value array - foreach (JsonElement value in valueElement.EnumerateArray()) - { - if (value.TryGetProperty("@odata.type", out JsonElement objtype)) - { - // only getting groups -- roles will show up in this graph query as well. - // If you want those too, then remove this if filter check - if (objtype.GetString() == "#microsoft.graph.group") - { - Group g = new Group(); - - // specifically get each property you want here and populate it in our new group object - if (value.TryGetProperty("id", out JsonElement id)) { g.Id = id.GetString(); } - if (value.TryGetProperty("displayName", out JsonElement displayName)) { g.DisplayName = displayName.GetString(); } - - groups.Add(g); - } - } - } - } - } else - { - Console.WriteLine($"Error making graph request:\n{response.ToString()}"); - } - } // end while loop - - return groups; - } -``` - -### Get_Groups_GraphSDK_Method - -Similarly, the Graph SDK has an entry method, `Get_Groups_GraphSDK_Method`. This method calls `Get_GroupList_GraphSDK` to get the list of groups and then displays it in the console window. - -```csharp -/// - /// Entry point to make the request to Microsoft Graph using the Graph SDK and outputs the list to the console. - /// - /// - /// - private static async Task Get_Groups_GraphSDK_Method(string graphToken, bool me_endpoint) - { - List groupList = new List(); - - groupList = await Get_GroupList_GraphSDK(graphToken, me_endpoint); - foreach (Group g in groupList) - { - Console.WriteLine($"Group Id: {g.Id} : Display Name: {g.DisplayName}"); - } - } -``` - -### Get_GroupList_GraphSDK method - -This method determines whether to use the `me` endpoint or the `users` endpoint to get the group list. If you use the client credentials grant flow to get the access token for Microsoft Graph, use the `me` endpoint. If not (for example, a delegated flow is used for the access token), use the `users` endpoint. Regardless of the method used, the code handles paging because, by default, only 100 records per page are returned. Paging is determined via the `@odata.nextLink` value. If there's a value for that property, the full URL is called for the next page of data. For more information about paging, see [Paging Microsoft Graph data in your app](/graph/paging). - -```csharp -/// - /// Calls the Me.MemberOf endpoint in Microsoft Graph and handles paging - /// - /// - /// List of Microsoft Graph Groups - private static async Task> Get_GroupList_GraphSDK(string graphToken, bool use_me_endpoint) - { - - GraphServiceClient client; - - Authentication.ManualTokenProvider authProvider = new Authentication.ManualTokenProvider(graphToken); - - client = new GraphServiceClient(authProvider); - IUserMemberOfCollectionWithReferencesPage membershipPage = null; - - HeaderOption option = new HeaderOption("ConsistencyLevel","eventual"); - - if (use_me_endpoint) - { - if (!client.Me.MemberOf.Request().Headers.Contains(option)) - { - client.Me.MemberOf.Request().Headers.Add(option); - } - - membershipPage = await client.Me.MemberOf - .Request() - .OrderBy("displayName&$count=true") // todo: find the right way to add the generic query string value for count - .GetAsync(); - } else - { - if (!client.Users[userId].MemberOf.Request().Headers.Contains(option)) - { - client.Users[userId].MemberOf.Request().Headers.Add(option); - } - - membershipPage = await client.Users[userId].MemberOf - .Request() - .OrderBy("displayName&$count=true") - .GetAsync(); - } - - List allItems = new List(); - - if(membershipPage != null) - { - foreach(DirectoryObject o in membershipPage) - { - if(o is Group) - { - allItems.Add((Group)o); - } - } - - while (membershipPage.AdditionalData.ContainsKey("@odata.nextLink") && membershipPage.AdditionalData["@odata.nextLink"].ToString() != string.Empty) - { - membershipPage = await membershipPage.NextPageRequest.GetAsync(); - foreach (DirectoryObject o in membershipPage) - { - if (o is Group) - { - allItems.Add(o as Group); - } - } - } - - } - - return allItems; - - } -``` -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] - diff --git a/support/entra/entra-id/app-integration/graph-api-error-handling-invoke-restmethod.md b/support/entra/entra-id/app-integration/graph-api-error-handling-invoke-restmethod.md deleted file mode 100644 index a90177c8e8d..00000000000 --- a/support/entra/entra-id/app-integration/graph-api-error-handling-invoke-restmethod.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Handling errors in Microsoft Graph API requests with invoke-restmethod -description: This article provides a code sample to simulate a handling error that occurs when you make requests to the Microsoft Graph API by using the Invoke-RestMethod cmdlet in PowerShell. -ms.date: 02/18/2024 -author: genlin -ms.author: raheld -ms.service: entra-id -ms.topic: overview -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Microsoft Graph Users, Groups, and Entra APIs ---- -# Handling errors in Microsoft Graph API Requests with Invoke-RestMethod - -This article provides a code sample that demonstrates how to handle errors and implement retry logic when you make requests to the Microsoft Graph API by using the `Invoke-RestMethod` cmdlet in PowerShell. - -## Prerequisites - -- An Azure app registration with a client secret -- The `user.read.all` permission for Microsoft.Graph for the Azure app. For more information, see [List users](/graph/api/user-get?view=graph-rest-1.0&tabs=http&preserve-view=true). - -## Code sample - -To demonstrate the retry logic, this sample tries to query the `signInActivity` data for guest users. When you run this code, you can expect to receive a "403" error. - -- **Get-AccessTokenCC** This function requests an access token from Microsoft Entra ID (formerly Azure Active Directory). The token will be used to authenticate API requests to Microsoft Graph. You have to provide values for the `$clientSecret`, `$clientId`, and `$tenantId` variables of your Azure registration app. -- **Get-GraphQueryOutput ($Uri)** This function makes a request to the Microsoft Graph API to retrieve data. It also handles paging. The function retries the request if a "403" error is generated. - -``` powershell -Function Get-AccessTokenCC - -{ - $clientSecret = '' - $clientId = '' - $tenantId = '' - # Construct URI - $uri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" - # Construct Body - $body = @{ - client_id = $clientId - client_secret = $clientSecret - scope = 'https://graph.microsoft.com/.default' - grant_type = 'client_credentials' - } - # Get OAuth 2.0 Token - $tokenRequest = Invoke-WebRequest -Method Post -Uri $uri -ContentType 'application/x-www-form-urlencoded' -Body $body -UseBasicParsing - # Access Token - $token = ($tokenRequest.Content | ConvertFrom-Json).access_token - #$token = "Junk" #uncomment this line to cause a 401 error -- you can set that status in the error handler to test the pause and retry - #Write-Host "access_token = $token" - return $token -} - -Function Get-GraphQueryOutput ($Uri) -{ - write-host "uri = $Uri" - write-host "token = $token" - - $retryCount = 0 - $maxRetries = 3 - $pauseDuration = 2 - - $allRecords = @() - while ($Uri -ne $null){ - Write-Host $Uri - try { - # todo: verify that the bearer token is still good -- hasn't expired yet -- if it has, then get a new token before making the request - $result=Invoke-RestMethod -Method Get -Uri $Uri -ContentType 'application/json' -Headers @{Authorization = "Bearer $token"} - - Write-Host $result - - if($query.'@odata.nextLink'){ - # set the url to get the next page of records. For more information about paging, see https://docs.microsoft.com/graph/paging - $Uri = $query.'@odata.nextLink' - } else { - $Uri = $null - } - - } catch { - Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value__ - Write-Host "StatusDescription:" $_.Exception.Response.StatusDescription - - if($_.ErrorDetails.Message){ - Write-Host "Inner Error: $_.ErrorDetails.Message" - } - - # check for a specific error so that we can retry the request otherwise, set the url to null so that we fall out of the loop - if($_.Exception.Response.StatusCode.value__ -eq 403 ){ - # just ignore, leave the url the same to retry but pause first - if($retryCount -ge $maxRetries){ - # not going to retry again - $Uri = $null - Write-Host 'Not going to retry...' - } else { - $retryCount += 1 - Write-Host "Retry attempt $retryCount after a $pauseDuration second pause..." - Start-Sleep -Seconds $pauseDuration - } - - } else { - # not going to retry -- set the url to null to fall back out of the while loop - $Uri = $null - } - } - } - - $output = $allRecords | ConvertTo-Json - -if ($result.PSObject.Properties.Name -contains "value") { - return $result.value -} else { - return $result -} -} - -# Graph API URIs -$uri = 'https://graph.microsoft.com/v1.0/users?$filter=userType eq ''Guest''&$select=displayName,UserprincipalName,userType,identities,signInActivity' - -# Pull Data -$token = Get-AccessTokenCC -Get-GraphQueryOutput -Uri $uri|out-file c:\\temp\\output.json - -``` - -## Capturing a specific header - -For advanced scenarios, such as capturing specific header values such as `Retry-After` during throttling responses (HTTP 429), use: - -```powershell -$retryAfterValue = $_.Exception.Response.Headers["Retry-After"] -``` -To handle the "429 - too many requests" error, see [Microsoft Graph throttling guidance](/graph/throttling). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] - diff --git a/support/entra/entra-id/app-integration/idx10501-token-signature-validation-error.md b/support/entra/entra-id/app-integration/idx10501-token-signature-validation-error.md deleted file mode 100644 index c46e16d2293..00000000000 --- a/support/entra/entra-id/app-integration/idx10501-token-signature-validation-error.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: How to Resolve Token Signature Validation Errors in Microsoft Entra ID Applications -description: This article discusses how to resolve IDX10501 Signature Validation Errors in Microsoft Entra ID applications. -ms.date: 06/03/2025 -author: genlin -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# IDX10501 Signature Validation Errors in Microsoft Entra ID applications - -If a client application obtains an access token from Microsoft Entra ID and sends it to a resource (API) application, the resource application must validate the token. It validates by using the public key from the certificate that was used to sign the token. If the application can't find the correct key identifier (kid), it might generate an error message that resembles the following message: - -> IDX10501: Signature validation failed. Unable to match 'kid' - -To resolve token signature validation errors such as "IDX10501," make sure that your application is configured to retrieve the correct public key from Microsoft Entra ID. Use the appropriate key discovery or metadata endpoint, based on the application type and signing configuration. - -## For OAuth2 resource applications - -The following steps demonstrate how an OAuth2 application validates a token that's issued from Microsoft Entra ID: - -1. Use an API client to perform an [Authorization Code flow](/entra/identity-platform/v2-oauth2-auth-code-flow) and acquire a token. -1. Decode the token by using [jwt.ms](https://jwt.ms), and note the `kid`. -1. Depending on your Microsoft Entra ID application version, use the token as a bearer token to call one of the following keys discovery endpoints. The API returns three keys. The `kid` that you obtained in step 2 should match one of the keys that are returned by the keys discovery endpoint. - - For v1.0 applications, use: - - ```http - https://login.microsoftonline.com/common/discovery/keys - ``` - - For v2.0 applications, use: - - ```http - https://login.microsoftonline.com/common/discovery/v2.0/keys - ``` - -## For SAML resource applications - -For SAML, Microsoft Entra ID uses the app-specific certificate to sign tokens. To retrieve the correct public key, follow these steps: - -1. Use the API client to acquire an access token for the SAML app. -2. Use the following keys discovery endpoint, replacing `` and `` with your values. - - ```http - https://login.microsoftonline.com//discovery/keys?appid= - ``` -3. If your app uses custom signing keys that use a [claims-mapping policy](/entra/identity-platform/saml-claims-customization), you must append an `appid` query parameter that contains the app client ID. This step is necessary to retrieve a `jwks_uri` that points to the app’s specific signing key information. For example: - - ```http - https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration?appid=6731de76-14a6-49ae-97bc-6eba6914391e - ``` - -### Middleware configuration examples - -To avoid signature validation errors, configure your middleware to use the correct metadata endpoint. - -**OpenID Connect Middleware (OWIN)** - -```csharp -app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - ClientId = clientId, - Authority = authority, - RedirectUri = redirectUri, - MetadataAddress = "https://login.microsoftonline.com//.well-known/openid-configuration?appid=", - PostLogoutRedirectUri = redirectUri, - }); -``` - -**JWT Bearer Authentication Middleware** - -```csharp -app.UseJwtBearerAuthentication(new JwtBearerOptions -{ - Audience = "...", - Authority = "...", - MetadataAddress = "https://login.microsoftonline.com//.well-known/openid-configuration?appid=", - TokenValidationParameters = new TokenValidationParameters - { - // Additional validation parameters - } -}); -``` - -**Microsoft.Identity.Web (Web App)** - -```csharp -services.AddMicrosoftIdentityWebAppAuthentication(Configuration) - .EnableTokenAcquisitionToCallDownstreamApi() - .AddInMemoryTokenCaches(); - -services.Configure(options => -{ - options.MetadataAddress = "https://login.microsoftonline.com//.well-known/openid-configuration?appid="; -}); -``` - -**Microsoft.Identity.Web (Web API)** - -```csharp -services.AddMicrosoftIdentityWebApiAuthentication(Configuration); - -services.Configure(JwtBearerDefaults.AuthenticationScheme, options => -{ - options.MetadataAddress = "https://login.microsoftonline.com//.well-known/openid-configuration?appid="; -}); -``` - -## Next steps - -To learn more about Microsoft the Entra ID signing keys rollover, see [Access tokens in the Microsoft identity platform](/entra/identity-platform/access-tokens). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/media/401-unauthorized-aspnet-core-web-api/wrong-token.png b/support/entra/entra-id/app-integration/media/401-unauthorized-aspnet-core-web-api/wrong-token.png deleted file mode 100644 index 489c1c8ef24..00000000000 Binary files a/support/entra/entra-id/app-integration/media/401-unauthorized-aspnet-core-web-api/wrong-token.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/404-not-found-error-manage-objects-microsoft-graph/404-not-found-error-diagram.png b/support/entra/entra-id/app-integration/media/404-not-found-error-manage-objects-microsoft-graph/404-not-found-error-diagram.png deleted file mode 100644 index 6069340a509..00000000000 Binary files a/support/entra/entra-id/app-integration/media/404-not-found-error-manage-objects-microsoft-graph/404-not-found-error-diagram.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-reg-platform-config.png b/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-reg-platform-config.png deleted file mode 100644 index d94f4a4ee6a..00000000000 Binary files a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-reg-platform-config.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-registrations-configure-android-app.png b/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-registrations-configure-android-app.png deleted file mode 100644 index 2ac62e6fe7a..00000000000 Binary files a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/app-registrations-configure-android-app.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/google-play-console-app-signing.png b/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/google-play-console-app-signing.png deleted file mode 100644 index ce8e9e36b49..00000000000 Binary files a/support/entra/entra-id/app-integration/media/android-app-authentication-fails-after-published-to-google-play-store/google-play-console-app-signing.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/application-permissions-power-bi-api.png b/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/application-permissions-power-bi-api.png deleted file mode 100644 index 3b6e83e7872..00000000000 Binary files a/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/application-permissions-power-bi-api.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/delegated-permissions-power-bi-api.png b/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/delegated-permissions-power-bi-api.png deleted file mode 100644 index f4d7bb46ff2..00000000000 Binary files a/support/entra/entra-id/app-integration/media/application-delegated-permission-access-tokens-identity-platform/delegated-permissions-power-bi-api.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/asp-dot-net-application-infinite-sign-in-loop/openidconnet-nonce-cookies.png b/support/entra/entra-id/app-integration/media/asp-dot-net-application-infinite-sign-in-loop/openidconnet-nonce-cookies.png deleted file mode 100644 index 3c94597af3c..00000000000 Binary files a/support/entra/entra-id/app-integration/media/asp-dot-net-application-infinite-sign-in-loop/openidconnet-nonce-cookies.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/capture-https-traffic-http-fiddler-entra-id-app/enable-https-decrypt.png b/support/entra/entra-id/app-integration/media/capture-https-traffic-http-fiddler-entra-id-app/enable-https-decrypt.png deleted file mode 100644 index 567b64ea8e3..00000000000 Binary files a/support/entra/entra-id/app-integration/media/capture-https-traffic-http-fiddler-entra-id-app/enable-https-decrypt.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/allow-public-client-flows.png b/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/allow-public-client-flows.png deleted file mode 100644 index 1153c54d492..00000000000 Binary files a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/allow-public-client-flows.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/grant-type.png b/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/grant-type.png deleted file mode 100644 index ca927a79e9b..00000000000 Binary files a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/grant-type.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/post-request.png b/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/post-request.png deleted file mode 100644 index 3e8adf337ac..00000000000 Binary files a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/post-request.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/public-client-type.png b/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/public-client-type.png deleted file mode 100644 index dbcd2805672..00000000000 Binary files a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/public-client-type.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/web-client-type.png b/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/web-client-type.png deleted file mode 100644 index dadea531260..00000000000 Binary files a/support/entra/entra-id/app-integration/media/confidential-client-application-authentication-error-aadsts7000218/web-client-type.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/app-reg.png b/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/app-reg.png deleted file mode 100644 index 151f5cdab8f..00000000000 Binary files a/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/app-reg.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/log-sample.png b/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/log-sample.png deleted file mode 100644 index c9b68801a63..00000000000 Binary files a/support/entra/entra-id/app-integration/media/enable-msal4j-logging-spring-boot-webapp/log-sample.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-appid.png b/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-appid.png deleted file mode 100644 index 3d7583b5f06..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-appid.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-redirecturi.png b/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-redirecturi.png deleted file mode 100644 index 8cafa532717..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-AADSTS50011-redirect-uri-mismatch/aadsts50011-error-redirecturi.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/consent-permissions.png b/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/consent-permissions.png deleted file mode 100644 index 746e3ec295b..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/consent-permissions.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/graph-api-permissions.png b/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/graph-api-permissions.png deleted file mode 100644 index 82c7e424751..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-AADSTS650056-misconfigured-app/graph-api-permissions.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png b/support/entra/entra-id/app-integration/media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png deleted file mode 100644 index e225949405a..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts50000-issuing-token-sign-in-service/manifest-sample.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-chain-ski-aki-value.png b/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-chain-ski-aki-value.png deleted file mode 100644 index aff995340bc..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-chain-ski-aki-value.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-policies.png b/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-policies.png deleted file mode 100644 index afcfc48e3ae..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts50017-certificate-based-authentication-failed/certificate-policies.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/adfs-saml-response.png b/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/adfs-saml-response.png deleted file mode 100644 index fec481a181e..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/adfs-saml-response.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-2.png b/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-2.png deleted file mode 100644 index 3b5006d96b8..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-2.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-3.png b/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-3.png deleted file mode 100644 index 42bc49445e1..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response-3.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response.png b/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response.png deleted file mode 100644 index a87d80e6554..00000000000 Binary files a/support/entra/entra-id/app-integration/media/error-code-aadsts7500514-supported-type-saml-response-not-found/pingid-saml-response.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/add-javascript-code-onbeforerequest-function.png b/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/add-javascript-code-onbeforerequest-function.png deleted file mode 100644 index 5893b9e28a1..00000000000 Binary files a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/add-javascript-code-onbeforerequest-function.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/all-processes.png b/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/all-processes.png deleted file mode 100644 index bd313a49114..00000000000 Binary files a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/all-processes.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/show-only-the-following-hosts.png b/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/show-only-the-following-hosts.png deleted file mode 100644 index ce1e5358790..00000000000 Binary files a/support/entra/entra-id/app-integration/media/filter-fiddler-traffic-using-domain-name-client-process/show-only-the-following-hosts.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-application-permissions.png b/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-application-permissions.png deleted file mode 100644 index 29a60520670..00000000000 Binary files a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-application-permissions.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-azure-sql-database.png b/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-azure-sql-database.png deleted file mode 100644 index 3cdca3ded8f..00000000000 Binary files a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/add-azure-sql-database.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/groups-list.png b/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/groups-list.png deleted file mode 100644 index dd07a80ca18..00000000000 Binary files a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/groups-list.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png b/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png deleted file mode 100644 index 8e623eef80c..00000000000 Binary files a/support/entra/entra-id/app-integration/media/get-signed-in-users-groups-in-access-token/select-method-to-get-groups.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/clone-msal-repository.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/clone-msal-repository.png deleted file mode 100644 index e7cd9c6c89e..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/clone-msal-repository.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/get-from-version-control.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/get-from-version-control.png deleted file mode 100644 index ee33100cc32..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/get-from-version-control.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/open-existing-project-android-studio.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/open-existing-project-android-studio.png deleted file mode 100644 index 2cd86ed5996..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/open-existing-project-android-studio.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-inspector.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-inspector.png deleted file mode 100644 index 370dc0f34d1..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-inspector.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-to-check-signature-hash.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-to-check-signature-hash.png deleted file mode 100644 index d7738bb4024..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-package-to-check-signature-hash.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-play-button.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-play-button.png deleted file mode 100644 index 08332f3216b..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-play-button.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-root-package.png b/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-root-package.png deleted file mode 100644 index f20f1b5a479..00000000000 Binary files a/support/entra/entra-id/app-integration/media/package-inspector-msal-android-native/select-root-package.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/script-errors-running-msal-net-xbap-app/add-uri.png b/support/entra/entra-id/app-integration/media/script-errors-running-msal-net-xbap-app/add-uri.png deleted file mode 100644 index 29da28a8c62..00000000000 Binary files a/support/entra/entra-id/app-integration/media/script-errors-running-msal-net-xbap-app/add-uri.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/serilog-protected-web-api-authentication-authorization-errors/application-id-uri.png b/support/entra/entra-id/app-integration/media/serilog-protected-web-api-authentication-authorization-errors/application-id-uri.png deleted file mode 100644 index 1d7ddb2990e..00000000000 Binary files a/support/entra/entra-id/app-integration/media/serilog-protected-web-api-authentication-authorization-errors/application-id-uri.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt/login-hint-optional-claim.png b/support/entra/entra-id/app-integration/media/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt/login-hint-optional-claim.png deleted file mode 100644 index 8f2a861c23e..00000000000 Binary files a/support/entra/entra-id/app-integration/media/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt/login-hint-optional-claim.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/testing-sso-screen.PNG b/support/entra/entra-id/app-integration/media/testing-sso-screen.PNG deleted file mode 100644 index e1cdcce27f9..00000000000 Binary files a/support/entra/entra-id/app-integration/media/testing-sso-screen.PNG and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png b/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png deleted file mode 100644 index 9aea6915c09..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png b/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png deleted file mode 100644 index 7c0cf2dfa36..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png b/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png deleted file mode 100644 index 6442cbdbbbc..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/azure-key-vault.png b/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/azure-key-vault.png deleted file mode 100644 index 54f34e5c512..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/azure-key-vault.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/configured-permissions.png b/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/configured-permissions.png deleted file mode 100644 index af451278d66..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/configured-permissions.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/consent-on-behalf-of-your-organization.png b/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/consent-on-behalf-of-your-organization.png deleted file mode 100644 index b6c0356e6ac..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-consent-issues/consent-on-behalf-of-your-organization.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/add-redirect-uri.png b/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/add-redirect-uri.png deleted file mode 100644 index bae6fb3fabe..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/add-redirect-uri.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/custom-policy.png b/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/custom-policy.png deleted file mode 100644 index 8ee12a4673f..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/custom-policy.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/find-identity-exp-fr.png b/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/find-identity-exp-fr.png deleted file mode 100644 index 441539a5727..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-error-idx10501-aspnet-b2c/find-identity-exp-fr.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-after-auth.png b/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-after-auth.png deleted file mode 100644 index 806810d5df8..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-after-auth.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-misisng-samesite.png b/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-misisng-samesite.png deleted file mode 100644 index 6914917d1b7..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-misisng-samesite.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-multiple-domains.png b/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-multiple-domains.png deleted file mode 100644 index 649eb46e9d9..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-multiple-domains.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-start-auth.png b/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-start-auth.png deleted file mode 100644 index 6a071f4189f..00000000000 Binary files a/support/entra/entra-id/app-integration/media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-start-auth.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/media/use-netlog-capture-network-traffic/import-netlog-json.png b/support/entra/entra-id/app-integration/media/use-netlog-capture-network-traffic/import-netlog-json.png deleted file mode 100644 index 7403052b1d6..00000000000 Binary files a/support/entra/entra-id/app-integration/media/use-netlog-capture-network-traffic/import-netlog-json.png and /dev/null differ diff --git a/support/entra/entra-id/app-integration/no-account-login-hint-passed-acquire-token-silent.md b/support/entra/entra-id/app-integration/no-account-login-hint-passed-acquire-token-silent.md deleted file mode 100644 index 46af68a7711..00000000000 --- a/support/entra/entra-id/app-integration/no-account-login-hint-passed-acquire-token-silent.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -title: No Account or Login Hint Was Passed to the AcquireTokenSilent -description: Provides solutions to an error that occurs when web applications using Microsoft Authentication Library (MSAL) or Microsoft Identity Web acquire a token silently. -ms.service: entra-id -ms.date: 06/18/2025 -ms.reviewer: willfid, v-weizhu -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# Error "No account or login hint was passed to the AcquireTokenSilent" in web applications without persistent token cache - -This article offers solutions for the "No account or login hint was passed to the AcquireTokenSilent" error that occurs in a web application using Microsoft Authentication Library (MSAL) or Microsoft Identity Web. - -## Symptoms - -Assume that your web applications authenticate users using MSAL or Microsoft Identity Web and don't use persistent token caches. When MSAL tries to pull a user account and acquire a token silently from its token cache, the following error message is displayed: - -> No account or login hint was passed to the AcquireTokenSilent - -## Cause - -This issue occurs because MSAL looks for an account that no longer exists in the token cache based on an existing authentication cookie. The authentication cookie is created only after an interactive sign-in and contains information about the user. This issue occurs in the following scenarios: - -- The web application has restarted. -- The memory is cleared due to high memory usage or a set period of inactivity. -- MSAL has a default cache size limit that automatically removes older entries. - -## Solution 1 (recommended): Implement a persistent token cache - -You can implement a persistent token cache in a durable location such as SQL Server or file-based storage. A persistent token cache ensures that tokens are retained even when the application restarts or the memory is cleared. For more information about how to implement a custom persistent token cache, see [Token cache serialization](/entra/msal/dotnet/how-to/token-cache-serialization). - -## Solution 2: Reject the authentication cookie - -You can implement a cookie authentication event to validate whether the currently signed-in user is present in the MSAL token cache. If the user isn't present, reject the authentication cookie and force the current user to sign in again. - -### For ASP.NET web applications using MSAL - -Create a cookie authentication event: - -```csharp -app.UseCookieAuthentication(new CookieAuthenticationOptions -{ - Provider = new CookieAuthenticationProvider() - { - OnValidateIdentity = async context => - { - IConfidentialClientApplication clientApp = MsalAppBuilder.BuildConfidentialClientApplication(); - -         var signedInUserIdentity = new ClaimsPrincipal(context.Identity); - -         if (await clientApp.GetAccountAsync(signedInUserIdentity.GetAccountId()) == null) - -         { - -             context.RejectIdentity(); - -         } - -     } - - } - -}); -``` - -> [!NOTE] -> To implement a cookie authentication event, the web application must install the following helper classes and the `Microsoft.Identity.Web.TokenCache` NuGet package: -> -> - `MsalAppBuilder.cs` -> - `AuthenticationConfig.cs` - -### For ASP.NET Core web applications using MSAL - -1. Create a custom cookie authentication event: - - ```csharp - using Microsoft.AspNetCore.Authentication.Cookies; - using Microsoft.Extensions.DependencyInjection; - using Microsoft.Identity.Client; - using System.Threading.Tasks; - using System.Security.Claims; - - namespace SampleApp.Services - { - internal class RejectSessionCookieWhenAccountNotInCacheEvents : CookieAuthenticationEvents - { - public async override Task ValidatePrincipal(CookieValidatePrincipalContext context) - { - var msalInstance = context.HttpContext.RequestServices.GetRequiredService(); - IConfidentialClientApplication msalClient = msalInstance.GetClient(); - -         var accounts = await msalClient.GetAccountsAsync(); - -         var account = await msalClient.GetAccountAsync(accounts.FirstOrDefault()); - -         if (account == null) - -         { - -             context.RejectPrincipal(); - -         } - -         await base.OnValidatePrincipal(context); - -     } - - } - - } - ``` - -2. Register the custom cookie authentication event: - - ```csharp - Services.Configure(cookieScheme, options=>options.Events=new RejectSessionCookieWhenAccountNotInCacheEvents()); - ``` - -### For web applications using Microsoft Identity Web - -Microsoft Identity Web provides built-in mechanisms to manage token caches. For more information, see [Managing incremental consent and conditional access](https://github.com/AzureAD/microsoft-identity-web/wiki/Managing-incremental-consent-and-conditional-access). If this document doesn't help you resolve the issue, you can manually clear the authentication cookie using a custom cookie authentication event: - -1. Create a custom cookie authentication event: - - ```csharp - using Microsoft.AspNetCore.Authentication.Cookies; - using Microsoft.Extensions.DependencyInjection; - using Microsoft.Identity.Client; - using Microsoft.Identity.Web; - using System; - using System.Collections.Generic; - using System.Linq; - using System.Threading.Tasks; - - namespace SampleApp.Services - { - internal class RejectSessionCookieWhenAccountNotInCacheEvents : CookieAuthenticationEvents - { - public async override Task ValidatePrincipal(CookieValidatePrincipalContext context) - { - try - { - var tokenAcquisition = context.HttpContext.RequestServices.GetRequiredService(); - string token = await tokenAcquisition.GetAccessTokenForUserAsync( - scopes: new[] { "profile" }, - user: context.Principal); - } - catch (MicrosoftIdentityWebChallengeUserException ex) - when (AccountDoesNotExistInTokenCache(ex)) - { - context.RejectPrincipal(); - } - } - /// - /// Is the exception due to no account in the token cache? - /// - /// Exception thrown by .GetTokenForXX methods. - /// A boolean indicating if the exception relates to the absence of an account in the cache. -     private static bool AccountDoesNotExistInTokenCache(MicrosoftIdentityWebChallengeUserException ex) -     { -         return ex.InnerException is MsalUiRequiredException - -                && (ex.InnerException as MsalUiRequiredException).ErrorCode == "user_null"; - -     } - - } - - } - ``` - -2. Register the custom cookie authentication event: - - ```csharp - // Add Microsoft Identity Web - services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme) - .AddMicrosoftIdentityWebApp(Configuration.GetSection("AzureAd")) - .EnableTokenAcquisitionToCallDownstreamApi(initialScopes) - .AddMicrosoftGraph(Configuration.GetSection("GraphBeta")) - .AddInMemoryTokenCaches(); - - // Register the Custom Cookie Authentication event - Services.Configure(cookieScheme, options=>options.Events=new RejectSessionCookieWhenAccountNotInCacheEvents()); - ``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/package-inspector-msal-android-native.md b/support/entra/entra-id/app-integration/package-inspector-msal-android-native.md deleted file mode 100644 index 5ce878bb171..00000000000 --- a/support/entra/entra-id/app-integration/package-inspector-msal-android-native.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Package Inspector for MSAL Android Native -description: Introduces how to install and use the Package Inspector tool. -ms.reviewer: markbukovich, v-weizhu -ms.service: entra-id -ms.date: 03/25/2025 -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# Package Inspector for MSAL Android Native - -The Microsoft Authentication Library (MSAL) for Android Native includes a tool called Package Inspector. This tool lists the packages installed on an Android device and allows users to view, copy, and paste the signature hash used to sign an application's package. Package Inspector is invaluable for troubleshooting and verifying the signature hash of applications installed on an Android device. This article covers installation, usage, and common issues of the Package Inspector. - -## Scenarios for using Package Inspector - -- You have successfully developed an application to use MSAL, but after deploying the app to the Google Play Store, the app fails to perform authentication. - - In this scenario, Package Inspector is useful to discover the new signature hash used by Google to sign the app package. - -- You are implementing MSAL in your Android application, but encounter the following error: - - > The redirect URI in the configuration file doesn't match with the one generated with the package name and signature hash. Please verify the uri in the config file and your app registration in Azure portal. - - In this scenario, you can use Package Inspector to verify what the package signature hash is and configure both the Azure portal and application to use the correct signature hash. - -- You are implementing MSAL in your Android application, but encounter the following error: - - > Intent filter for: BrowserTabActivity is missing - - This error occurs because the signature hash specified in the *AndroidManifest.xml* file doesn't match the signature hash used to sign the APK file. In this scenario, Package Inspector is useful to verify what the signature hash is. - -> [!NOTE] -> For more information about MSAL for Android Native, see [Microsoft Authentication Library (MSAL) for Android](https://github.com/AzureAD/microsoft-authentication-library-for-android). - -## Prerequisites - -Before you start, ensure you have the following: - -- A recent version of Android Studio installed. - - Android Studio comes with an AVD manager. For more information, see [Create and manage virtual devices](https://developer.android.com/studio/run/managing-avds). -- A virtual Android device with applications installed. -- A physical device with developer options, USB debugging enabled, and a USB cable. For more information, see [Configure on-device developer options](https://developer.android.com/studio/debug/dev-options). -- An application installed to inspect. - -## Install Package Inspector - -There are two methods to install Package Inspector: - -### Option 1: Clone Android MSAL repository directly into Android Studio - -1. Open Android Studio and close any open projects. -2. Select **Get From Version Control**. - - :::image type="content" source="media/package-inspector-msal-android-native/get-from-version-control.png" alt-text="Screenshot that shows the 'Get From Version Control' option in Android Studio"::: -3. Ensure **Git** is selected at the top of the window, paste the Android MSAL repository URL `https://github.com/AzureAD/microsoft-authentication-library-for-android.git`, and then select **Clone**. - - :::image type="content" source="media/package-inspector-msal-android-native/clone-msal-repository.png" alt-text="Screenshot that shows how to clone a Git repository in Android Studio"::: - -### Option 2: Download Android MSAL repository and open it in Android Studio - -1. [Download the Android MSAL repository](https://github.com/AzureAD/microsoft-authentication-library-for-android/archive/refs/heads/dev.zip). -2. Extract the zip file to your selected directory. -3. Open Android Studio and close any open projects. -4. Select **Open an Existing Project**. - - :::image type="content" source="media/package-inspector-msal-android-native/open-existing-project-android-studio.png" alt-text="Screenshot that shows the 'Open an Existing Project' option in Android Studio"::: -5. Select the root package **msal-android** for the Android MSAL repository. Then, select **OK**. - - :::image type="content" source="media/package-inspector-msal-android-native/select-root-package.png" alt-text="Screenshot showing selecting the root package in Android Studio"::: - - > [!NOTE] - > - The default name of the root package is `microsoft-authentication-library-for-android-dev`. In this example, it's renamed `msal-android`. - > - Don't select the **package-inspector** directory. - -## Use Package Inspector - -1. With the Android MSAL project open in Android Studio, connect the desired Android device. It can be a physical device connected to the computer's USB port or an emulator booted from Android Studio's AVD manager. Ensure your device appears in the drop-down list at the top of Android Studio and select it. -2. On the left of the device drop-down list, there is another drop-down list. Select **package-inspector** from it. - - :::image type="content" source="media/package-inspector-msal-android-native/select-package-inspector.png" alt-text="Screenshot that shows the selection of package-inspector in Android Studio" lightbox="media/package-inspector-msal-android-native/select-package-inspector.png"::: -3. Select the **play** button (indicated with a green circle on the right) to build, install, and run Package Inspector on the selected device. - - :::image type="content" source="media/package-inspector-msal-android-native/select-play-button.png" alt-text="Screenshot that shows the selection of the play button in Android Studio" lightbox="media/package-inspector-msal-android-native/select-play-button.png"::: -4. Browse the list of packages in the Package Inspector app and select a package to view its signature hash. All accessible packages appear in this list. - - :::image type="content" source="media/package-inspector-msal-android-native/select-package-to-check-signature-hash.png" alt-text="Screenshot that shows package selection in the Package Inspector app"::: - -## Common issues - -### Issues when loading Package Inspector into Android Studio - -To resolve these issues, ensure you load the root package from the MSAL repository, not Package Inspector. Make sure that the Android MSAL project you load into Android Studio is named `microsoft-authentication-library-for-android-dev` or whatever you have renamed the root directory on your system instead of `package-inspector`. For more information, see step 5 under [Option 2](#option-2-download-android-msal-repository-and-open-it-in-android-studio) in the [Install Package Inspector](#install-package-inspector) section. - -### Not all packages appear in Package Inspector - -You have installed and opened Package Inspector, and a list of packages appear in the app. However, you don't see packages for any apps you have installed on the device. The issue might occur due to changes in Android 11 (API 30). For more information, see [Package visibility](https://developer.android.com/training/package-visibility). - -To resolve this issue, follow these steps: - -1. Open the *AndroidManifest.xml* file within the `package-inspector` directory on the left side of Android Studio. -2. Add the following permission and query between the `` tags: - - ```xml - - ... - - - - - - - - - ``` - -3. Rerun the application from Android Studio to apply the changes. Then, you can see the packages you have installed. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/repeat-login-prompts-in-msal-ios-app.md b/support/entra/entra-id/app-integration/repeat-login-prompts-in-msal-ios-app.md deleted file mode 100644 index d44fa92e7e6..00000000000 --- a/support/entra/entra-id/app-integration/repeat-login-prompts-in-msal-ios-app.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Why does an MSAL-based iOS app keep asking for credentials with Microsoft Entra? -description: Provides guidance for troubleshooting repeated sign-in prompts in an iOS MSAL implementation -ms.date: 03/19/2025 -ms.author: daga -ms.service: entra-id -ms.custom: sap:Microsoft Entra App Integration and Development ---- - -# Troubleshoot sign-in prompt issues in iOS with MSAL SDK - -This article provides guidance for troubleshooting repeated sign-in prompts in an iOS app that uses Microsoft Authentication Library (MSAL). - -## Symptoms - -You [follow this tutorial](/azure/active-directory/develop/tutorial-v2-ios) to integrate Microsoft identity platform authentication in your iOS app by using the Microsoft Authentication Library (MSAL) SDK. However, after the initial login, users are unexpectedly prompted to sign in multiple times. - -## Cause - -This issue is typically caused by the web browser used by MSAL does not allow cookie sharing. - -The tutorial uses the MSAL to implement authentication. MSAL SDK facilitates authentication by automatically renewing tokens. It also enables single sign-on (SSO) between other apps on the device and manages user accounts. - -For SSO to function correctly, tokens must be shared between apps. To meet this requirement, you must use a token cache or a broker application, such as Microsoft Authenticator for iOS. Interactive authentication in MSAL requires a web browser. On iOS, MSAL uses the Safari system browser by default for interactive authentication. This default setup supports SSO state sharing between apps. - -However, if you customize the browser configuration for authentication, such as by using one of the following options, cookie sharing might not be enabled by default. - -| **For iOS only** | **For iOS and macOS** | -| --- | --- | -| [SFAuthenticationSession](https://developer.apple.com/documentation/safariservices/sfauthenticationsession?language=objc)
[SFSafariViewController](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller?language=objc) | [ASWebAuthenticationSession](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession?language=objc)
[WKWebView](https://developer.apple.com/documentation/webkit/wkwebview?language=objc) | - - -## Resolution - -To prevent repeated login prompts, you must allow cookie sharing when you customize the browser. To enable SSO and cookie sharing between MSAL and your iOS app, use one of the following solutions: - -Use `ASWebAuthenticationSession` and Safari system browser (`UIApplication.shared.open`) - - - Use Case: Your app uses MSAL together with the default `ASWebAuthenticationSession` instance, and you open external links or logout flows in Safari system browser. - - **Note:** `ASWebAuthenticationSession` is the recommended method for MSAL interactive authentication on iOS 12+. It's the only supported method on iOS 13+. This method is privacy-preserving and shares cookies with system browser. SSO works between MSAL and Safari browser application because they share cookies through the system authentication session. - -Use `WKWebView` - - - Use Case: You explicitly configure MSAL to use `WKWebView`, and your app also uses `WKWebView` for related workflows. - - **Note:** You can use `WKWebView` for a consistent experience within your app. However, because it's sandboxed, `WKWebView` doesn't share session cookies with Safari system browser or other apps. In this condition, SSO support is limited to use within your app. - - For more information, see [Customizing webviews and browsers](/azure/active-directory/develop/customize-webviews). - -[!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/reply-url-redirected-to-localhost.md b/support/entra/entra-id/app-integration/reply-url-redirected-to-localhost.md deleted file mode 100644 index 89a2c8fb29c..00000000000 --- a/support/entra/entra-id/app-integration/reply-url-redirected-to-localhost.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Microsoft Entra ID is sending the token to an incorrect reply URL endpoint or localhost. -description: Describes a problem in which Microsoft Entra ID is sending the token to an incorrect reply URL endpoint or localhost. -ms.date: 08/26/2022 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- -# Microsoft Entra ID is sending the token to an incorrect reply URL endpoint or localhost - -This article describes a problem in which Microsoft Entra ID is sending the token to an incorrect reply URL endpoint or localhost. - -## Symptoms - -During single sign-on, if the sign-in request does not contain an explicit reply URL (Assertion Consumer Service URL) then Microsoft Entra ID will select any of the configured reply URLs for that application. Even if the application has an explicit reply URL configured, the user may be to redirected `https://127.0.0.1:444`. - -When the application was added as a non-gallery app, Microsoft Entra ID created this reply URL as a default value. This behavior has changed and Microsoft Entra no longer adds this URL by default. - -## Cause - -The user has not been granted access to the application in Microsoft Entra ID. - -## Resolution - -Delete the unused reply URLs configured for the application. - -On the SAML-based SSO configuration page, in the **Reply URL (Assertion Consumer Service URL)** section, delete unused or default Reply URLs created by the system. For example, `https://127.0.0.1:444/applications/default.aspx`. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/script-errors-running-msal-net-xbap-app.md b/support/entra/entra-id/app-integration/script-errors-running-msal-net-xbap-app.md deleted file mode 100644 index 733a350f8a9..00000000000 --- a/support/entra/entra-id/app-integration/script-errors-running-msal-net-xbap-app.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Script errors when running MSAL.Net in XBAP application with Internet Explorer -description: Provides a solution to the script error that occurs when you run MSAL.Net in an XBAP application that uses Microsoft Entra ID. -ms.date: 03/12/2025 -ms.reviewer: bachoang -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- -# "Cookies are disabled" error in MSAL.Net XBAP application in Internet Explorer - -This article describes a problem in which a script error is returned when you performing a Microsoft Entra ID login by using an XAML Browser Application (XBAP) from Microsoft Internet Explorer. - -## Symptoms - -You receive a script error warning and an error message stating that **cookies are disabled** when logging into Microsoft Entra ID. This problem happens when you run Microsoft Authentication Library for .NET (MSAL.NET) code similar to the following in an XAML Browser Application (XBAP) from Internet Explorer: - -```C# -string tenantId = ""; -string clientId = ""; -string[] Scopes = new string[] { "User.Read" }; -string errorMessage = string.Empty; -try - { - using (HttpClient httpClient = new HttpClient()) - { - IPublicClientApplication publicClientApp = PublicClientApplicationBuilder.Create(clientId) - .WithDefaultRedirectUri() - .WithAuthority(AzureCloudInstance.AzurePublic, AadAuthorityAudience.AzureAdMyOrg) - .WithTenantId(tenantId) - .Build(); - AuthenticationResult authenticationResult = null; - var t = Task.Run(async () => - { - try - { - authenticationResult = await publicClientApp.AcquireTokenInteractive(Scopes) - .WithAccount(null) - .WithPrompt(Prompt.ForceLogin) - .ExecuteAsync(); - } - catch (Exception ex) - { - errorMessage = "Error while getting token: " + ex.ToString(); - } - }); - t.Wait(); - - if (authenticationResult != null) - { - return authenticationResult.AccessToken; - } - else - { - return errorMessage; - } - } - } - catch (Exception ex) - { - return ex.Message; - } -``` -## Cause - -Although XBAP applications run within Internet Explorer, they operate in their own process space: **PresentationHost.exe**. This process is a highly secure container. XBAP applications use the WebBrowser control to host the Microsoft Entra ID login page. To minimize security risks from the browser surface, this container is configured yo use security restrictions that include blocking cookies. However, the Microsoft Entra ID login process depends on cookies. This conflict causes a script error. - -## Solution - -Configure MSAL.Net to use the [System Browser](/azure/active-directory/develop/msal-net-web-browsers#system-browser-experience-on-net) - Microsoft Edge to open the Entra ID login page. Then, follow these steps to make the required updates: - -1. In the Azure portal, locate your app in the **App registrations** page. Register `http://localhost` as a redirect URL under **Mobile and desktop applications** platform. - - :::image type="content" source="./media/script-errors-running-msal-net-xbap-app/add-uri.png" alt-text="Screenshot that shows the localhost address being registered as a redirect URL" lightbox="./media/script-errors-running-msal-net-xbap-app/add-uri.png"::: - -2. Make the following change to your code: - - ```C# - try - { - using (HttpClient httpClient = new HttpClient()) - { - IPublicClientApplication publicClientApp = PublicClientApplicationBuilder.Create(clientId) - .WithRedirectUri("http://localhost") - .WithAuthority(AzureCloudInstance.AzurePublic, AadAuthorityAudience.AzureAdMyOrg) - .WithTenantId(tenantId) - .Build(); - AuthenticationResult authenticationResult = null; - - var t = Task.Run(async () => - { - try - { - authenticationResult = await publicClientApp.AcquireTokenInteractive(Scopes) - .WithAccount(null) - .WithPrompt(Prompt.ForceLogin) - .WithUseEmbeddedWebView(false) - .ExecuteAsync(); - } - catch (Exception ex) - { - errorMessage = "Error while getting token: " + ex.ToString(); - } - }); - ``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/send-notification-details.md b/support/entra/entra-id/app-integration/send-notification-details.md deleted file mode 100644 index 98479518914..00000000000 --- a/support/entra/entra-id/app-integration/send-notification-details.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: How to send Notification Details to Microsoft support -description: Learn how to send Notification Details to Microsoft support. -ms.date: 02/18/2024 -author: bernawy -ms.author: bernaw -editor: v-jsitser -ms.reviewer: v-leedennis, jarrettr -ms.service: entra-id -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Enterprise Applications ---- -# How to send Notification Details to Microsoft support - -## How to see the details of a portal notification - -You can see the details of any portal notification by following the steps below: - -1. Select the **Notifications** icon (the bell) in the upper right of the Azure portal. - -2. Select any notification in an **Error** state (those with a red (!) icon next to them). - - > [!NOTE] - > You cannot click notifications in a **Successful** or **In Progress** state. - -3. Use the information under **Notification Details** to understand more details about the problem. - -If you still need help, you can also share this information with a support engineer or the product group to get help with your problem. - -## How to get help by sending notification details to a support engineer - -1. **Take a screenshot** or select the **Copy error icon**, found to the right of the **Copy error** textbox to copy all the notification details to share with a support or product group engineer. - -It is important that you share **all the details listed below** with a support engineer if you need help, so that they can help you quickly. - -## Notification Details Explained - -See the following descriptions for more details about the notifications. - -### Essential Notification Items - -- **Title** – the descriptive title of the notification - - Example – **Application proxy settings** -- **Description** – the description of what occurred as a result of the operation - - Example – **Internal url entered is already being used by another application** -- **Notification ID** – the unique ID of the notification - - Example – **clientNotification-2adbfc06-2073-4678-a69f-7eb78d96b068** -- **Client Request ID** – the specific request ID made by your browser - - Example – **302fd775-3329-4670-a9f3-bea37004f0bc** -- **Time Stamp UTC** – the timestamp during which the notification occurred, in UTC - - Example – **2017-03-23T19:50:43.7583681Z** -- **Internal Transaction ID** – the internal ID we can use to look up the error in our systems - - Example – **71a2f329-ca29-402f-aa72-bc00a7aca603** -- **UPN** – the user who performed the operation - - Example – **tperkins\@f128.info** -- **Tenant ID** – the unique ID of the tenant that the user who performed the operation was a member of - - Example – **7918d4b5-0442-4a97-be2d-36f9f9962ece** -- **User object ID** – the unique ID of the user who performed the operation - - Example – **17f84be4-51f8-483a-b533-383791227a99** - -### Detailed Notification Items - -- **Display Name** – **(can be empty)** a more detailed display name for the error - - Example – **Application proxy settings** -- **Status** – the specific status of the notification - - Example – **Failed** -- **Object ID** – **(can be empty)** the object ID against which the operation was performed - - Example – **8e08161d-f2fd-40ad-a34a-a9632d6bb599** -- **Details** – the detailed description of what occurred as a result of the operation - - Example – **Internal url `https://bing.com/` is invalid since it is already in use** -- **Copy error** – Select the **copy icon** to the right of the **Copy error** textbox to copy all the notification details to share with a support or product group engineer - - Example - ```{"errorCode":"InternalUrl\_Duplicate","localizedErrorDetails":{"errorDetail":"Internal url 'https://google.com/' is invalid since it is already in use"},"operationResults":\[{"objectId":null,"displayName":null,"status":0,"details":"Internal url 'https://bing.com/' is invalid since it is already in use"}\],"timeStampUtc":"2017-03-23T19:50:26.465743Z","clientRequestId":"302fd775-3329-4670-a9f3-bea37004f0bb","internalTransactionId":"ea5b5475-03b9-4f08-8e95-bbb11289ab65","upn":"tperkins@f128.info","tenantId":"7918d4b5-0442-4a97-be2d-36f9f9962ece","userObjectId":"17f84be4-51f8-483a-b533-383791227a99"}``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/serilog-protected-web-api-authentication-authorization-errors.md b/support/entra/entra-id/app-integration/serilog-protected-web-api-authentication-authorization-errors.md deleted file mode 100644 index cc775a40637..00000000000 --- a/support/entra/entra-id/app-integration/serilog-protected-web-api-authentication-authorization-errors.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -title: Use Serilog to Troubleshoot Protected Web API Authentication or Authorization Errors -description: Provides a sample web API application to troubleshoot Microsoft Entra protected Web API authentication or authorization errors using Serilog logs. -ms.date: 05/12/2025 -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform -ms.reviewer: bachoang, v-weizhu ---- -# Use Serilog to troubleshoot Microsoft Entra protected Web API authentication or authorization errors - -When a web API application calls a web API that's protected with Microsoft Entra ID, authentication or authorization errors might occur due to JwtBearer event validation failures. To troubleshoot this issue, this article introduces a sample web API application named [Net6WebAPILogging](https://github.com/bachoang/Net6WebAPILogging) to set and collect logs for JwtBearer events. - -## Net6WebAPILogging sample application - -This sample web API application assumes you already have a web API registered in Microsoft Entra ID. It uses Microsoft .NET 6 Framework and [Microsoft Identity Web](/entra/msal/dotnet/microsoft-identity-web/) NuGet package. - -It uses the following methods to set and collect logs for JwtBearer events: - -- Use the [JwtBearerEvents class](/dotnet/api/microsoft.aspnetcore.authentication.jwtbearer.jwtbearerevents) to configure middleware events. JWT Bearer token might fail to validate `OnTokenValidated`, `OnMessageReceived`, `OnAuthenticationFailed`, and `OnChalleenge` events. -- [Set up logging for JwtBearer events](#set-up-logging-for-jwtbearer-events). -- Use the [Serilog](https://serilog.net/) framework to log the `Debug` output to the console window and the local file whose path is specified in the **appsettings.json** file. - -## Run the sample application - -To run the sample application, you must perform the following steps: - -### Step 1: Configure the application ID URI for a protected web API - -To add the application ID URI for a web API, follow these steps: - -1. In the Azure portal, navigate to the app registration of the web API. -2. Select **Expose an API** under **Manage**. -3. At the top of the page, select **Add** next to **Application ID URI**. The default is `api://`. - - :::image type="content" source="media/serilog-protected-web-api-authentication-authorization-errors/application-id-uri.png" alt-text="Screenshot that shows how to set the application ID URI in an app registration."::: -5. Select **Save**. - -### Step 2: Change the sample application configuration - -Change the following information in the `AzureAd` section in the **appsettings.json** file with your own app registration information: - -```json -"AzureAd": { - "Instance": "https://login.microsoftonline.com/", - "Domain": ".onmicrosoft.com", // for example contoso.onmicrosoft.com - "TenantId": "", - "ClientId": "" - }, -``` - -### Step 3: Change the sample application code - -Change the `ValidAudiences` and `ValidIssuers` properties of the [TokenValidationParameters](/dotnet/api/microsoft.identitymodel.tokens.tokenvalidationparameters) class in the **Program.cs** file. - -### Step 4: Configure Serilog - -Configure Serilog in the `Serilog` section in the **appsettings.json** file as follows: - -```json - "Serilog": { - "MinimumLevel": { - "Default": "Information", - "Override": { - "Microsoft": "Debug", - "Microsoft.Hosting.Lifetime": "Information" - } - }, -``` - -## Set up logging for JwtBearer events - -Here's the sample **Program.cs** file that shows how to set up logging for the preceding events: - -```csharp -using Microsoft.AspNetCore.Authentication; -using Microsoft.AspNetCore.Authentication.JwtBearer; -using Microsoft.Identity.Web; -using Microsoft.IdentityModel.Logging; -using System.Diagnostics; -using Serilog; - - -// https://github.com/datalust/dotnet6-serilog-example - -Log.Logger = new LoggerConfiguration() - .WriteTo.Console() - .CreateBootstrapLogger(); - -Log.Information("starting up"); -try -{ - var builder = WebApplication.CreateBuilder(args); - - builder.Host.UseSerilog((ctx, lc) => lc - .WriteTo.Console() - .ReadFrom.Configuration(ctx.Configuration)); - - // Add services to the container. - builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme) - .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd")); - - // Enable PII for logging - IdentityModelEventSource.ShowPII = true; - // Configure middleware events - builder.Services.Configure(JwtBearerDefaults.AuthenticationScheme, options => - { - options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters - { - ValidAudiences = new List { "api://", "" }, - ValidIssuers = new List { "https://sts.windows.net//", "https://login.microsoftonline.com//v2.0" } - }; - options.Events = new JwtBearerEvents - { - OnTokenValidated = ctx => - { - string message = "[OnTokenValidated]: "; - message += $"token: {ctx.SecurityToken.ToString()}"; - Log.Information(message); - return Task.CompletedTask; - }, - OnMessageReceived = ctx => - { - string message = "[OnMessageReceived]: "; - ctx.Request.Headers.TryGetValue("Authorization", out var BearerToken); - if (BearerToken.Count == 0) - BearerToken = "no Bearer token sent\n"; - message += "Authorization Header sent: " + BearerToken + "\n"; - Log.Information(message); - return Task.CompletedTask; - }, - OnAuthenticationFailed = ctx => - { - ctx.Response.StatusCode = StatusCodes.Status401Unauthorized; - string message = $"[OnAuthenticationFailed]: {ctx.Exception.ToString()}"; - Log.Error(message); - // Debug.WriteLine("[OnAuthenticationFailed]: Authentication failed with the following error: "); - // Debug.WriteLine(ctx.Exception); - return Task.CompletedTask; - }, - OnChallenge = ctx => - { - // Debug.WriteLine("[OnChallenge]: I can do stuff here! "); - Log.Information("[OnChallenge]"); - return Task.CompletedTask; - }, - OnForbidden = ctx => - { - Log.Information("[OnForbidden]"); - return Task.CompletedTask; - } - }; - }); - - builder.Services.AddControllers(); - // Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle - // builder.Services.AddEndpointsApiExplorer(); - // builder.Services.AddSwaggerGen(); - - var app = builder.Build(); - - app.UseSerilogRequestLogging(); - // Configure the HTTP request pipeline. - if (app.Environment.IsDevelopment()) - { - // app.UseSwagger(); - // app.UseSwaggerUI(); - // do something - } - - app.UseHttpsRedirection(); - - app.UseAuthentication(); - app.UseAuthorization(); - - app.MapControllers(); - - app.Run(); -} -catch (Exception ex) -{ - Log.Fatal(ex, "Unhandled exception"); -} -finally -{ - Log.Information("Shut down complete"); - Log.CloseAndFlush(); -} -``` - -## References - -[Tutorial: Build and secure an ASP.NET Core web API with the Microsoft identity platform](/entra/identity-platform/tutorial-web-api-dotnet-core-build-app) - -[!INCLUDE [Azure Help Support](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt.md b/support/entra/entra-id/app-integration/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt.md deleted file mode 100644 index 9e6747e0c2e..00000000000 --- a/support/entra/entra-id/app-integration/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Bypass User Selection Prompt When Signing Out of OpenID Connect/OAuth2 Applications -description: Describes how to sign out of an OpenID Connect/OAuth2 application without a user selection prompt. -ms.service: entra-id -ms.date: 06/10/2025 -ms.reviewer: willfid, v-weizhu -ms.custom: sap:Developing or Registering apps with Microsoft identity platform -ms.topic: how-to ---- -# How to sign out of OpenID Connect/OAuth2 applications without a user selection prompt - -By default, when you sign out of an OpenID Connect/OAuth2 application registered in Microsoft Entra ID, you're prompted to select a user account to sign out of, even if only one account is available. This article provides a step-by-step guide to bypass this behavior. - -## Step 1: Add an optional claim for login\_hint - -1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/) as at least a [Cloud Application Administrator](/entra/identity/role-based-access-control/permissions-reference#cloud-application-administrator). -2. Browse to **Entra ID** > **App registrations**. -3. Select the application for which you want to configure optional claims. - 1. Under **Manage**, select **Token configuration**. - 2. Select **Add optional claim**. - 3. Select the token type you want to configure, such as **ID**. - 4. Select the optional claim **login_hint** to add. - 5. Select **Add**. - -:::image type="content" source="media/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt/login-hint-optional-claim.png" alt-text="Screenshot that shows the login_hint claim." lightbox="media/sign-out-of-openid-connect-oauth2-applications-without-user-selection-prompt/login-hint-optional-claim.png"::: - -For more information about adding optional claims, see [Configure and manage optional claims in ID tokens, access tokens, and SAML tokens](/entra/identity-platform/optional-claims). - -## Step 2: Ensure the "profile" and "openid" scopes are included in the original sign-in request - -Here are two examples of including both the `openid` and `profile` OpenID connect scopes in the request URL: - -- If you use the authorization code flow: - - ```http - https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize? - response_type=code&client_id=&scope=openid+user.read+profile&redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient - ``` - - During the token endpoint call, when you acquire an access token, an `id_token` is also returned. - -- If you use the implicit flow (not recommended): - - ```HTTP - https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize? - response_type=id_token&client_id=&scope=openid+user.read+profile&redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient - ``` - - After sign-in, when Microsoft Entra ID redirects back to your application, an `id_token` is returned. - -In the returned `id_token`, the value of the `login_hint` claim is included. - -## Step 3: Pass the logout\_hint parameter in the sign-out request - -When you send a sign-out request, pass the `logout_hint` parameter along with the value of the `login_hint` claim in the sign-out request: - -```http -https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/logout? -post_logout_redirect_uri=https://login.microsoftonline.com/common/oauth2/nativeclient -&logout_hint= -``` - -## More information - -For applications using Microsoft Authentication Library for JavaScript (MSAL.js), when you send an `EndSessionRequest` with a user account, MSAL.js automatically sends the `logout_hint` parameter along with the `login_hint` claim if detected. - -Here's an example code snippet: - -```typescript -logout() { - var account = this.authService.instance.getAllAccounts()[0]; - let logoutRequest:EndSessionRequest = { - account: account - }; - - this.authService.logout(logoutRequest); - } -``` - -For applications using Microsoft Identity Web or ASP.NET (Core) OpenID Connect authentication, you can add custom code to set the `logout_hint` parameter in the sign-out request. - -Here's an example code snippet: - -```csharp -services.Configure(OpenIdConnectDefaults.AuthenticationScheme, options => - -{ - - // Custom code here. - options.Events.OnRedirectToIdentityProviderForSignOut = (context) => - - { - - var login_hint = context.HttpContext.User.Claims.Where(c => c.Type == "login_hint").FirstOrDefault(); - - if (login_hint != null) - - { - - context.ProtocolMessage.SetParameter("logout_hint", login_hint.Value); - - }; - - return Task.FromResult(true); - - }; - -}); -``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-adding-apps.md b/support/entra/entra-id/app-integration/troubleshoot-adding-apps.md deleted file mode 100644 index e917bf72eec..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-adding-apps.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Troubleshoot common problems adding or removing an application to Microsoft Entra ID -description: Troubleshoot the common problems people face when adding or removing an app in Microsoft Entra ID. -ms.date: 02/18/2024 -author: bernawy -ms.author: bernaw -editor: v-jsitser -ms.reviewer: v-leedennis, jarrettr -ms.service: entra-id -ms.topic: overview -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Enterprise Applications ---- -# Troubleshoot common problems adding or removing an application to Microsoft Entra ID - -This series of articles provide guidance on how to troubleshoot issues that may arise when adding or removing an application in Microsoft Entra ID. - -## Application takes a long time to appear - -See the article [Application takes a long time to appear](app-takes-long-time-appear.md) for steps to troubleshoot and resolve this issue. - -## Application doesn't appear - -See the article [Application doesn't appear](app-doesnt-appear.md) for steps to troubleshoot and resolve this issue. - -## Unable to delete an application - -See the article [Unable to delete an application](unable-delete-app.md) for steps to troubleshoot and resolve this issue. - -## Send notification details to Microsoft support - -See the article [Send notification details to Microsoft support](send-notification-details.md) to learn how to see the details of a portal notification and send them to a support engineer. - -## More information - -If you need help with learning about applications, the [List of Tutorials on How to Integrate SaaS Apps with Microsoft Entra ID](/azure/active-directory/saas-apps/tutorial-list) article is a good place to start. - -In addition to this, the [Microsoft Entra Applications Document Library](/azure/active-directory/manage-apps/what-is-application-management) can help you learn more about single sign-on with Microsoft Entra ID and how it works. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-authorization-requestdenied-graph-api.md b/support/entra/entra-id/app-integration/troubleshoot-authorization-requestdenied-graph-api.md deleted file mode 100644 index a3c259ae4b1..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-authorization-requestdenied-graph-api.md +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Troubleshoot Authorization_RequestDenied error with Microsoft Graph -description: Guides to troubleshoot Authorization_RequestDenied error with Microsoft Graph in Postman. -ms.author: anukala -ms.date: 12/24/2024 -ms.service: entra-id -ms.custom: sap:Microsoft Graph Users, Groups, and Entra APIs ---- - -# Troubleshoot Authorization_RequestDenied error with Microsoft Graph - -When you use Microsoft Graph API to manage users, you might receive the following error message: - -> `Authorization_RequestDenied. Insufficient privileges to complete the operation.` - -This article demonstrates how to troubleshoot the `Authorization_RequestDenied` error in Microsoft Graph API by using Postman, through a "disable user" scenario. - -## Cause of the Authorization_RequestDenied error - -This error typically occurs because the user or app doesn't have sufficient permissions. To call Graph APIs, your app registration must have the following permissions: - -- The appropriate Microsoft Entra RBAC role for the required access level. For more information, see [Microsoft Entra built-in roles](/entra/identity/role-based-access-control/permissions-reference). -- The necessary API permissions to access Microsoft Graph. - -## Troubleshooting Microsoft Graph API by using Postman - -### Step 1: Assign Microsoft Entra RBAC role to the app registration (Service Principal) - -1. Log in to the [Azure portal](https://portal.azure.com), and go to **Microsoft Entra ID**. -1. In the **Manage** section, select **Roles and administrators**. -1. Select the appropriate role based on the required level of access. In this article, the app will manage the users. Therefore, **User Administrator** is selected. -1. Select **Add assignments**, select your app registration, and then select **Add**. - -### Step 2: Locate the application ID, client secret, and token endpoints of your app - -1. In the [Azure portal](https://portal.azure.com), go to **App registrations**, and then select your app registration. -1. On the **Overview** page, record the **Application (client) ID**. -1. Select **Endpoints**. This selection provides information, such as token endpoints, that will be used in the Postman configuration. This article uses OAuth 2.0 and token-based authentication together with Entra ID. In this case, you should record the **OAuth 2.0 token endpoint (v2)**. - - :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png" alt-text="Screenshot that shows checking the endpoints of the app registration." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/check-endpoints.png"::: -1. In the **Manage** section, select **Certificates & secrets**. Create a client secret or use an existing client secret for testing. - - In the Postman configuration, ensure you use the Client secret value, not the Secret ID. The client secret value cannot be viewed, except immediately after it's created. - -### Step 3: Configure Postman - -1. In Postman, select a request or collection, and then select **Authorization**. -1. Set Auth type to **OAuth 2.0**. -1. In the **Configure New Token** section, specify the following configuration: - - - Grant type: Client Credentials - - Access Token URL: \. - - Client ID: \ - - Client secret: \ - - Scope: `https://graph.microsoft.com/.default` - - Client Authentication: Send as Basic Auth header - - :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png" alt-text="Screenshot of Postman configurations." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/postman-config.png"::: - -1. Select **Get New Access Token**. If the configuration is correct, you should receive a token that will be used to run the Microsoft Graph API call. -1. Select **Proceed**, and then select **Use token**. - -### Step 4: Test and troubleshoot the Microsoft Graph API - -1. Send the following PATCH request to disable a user. `1f953789-0000-0000-0000-6f21508fd4e2` is the object ID of a user in the Entra ID. - - ``` HTTP - Patch https://graph.microsoft.com/v1.0/users/1f953789-0000-0000-0000-6f21508fd4e2 - ``` - - ```JSON - { - "accountEnabled": false - } - ``` - -1. The `Authorization_RequestDenied` error message is received in the response: - - ```Output - { - "error": { - "code": "Authorization_RequestDenied", - "message": "Insufficient privileges to complete the operation.", - "innerError": { - "date": "2024-12-24T03:25:32", - "request-id": "096361b2-75be-479b-b421-078610030949", - "client-request-id": "096361b2-75be-479b-b421-078610030949" - } - } - } - ``` - -1. Check the [Update user scenario in Microsoft Graph REST API v1.0 endpoint reference](/graph/api/user-update?view=graph-rest-1.0&tabs=http#permissions&preserve-view=true). The following permission is required to enable and disable a user, as described in the Microsoft Graph REST API v1.0 endpoint reference. - - | Property | Type | Description | - |:----------------|:--------|:------------| - | accountEnabled | Boolean | `true` if the account is enabled; otherwise, `false`. This property is required when a user is created.
- *User.EnableDisableAccount.All* + *User.Read.All* is the least privileged combination of permissions required to update this property.
- In delegated scenarios, *Privileged Authentication Administrator* is the least privileged role that's allowed to update this property for all administrators in the tenant. | - -1. Check whether the app registration has the required permissions: - 1. Locate your app registration in the Azure portal. - 2. In the **Manage** section, select **API permissions** - 3. Check the configured API permissions. In this case, the app registration doesn't have the **User.EnableDisableAccount.All** permission that is the root cause of the issue. - - :::image type="content" source="media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png" alt-text="Screenshot that shows checking API permissions." lightbox="media/troubleshoot-authorization-requestdenied-graph-api/check-api-permissions.png"::: - -1. Select **Add a permission** to add **User.EnableDisableAccount.All** to the app registration. -1. You must also select **Grant admin consent for default directory** for the permissions. Select **Yes** to confirm that you want to grant admin consent. -1. Send the PATCH request to disable a user. If the request is successful, you should receive a `204 No Content` response. - -[!INCLUDE [third-party-disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-consent-issues.md b/support/entra/entra-id/app-integration/troubleshoot-consent-issues.md deleted file mode 100644 index 2656a3a2e23..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-consent-issues.md +++ /dev/null @@ -1,240 +0,0 @@ ---- -title: Troubleshoot Consent Issues in Microsoft Entra ID -description: Helps you troubleshoot and resolve consent issues in Microsoft Entra ID. -ms.date: 01/15/2025 -ms.reviewer: willfid, v-weizhu -ms.service: entra-id -ms.custom: sap:App registrations ---- -# Troubleshoot consent issues in Microsoft Entra ID - -This article provides guidance on troubleshooting consent issues in Microsoft Entra ID. It applies to OpenID Connect and OAuth2-based authentications. - -> [!NOTE] -> SAML-based applications might present similar errors but require different solutions, typically due to configuration mismatches within the SAML request on either the third-party SAML Service Provider or Microsoft Entra ID. - -## Symptoms - -When an application tries to sign in or get an access token for a resource that hasn't been consented to by a user or admin, you receive an error message similar to one of the following examples: - -- > Need admin approval -- > AADSTS65001: The user or administrator has not consented to use the application with ID '\' named '\'. Send an interactive authorization request for this user and resource. -- > AADSTS650056: Misconfigured application. This could be due to one of the following: The client has not listed any permissions for 'AAD Graph' in the requested permissions in the client's application registration. Or, The admin has not consented in the tenant. Or, Check the application identifier in the request to ensure it matches the configured client application identifier. Please contact your admin to fix the configuration or consent on behalf of the tenant. -- > AADSTS90094: An administrator of \ has set a policy that prevents you from granting \ the permissions it is requesting. Contact an administrator of \, who can grant permissions to this app on your behalf. -- > AADSTS90008: The user or administrator has not consented to use the application with ID '\'. This happened because application is misconfigured: it must require access to Windows Azure Active Directory by specifying at least 'Sign in and read user profile' permission -- > AADSTS900941: Administrator consent is required. App is considered risky. (AdminConsentRequiredDueToRiskyApp) This app may be risky. If you trust this app, ask your admin to grant you access. -- > AADSTS900981: An admin consent request was received for a risky app. (AdminConsentRequestRiskyAppWarning) This app may be risky. Only continue if you trust this app. - -There are many reasons why you might receive a message indicating that admin approval or admin consent is required. Consider the following high-level scenarios: - -- The **User.Read** permission is missing. -- User consent is disabled at the tenant level. -- User assignment is enabled for the application. -- A service principal doesn't exist in the tenant for the client application. -- A service principal doesn't exist in the tenant for the resource. -- A consent URL that specifies `prompt=admin_consent` or `prompt=consent` is requested. -- Scopes that haven't been consented to are requested in a sign-in request. -- The scope or permission requires admin consent. -- User consent is blocked for risky applications. - -The following sections provide a troubleshooting guide for finding the root causes of consent issues. If you want to resolve issues directly, go to the [Perform admin consent](#perform-admin-consent) section. - -## Before troubleshooting - -Make sure the application has permission for user sign-in, such as the **User.Read** permission. Furthermore, ensure that this permission has been consented to. - -For example, if you own the application registration or any application requiring user sign-in, you should at least have the Microsoft Graph **User.Read** or **Openid** delegated permission added to the application registration **API Permissions**. - - :::image type="content" source="media/troubleshoot-consent-issues/configured-permissions.png" alt-text="Screenshot that shows the permissions added to the application registration API Permissions." lightbox="media/troubleshoot-consent-issues/configured-permissions.png"::: - -## Troubleshoot steps - -### Step 1: Get the sign-in request sent to Microsoft Entra ID - -To determine why the consent prompt appears, get the sign-in request and examine the parameters sent to Microsoft Entra ID. When the consent prompt appears, you can get the sign-in request by using one of the following methods: - -- If you're using a browser, view the address bar. -- If you're not using a browser or still can't see the address bar in the browser, use an HTTP capture tool like Fiddler to get the request. - -A sign-in request should look like the following one: - -- V1 OAuth2 endpoint: - - `https:////oauth2/authorize?client_id=&response_type=code&redirect_uri=&resource=&scope=&prompt=` - -- V2 OAuth2 endpoint: - - `https:////oauth2/v2.0/authorize?client_id=&response_type=code&redirect_uri=& scope=&prompt=` - -The following table provides an example of the parameters used in a sign-in request, which are referenced throughout the following troubleshooting steps: - -|Property| Sign-in request portion| Value| -|---|---|---| -|Aad-Instance| ``| login.microsoftonline.com| -|Tenant-ID| `` portion of the sign-in request| common| -|App-ID| `` portion of the sign-in request| 1f92960d-1442-4cd2-8c76-d13c5dcb30bf| -|Scope| `` portion of the sign-in request| Openid+User.Read+Directory.Read.All| -|App-URI-ID| V1 endpoint: `` portion of the sign-in request

V2 endpoint: For resources other than Microsoft Graph, this will be the portion before the scope name. For example, for `https://analysis.windows.net/powerbi/api/App.Read.All`, `App.Read.All` is the scope name, so the `App-URI-ID` is `https://analysis.windows.net/powerbi/api`.| https://graph.microsoft.com| -|Prompt| `` portion of the sign-in request || - -### Step 2: Verify if you allow users to consent - -To check if user consent is allowed in your organization, follow these steps: - -1. Sign in to the Azure portal. -2. Navigate to Microsoft Entra ID, and select **Enterprise applications** > **Consent and permissions**. -3. Review the **User consent for applications** setting: - - - If **Allow user consent for apps** is selected, all users can consent to permissions that don't require admin consent. In this case, go to the next step. - - - If **Do not allow user consent** is selected, users will always receive the "Need admin approval" message. In this case, an admin must [perform admin consent](#perform-admin-consent). - - > [!NOTE] - > If an admin believes they have already consented to those permissions, most likely, not all of the required permissions listed in the sign-in request were consented to, or the wrong application was used based on the ``. - -### Step 3: Verify if the application exists - -To verify if the application exists in the tenant, follow these steps: - -1. Sign in to the Azure portal. -2. Switch to the correct tenant based on the ``. -3. Go to **Enterprise applications**. -4. Set **Application Type** to **All Applications** and search for the ``. -5. If the application isn't found, this is why you experience consent issues. In this case, [perform admin consent](#perform-admin-consent). If the application is found, go to the next step. - -### Step 4:Verify if user assignment is required - -In the **Enterprise applications** pane, search for and select the application. Under the **Manage** section, select **Properties** to open the **Properties** pane, and then review the **Assignment required** setting. - -If user assignment is required, an admin must consent to this application. To do so, go to the [perform admin consent](#perform-admin-consent) section. - -> [!NOTE] -> Consenting to an application for all users in an organization doesn't allow all users to access the application. You must follow the user assignment rules. Only those users assigned to the application can access it. If you don't want to perform admin consent, the only workaround is to turn off **Assignment required**, ask users for consent when they access the application, and then turn **Assignment required** back on. - -If user assignment isn't required, go to the next step. - -### Step 5: Compare permissions requested and granted for the application - -To verify if the scopes (also called permissions) in the sign-in request are listed in the **Permissions** section of the application, follow these steps: - -1. If the application is found in [Step 3: Verify if the application exists](#step-3-verify-if-the-application-exists), select it. -2. Go to **Permissions**. -3. Compare what is listed in the **Permissions** pane and what is listed as `` in the sign-in request. The permissions listed in the **Permissions** pane are those that have been consented to. - - > [!NOTE] - > - Pay attention to the permission type. Delegated permissions are for when users sign in, and application permissions are for when the service principal is used to authenticate via the client credential flow. - > - OpenID Connect scopes are generally not listed in enterprise applications. Don't worry if the following scopes aren't listed: - > - > - `openid`: Sign users in - > - `email`: View users' email address - > - `profile`: View users' basic profile - > - `offline_access`: Maintain access to data you have given it access to - -4. If `` in the sign-in request is blank or contains less than what is listed in the **Permissions** pane, go to the next step. If other scopes in `` aren't in the **Permissions** pane, go to the [Perform admin consent](#perform-admin-consent) section. The missing permissions must be consented to. - -### Step 6: Verify if the resource exists in your tenant - -To check if a resource exists, try a request that looks like `https:////oauth2/authorize?response_type=code&client_id=&resource=`. - -You might encounter one of the following behaviors or errors: - -- You're allowed to sign in (this is the behavior you expect). In this case, go to the next step. In most cases, if you see the `code` parameter in the address bar, it means the authentication process was successful. -- Error AADSTS650052: The app needs access to a service that your organization has not subscribed to or enabled. Contact your IT Admin to review the configuration of your service subscriptions. - - This error means the resource doesn't exist in your organization. To resolve this issue, use this consent URL: `https://login.microsoftonline.com//oauth2/authorize?response_type=code&client_id=&prompt=admin_consent` - -- Error AADSTS650057: Invalid resource. The client has requested access to a resource which is not listed in the requested permissions in the client's application registration. Client app ID: \(\). Resource value from request: '\'. Resource app ID:\. List of valid resources from app registration: 00000002-0000-0000-c000-000000000000 - - In order for a client application to sign in and get an access token for a resource, the resource must be assigned the required API permissions that the client application requires, such as access to Azure Key Vault. - - :::image type="content" source="media/troubleshoot-consent-issues/azure-key-vault.png" alt-text="Screenshot that shows how to add Azure Key Vault to API permissions."::: - - > [!NOTE] - > Only the application owner can do this operation. - -- Error AADSTS500011: The resource principal named '\' was not found in the tenant named '\'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant. - - This error means that the specified `` is invalid or only available as a single-tenant application. Otherwise, it means this resource can't be accessed by external organizations or doesn't exist. - - To resolve this issue, you must work with the application owner to verify that the `` and `` are correct. If the `` is owned by a different ``, then the app registration for `` must be set up as a multi-tenant application. Otherwise, the `` must be the same tenant as where the app registration for `` is located. - -### Step 7: Verify if the prompt parameter is passed - -Sometimes, signing in to the application requires passing the `prompt` parameter of `consent` or `admin_consent`. Once the application obtains consent, make sure the `prompt` parameter isn't specified. Otherwise, users might always receive a consent error. - -Your sign-in request might look like this: - -`https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent` - -So, to resolve consent issues, remove the `prompt` parameter as follows: - -`https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All` - -## Perform admin consent - -To resolve consent issues, perform admin consent by following these steps: - -1. Have an administrator (a user with the Global Administrator, Company Administrator, or Application Administrator role) access the application. -2. If the consent screen appears, review the requested permissions. To approve the requested permissions, select the **Consent on behalf of your organization** checkbox. - - :::image type="content" source="media/troubleshoot-consent-issues/consent-on-behalf-of-your-organization.png" alt-text="Screenshot that shows the 'Consent on behalf of your organization' checkbox."::: - - > [!NOTE] - > If an administrator isn't sure what the permissions allow, the administrator must work with the application vendor to understand the permissions and their use. Microsoft support might not know what these permissions do or why they're needed. - -3. If the administrator doesn't get the consent screen, grab the sign-in address, add `&prompt=consent` to the end, and then use this request to perform admin consent. - - Here's an example: `https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile&tresource=https://graph.microsoft.com&prompt=consent` - - If the requested permissions aren't listed in the application registration, use the Microsoft identity platform (V2) endpoint to force admin consent. V2 endpoint requires each permission scope to be passed in the `scope` parameter as follows: - - `https://login.microsoftonline.com/contoso.onmicrosoft.com/oauth2/v2.0/authorize?client_id=1f92960d-1442-4cd2-8c76-d13c5dcb30bf&response_type=code&redirect_uri=https://www.contoso.com&scope=openid+profile+User.Read+Directory.Read.All&prompt=consent` - -> [!NOTE] -> - Permission scopes used by the application must be provided by the application owner. -> - Consent for application permissions will always require admin consent from a global or company administrator. Application permissions must be added within the application registration in the application's owning tenant. -> - Application admins can also consent to delegate permissions that require admin consent. -> - When using the admin consent URL, the permissions must already be configured with the application registration. Otherwise, the application owner must have their application correctly configured with Microsoft Entra ID. An admin consent URL looks like `https://login.microsoftonline.com//adminconsent?client_id=`. - -## More information - -### Consent - -In most cases, certain permissions that require consent haven't been consented. Therefore, consent is requested. To understand the consent, see the following pages: - -- [Overview of permissions and consent in the Microsoft identity platform](/entra/identity-platform/permissions-consent-overview) -- [Microsoft identity platform admin consent protocols](/entra/identity-platform/v2-admin-consent) -- [Microsoft Entra app consent experiences](/entra/identity-platform/application-consent-experience) - -### Application registrations and enterprise applications - -In Microsoft Entra, there's an application model that consists of application objects (also called "application registrations") and service principal objects (also called "enterprise applications"). How their relationship works together based on the required permissions is set on the application object. For more information, see [Application and service principal objects in Microsoft Entra ID](/entra/identity-platform/app-objects-and-service-principals). - -Simply adding permissions to an application registration doesn't consent to the permissions. To consent to permissions, you must assign permissions to the service principal. - -### Delegated permissions and application permissions - -There are two types of permissions in Microsoft Entra ID: delegated permissions and application permissions. Make sure you apply the correct permission configuration in the application registration and consent to that permission. - -For more information about permissions in Microsoft Entra ID, see the following pages: - -- [Overview of permissions and consent in the Microsoft identity platform](/entra/identity-platform/permissions-consent-overview) -- [Understanding the difference between application and delegated permissions from OAuth2 Authentication Flows](https://blogs.aaddevsup.xyz/2019/07/understanding-the-difference-between-application-and-delegated-permissions-from-oauth2-authentication-flows-perspective/) - -### Collect Microsoft Entra activity logs - -You can use the Microsoft Entra activity logs to get more details. To do so, follow these steps: - -1. Sign in to the Azure portal by using an account that has permission to read audit logs, such as a Global Administrator or Security Reader. -2. Go to Microsoft Entra ID. -3. Select **Audit logs** under the **Monitoring** section. -4. Set your filter as follows: - - **Category**: **ApplicationManagement** - - **Status**: **Failure** - - **Activity**: **Consent to application** -5. Find and select the app that fails to consent. -6. Review the **STATUS REASON** to get more details. - -In certain scenarios, you're required to perform admin consent even though you might allow users to consent and the permission normally doesn't require an admin to consent. For example, when the status reason shows "Microsoft.Online.Security.UserConsentBlockedForRiskyAppsException." For more information, see [Unexpected error when performing consent to an application](/entra/identity/enterprise-apps/application-sign-in-unexpected-user-consent-error#requesting-not-authorized-permissions-error) and [Unexpected consent prompt when signing in to an application](/entra/identity/enterprise-apps/application-sign-in-unexpected-user-consent-prompt). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file diff --git a/support/entra/entra-id/app-integration/troubleshoot-error-idx10501-aspnet-b2c.md b/support/entra/entra-id/app-integration/troubleshoot-error-idx10501-aspnet-b2c.md deleted file mode 100644 index f5a6a8ea291..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-error-idx10501-aspnet-b2c.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: Troubleshoot IDX10501 Error in ASP.NET Core app with Azure B2C Custom Policy -description: Provides guidance for troubleshooting the IDX10501 error in ASP.NET Core with Azure B2C. -ms.date: 01/06/2025 -ms.author: markbukovich -ms.service: entra-id -ms.custom: sap:Microsoft Entra App Integration and Development ---- - -# IDX10501 error in ASP.NET Core app with Azure B2C custom policy - -This guide discusses the cause of the "IDX10501" error, and provides a step-by-step solution to resolve it. - -## Symptoms -When you [implement a custom policy](/azure/active-directory-b2c/enable-authentication-web-application-options#pass-the-azure-ad-b2c-policy-id) in an ASP.NET Core application that integrates with Azure Active Directory B2C (Azure AD B2C), you might encounter the following IDX10501 error: - -> IDX10501: Signature validation failed. Unable to match key: kid: '[PII of type 'System.String' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'. Number of keys in TokenValidationParameters: '0'. Number of keys in Configuration: '1'. Exceptions caught: '[PII of type 'System.Text.StringBuilder' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'. token: '[PII of type 'System.IdentityModel.Tokens.Jwt.JwtSecurityToken' is hidden. For more details, see https://aka.ms/IdentityModel/PII.]'. - -## Understanding the error - -Why is this error generated when the custom policy redirects to your app? In ASP.NET Core, whenever a user is authenticated and authorized, and a redirect page exists to the web app that contains an ID token, ASP.NET Core middleware tries to validate this ID token to make sure that the redirect is genuine. To validate the ID token, the middleware requires the public key of the signing certificate that was used to sign the ID token. The middleware gets this public key by querying Azure Active Directory B2C. Specifically, the middleware uses a "metadata" endpoint in Azure Active Directory B2C that provides authentication information, including any public keys for signing certificates. - -When you create a custom policy, you're required to create or upload a signing certificate. This signing certificate is different from that used for built-in user flows in Azure Active Directory B2C. This means that the public keys that are accessible from the "metadata" endpoint for your Azure Active Directory B2C won't contain the public key for your custom policy. The custom policy actually has its own metadata endpoint. - -The endpoint that the middleware uses is configured by Microsoft.Identity.Web and is set at app startup. Because the metadata URL is already set, invoking a custom policy during runtime creates a scenario in which the middleware is looking at the wrong metadata URL while it validates the returning token. - -## Solution - -To resolve this issue, you must configure the correct metadata endpoint for the additional custom policy. To do this, create a second authentication scheme to handle the custom policy. By having this additional authentication scheme, you can set the correct metadata endpoint at startup. This process uses the following steps: - -1. Add an additional redirect URI to your app registration. -2. Configure an additional B2C authentication scheme in your app. -3. Add an action to the desired controller. -4. Implement the created action in the layout. - -Code sample: [ASP.NET Core Web App with Custom B2C Policy](https://github.com/mbukovich/ExtraB2CPolicyMVC). - -### Prerequisites - -Before you continue this process, make sure that you have: - -- An Azure B2C directory -- An app registration for B2C authentication -- [Standard user flows that are set up](/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-user-flow) -- [A custom B2C policy that's added to your directory](/azure/active-directory-b2c/tutorial-create-user-flows?pivots=b2c-custom-policy) -- An existing ASP.NET Core web app that's configured by having Microsoft.Identity.Web for B2C authentication - - For more information, see [Enable authentication in your own web app by using Azure AD B2C](/azure/active-directory-b2c/enable-authentication-web-application?tabs=visual-studio) - -### Step 1: Add an additional redirect URI - -In the app registration, you have to add another redirect URI for the custom policy. In this case, you can't use the existing redirect URI because it could cause confusion for the web app. You'll be setting up two different authentication schemes. However, when the B2C policy redirects to the web app, the middleware won't know which authentication scheme to use. Therefore, you need a separate redirect URI to clearly distinguish between redirects from the existing and new authentication schemes. - -Follow these steps: - -1. Navigate to your app registration in the [Azure portal](https://portal.azure.com). -2. In the **Manage** section, select **Authentication**. -3. In the **Redirect URIs** section, select **Add URI**. -4. Add a redirect URI. In this case, the new redirect URI is `https://localhost:44321/signin-oidc-editemail`. - - :::image type="content" source="media/troubleshoot-error-idx10501-aspnet-b2c/add-redirect-uri.png" alt-text="Screenshot of adding Redirect URIs." lightbox="media/troubleshoot-error-idx10501-aspnet-b2c/add-redirect-uri.png"::: - -> [!NOTE] -> Each custom policy requires its own redirect URI. For example, if you're adding two custom policies, you have to create two authentication schemes and two redirect URIs. - -### Step 2: Configure an Additional Authentication Scheme - -This process involves adding an action to your controller that issues a challenge to the user. Before you create this action, configure the app with an additional authentication scheme. This requires updating both the Appsettings.json file and the Startup.cs file. - -#### Update `Appsettings.json` - -Add the following configuration for your custom policy: - -```json -"": { - "Instance": "https://.b2clogin.com", - "ClientId": "", - "CallbackPath": "/", - "SignedOutCallbackPath": "/signout/", - "Domain": ".onmicrosoft.com", - "SignUpSignInPolicyId": "" -}, -``` - -Example of `Appsettings.json` - -```json -{ - "AzureADB2C": { - "Instance": "https://markstestorganization1.b2clogin.com", - "ClientId": "09717d12-ca7f-4388-8393-dafe42c0c3a5", - "CallbackPath": "/signin-oidc", - "SignedOutCallbackPath": "/signout/B2C_1_signupsignin1", - "Domain": "markstestorganization1.onmicrosoft.com", - "SignUpSignInPolicyId": "B2C_1_signupsignin1", - "ResetPasswordPolicyId": "B2C_1_PasswordReset1", - "EditProfilePolicyId": "B2C_1_editProfileTest1" - }, - "AzureADB2CEditEmail": { - "Instance": "https://markstestorganization1.b2clogin.com", - "ClientId": "09717d12-ca7f-4388-8393-dafe42c0c3a5", - "CallbackPath": "/signin-oidc-editemail", - "SignedOutCallbackPath": "/signout/B2C_1_signupsignin1", - "Domain": "markstestorganization1.onmicrosoft.com", - "SignUpSignInPolicyId": "B2C_1_signupsignin1" - }, - "Logging": { - "LogLevel": { - "Default": "Information", - "Microsoft": "Warning", - "Microsoft.Hosting.Lifetime": "Information" - } - }, - "AllowedHosts": "*" -} -``` -**Important considerations** - -- You can choose any name for the second B2C configuration. This configuration will be used for a single custom policy. If you have to add more custom policies, you must include additional B2C configurations in the AppSettings.json file. For this reason, we recommend that you give the JSON object a name that reflects the associated custom policy. -- The CallbackPath value is the portion of the redirect URI that follows the domain. For example, if your redirect URI is `https://localhost:44321/signin-oidc-editemail`, then CallbackPath will be `/signin-oidc-editemail`. -- You must include the standard built-in sign-up/sign-in user flow in the authentication scheme to make sure that users are prompted to sign in if they try to access your custom policy without being signed-in. - -#### Update `Startup.cs` - -Configure an additional authentication scheme in the Startup.cs file. In the `ConfigureServices` function, add the following code: - -```csharp -// Create another authentication scheme to handle extra custom policy -services.AddAuthentication() - .AddMicrosoftIdentityWebApp(Configuration.GetSection(""), "", ""); - -services.Configure("", options => - { - options.MetadataAddress = ""; - }); -``` - -- You have to set custom names for both your authentication scheme and the associated cookie scheme. Microsoft.Identity.Web will create these schemes by using the names that you specify. - -- Replace `` with the name of the JSON configuration from the previous step. Per the example in this article, this should be `AzureADB2CEditEmail`. - -- Replace `` with the OpenID Connect discovery endpoint URL that's found under your custom policy in Azure AD B2C. - -#### How to get the metadata address for custom policy - -It's important to get the metadata address because this will be used by the middleware to get the required information to validate ID tokens that are returned by the custom policy. - -To find the metadata address, follow these steps: - -1. Log in to the Azure B2C portal. -1. In **Policies** section, select **Identity Experience Framework**. - - :::image type="content" source="media/troubleshoot-error-idx10501-aspnet-b2c/find-identity-exp-fr.png" alt-text="Screenshot of the Identity Experience Framework button."::: -1. Select **Custom policies**, and then select the custom policy that you're using. In this case, it's **B2C_1A_DEMO_CHANGESIGNINNAME**. - - :::image type="content" source="media/troubleshoot-error-idx10501-aspnet-b2c/custom-policy.png" alt-text="Screenshot of checking custom-policy."::: -1. The metadata address is the URL that's listed under **OpenId Connect Discovery Endpoint**. Copy this URL, and paste it as the value for the `options.MetadataAddress` variable. - -### Step 3: Add an action to the controller - -In your controller, implement an action to trigger the Custom B2C Policy challenge for the user. In code sample, the action is added to the Home Controller for simplicity. Add the following code to your controller, and adjust the values and action name to meet your scenario. This code snippet can be found on line 40 of the `HomeController.cs` file in the `Controllers` folder in the code sample: - -```csharp -[Authorize] -public IActionResult EditEmail() -{ - var redirectUrl = Url.Content("~/"); - var properties = new AuthenticationProperties { RedirectUri = redirectUrl }; - properties.Items["policy"] = "B2C_1A_DEMO_CHANGESIGNINNAME"; - return Challenge(properties, "B2CEditEmail"); -} -``` - -Make sure that `` matches your specific policy name and `` is consistent with what you configured earlier. - -### Step 4: Implement action in layout - -Implement the action in the layout so that the user can actually invoke the custom policy. In the code sample, the following snippet adds a button alongside the existing B2C buttons, based on the [tutorial](/azure/active-directory-b2c/enable-authentication-web-application). The snippet is added to line 13 of the `_LayoutPartial.cshtml` file in the `Views/Shared` folder. Note that the `asp-controller` property is set to `Home` to reference the Home Controller, and the `asp-action property` is set to `EditEmail` to reference the action that's created in the Home Controller. For more information, see [Add the UI elements](/azure/active-directory-b2c/enable-authentication-web-application?tabs=visual-studio#step-4-add-the-ui-elements). - -```html -
  • -
    - -
    -
    • -``` - -If you have an existing app that doesn’t use the partial layout, and you want only a quick link to test the custom policy, you can use the following tag to create a basic link. Make sure that you replace the indicated values and reference the correct controller if you didn’t add your action to the Home Controller. - -```html -Replace with text that describes the action -``` - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-oidc-http-infinite-redirection.md b/support/entra/entra-id/app-integration/troubleshoot-oidc-http-infinite-redirection.md deleted file mode 100644 index 50530da261e..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-oidc-http-infinite-redirection.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Infinite redirection between OpenID Connect app and Entra ID -description: Provides guidance for troubleshooting infinite redirection between the OpenID Connect app and Entra ID. -ms.date: 12/26/2024 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Microsoft Entra App Integration and Development ---- - -# Troubleshoot infinite redirection between OIDC app and Entra ID - -This article describes an infinite redirection issue that exists between an OpenID Connect (OIDC) application and Microsoft Entra ID. - -## Symptoms - -When you browse to a website that's built by using an OpenID Connect (OIDC) app and Microsoft Entra ID, the browser enters an infinite loop that forms between the website and the Microsoft Entra ID authentication process. - -The issue specifically occurs when you browse the website by using the HTTP protocol. When you use HTTPS, the issue doesn't occur. - -## Cause - -The `.AspNet.Cookies` cookie isn't sent in HTTP requests because of its secure attribute. - -## Solution: Enforce HTTPS navigation - -To resolve the issue, enforce HTTPS navigation for the site. HTTPS is always recommended for sites that require authentication. - -## Workaround - -If your scenario requires the initial navigation to occur over HTTP, you can customize the Cookies Authentication middleware to allow the authentication AspNet cookie for both the HTTP and HTTPS schemes by setting the `CookieSecure` attribute to `CookieSecureOption.Never`, as shown in the following `Startup.Auth.cs` file. - -> [!Note] -> This workaround isn't recommended for production environments because it compromises security by allowing cookies to be sent over HTTP. - -```csharp -public void ConfigureAuth(IAppBuilder app) - { - app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); - app.UseCookieAuthentication(new CookieAuthenticationOptions - { - CookieSecure = CookieSecureOption.Never - }); - - app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - ClientId = clientId, - Authority = authority, - -} - } -``` - -This issue is discussed also in [this ASP.NET Security Blog article (Issue #219)](https://github.com/aspnet/Security/issues/219). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-rabc-issues-webassembly-auth-apps.md b/support/entra/entra-id/app-integration/troubleshoot-rabc-issues-webassembly-auth-apps.md deleted file mode 100644 index 1ba81a8c0f8..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-rabc-issues-webassembly-auth-apps.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: WebAssembly App Error - These requirements were not Met RolesAuthorizationRequirement in Microsoft Entra ID -description: This article provides guidance to resolve role-based access control issues in developing WebAssembly authentication apps. -ms.date: 03/20/2025 -ms.author: willfid -ms.service: entra-id -ms.custom: sap:Microsoft Entra App Integration and Development ---- - -# Add role claim support in WebAssembly authentication in Microsoft Entra ID - -This article provides guidance to resolve role-based access control issues in developing WebAssembly authentication apps. - -## Symptoms - -When you build a WebAssembly authentication app and try to implement role-based access control in the app, you receive the following error messages: -- You are not authorized to access this resource. -- Microsoft.AspNetCore.Authorization.DefaultAuthorizationService[2]Authorization failed. These requirements were not met: RolesAuthorizationRequirement:User.IsInRole must be true for one of the following roles: (ROLE_NAME) - -## Cause - -The WebAssembly authentication stack might cast role claims into a single string. This prevents proper role-based access control. - -## Solution - -You can implement a custom user factory to modify the behavior of role claims mapping. To do this, follow these steps. - -#### Step 1: Create a custom user factory - -Create a custom User Factory (CustomUserFactory.cs): - -```csharp -using Microsoft.AspNetCore.Components.WebAssembly.Authentication; -using Microsoft.AspNetCore.Components.WebAssembly.Authentication.Internal; -using System.Security.Claims; -using System.Text.Json; - -public class CustomUserFactory : AccountClaimsPrincipalFactory -{ - public CustomUserFactory(IAccessTokenProviderAccessor accessor) - : base(accessor) - { - } - - public async override ValueTask CreateUserAsync( - RemoteUserAccount account, - RemoteAuthenticationUserOptions options) - { - var user = await base.CreateUserAsync(account, options); - var claimsIdentity = (ClaimsIdentity?)user.Identity; - - if (account != null && claimsIdentity != null) - { - MapArrayClaimsToMultipleSeparateClaims(account, claimsIdentity); - } - - return user; - } - - private void MapArrayClaimsToMultipleSeparateClaims(RemoteUserAccount account, ClaimsIdentity claimsIdentity) - { - foreach (var prop in account.AdditionalProperties) - { - var key = prop.Key; - var value = prop.Value; - if (value != null && (value is JsonElement element && element.ValueKind == JsonValueKind.Array)) - { - // Remove the Roles claim with an array value, and create new claims with the same key - claimsIdentity.RemoveClaim(claimsIdentity.FindFirst(prop.Key)); - var claims = element.EnumerateArray().Select(x => new Claim(prop.Key, x.ToString())); - claimsIdentity.AddClaims(claims); - } - } - } -} -``` - -#### Step 2: Add role mapping and custom user factory to your authentication middleware - -If you're using `AddOidcAuthentication`: - -```csharp - -builder.Services.AddOidcAuthentication(options => -{ - builder.Configuration.Bind("AzureAd", options.ProviderOptions); - options.ProviderOptions.AdditionalProviderParameters.Add("domain_hint", "contoso.com"); - options.ProviderOptions.DefaultScopes.Add("User.Read"); - options.UserOptions.RoleClaim = "roles"; - options.ProviderOptions.ResponseType = "code"; -}).AddAccountClaimsPrincipalFactory(); -``` - -If you're using `AddMsalAuthentication`: - -```csharp -builder.Services.AddMsalAuthentication(options => -{ - builder.Configuration.Bind("AzureAd", options.ProviderOptions.Authentication); - options.ProviderOptions.AdditionalScopesToConsent.Add("user.read"); - options.ProviderOptions.DefaultAccessTokenScopes.Add("api://{your-api-id}"); - options.UserOptions.RoleClaim = "roles"; -}).AddAccountClaimsPrincipalFactory(); -``` - -#### Step 3: Add the `Authorize` attribute to Blazor pages - -```csharp -@attribute [Authorize(Roles="access_as_user")] -``` - -Next, add app roles to your app registration, assign a user to the app role, and then configure your app to use the assigned app role. - -## References - -- [Secure an ASP.NET Core Blazor WebAssembly standalone app with the Authentication library](/aspnet/core/blazor/security/webassembly/standalone-with-authentication-library) - -- [GitHub project: Sample that has this solution implemented](https://github.com/willfiddes/aad-webassembly-auth) diff --git a/support/entra/entra-id/app-integration/troubleshoot-sign-in-saml-based-apps.md b/support/entra/entra-id/app-integration/troubleshoot-sign-in-saml-based-apps.md deleted file mode 100644 index ebeee7a36a2..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-sign-in-saml-based-apps.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Problems signing in to SAML-based Single Sign-On configured apps -description: Guidance for the specific errors when signing into an application you have configured for SAML-based federated Single Sign-On with Microsoft Entra ID. -ms.date: 07/18/2023 -ms.reviewer: bernawy -ms.service: entra-id -ms.custom: sap:Issues Signing In to Applications ---- - -# Problems signing in to SAML-based Single Sign-On configured apps - -To troubleshoot the sign-in issues below, we recommend the following to better diagnosis and automate the resolution steps: - -- Install the [My Apps Secure Browser Extension](/azure/active-directory/manage-apps/my-apps-deployment-plan) to help Microsoft Entra ID to provide better diagnosis and resolutions when using the testing experience in the Azure portal. -- Reproduce the error using the testing experience in the app configuration page in the Azure portal. Learn more on [Debug SAML-based Single Sign-On applications](/azure/active-directory/manage-apps/debug-saml-sso-issues) - -If you use the [testing experience](/azure/active-directory/manage-apps/debug-saml-sso-issues) in the Azure portal with the My Apps Secure Browser Extension, you don't need to manually follow the steps below to open the SAML-based Single Sign-On configuration page. - -To open the SAML-based Single Sign-On configuration page: - -1. Open the [**Azure portal**](https://portal.azure.com/) and sign in as a **Global Administrator** or **Coadmin**. -1. Open the **Microsoft Entra Extension** by selecting **All services** at the top of the main left-hand navigation menu. -1. Type **“Microsoft Entra ID"** in the filter search box and select the **Microsoft Entra ID** item. -1. Select **Enterprise Applications** from the Microsoft Entra left-hand navigation menu. -1. Select **All Applications** to view a list of all your applications. - - If you do not see the application you want show up here, use the **Filter** control at the top of the **All Applications List** and set the **Show** option to **All Applications**. - -1. Select the application you want to configure for Single Sign-On. -1. Once the application loads, select **Single Sign-On** from the application’s left-hand navigation menu. -1. Select SAML-based SSO. - -## General troubleshooting - -### Problem when customizing the SAML claims sent to an application - -To learn how to customize the SAML attribute claims sent to your application, see [Claims mapping in Microsoft Entra ID](/azure/active-directory/develop/active-directory-claims-mapping). - -### Errors related to misconfigured apps - -Verify both the configurations in the portal match what you have in your app. Specifically, compare Client/Application ID, Reply URLs, Client Secrets/Keys, and App ID URI. - -Compare the resource you’re requesting access to in code with the configured permissions in the **Required Resources** tab to make sure you only request resources you’ve configured. - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-validation-context-nonce-null-mvc.md b/support/entra/entra-id/app-integration/troubleshoot-validation-context-nonce-null-mvc.md deleted file mode 100644 index 23f24570a6b..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-validation-context-nonce-null-mvc.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Resolving nonce validation errors in ASP.NET MVC with OpenID Connect -description: This article provides solutions to the common nonce validation errors that are encountered in ASP.NET MVC apps by using OpenID Connect middleware. -ms.date: 01/02/2025 -ms.author: bachoang -ms.service: entra-id -ms.custom: sap:Developing or Registering apps with Microsoft identity platform ---- - -# "ValidationContext.Nonce is null" errors in ASP.NET MVC apps - -This article provides solutions to the common nonce validation errors that you might encounter in ASP.NET MVC apps by using OpenID Connect (OIDC) middleware. - -## Common error messages - -Depending on the version of Open Web Interface for .NET (OWIN) that you use, you might receive one of the following error messages: - -- IDX21323: RequireNonce is '[PII is hidden by default. Set the 'ShowPII' flag in IdentityModelEventSource.cs to true to reveal it.]'. OpenIdConnectProtocolValidationContext.Nonce was null, OpenIdConnectProtocol.ValidatedIdToken.Payload.Nonce was not null. The nonce cannot be validated. If you do not need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to false. - -- IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you do not need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to false. - -## Understanding nonce cookies - -The ASP.NET OIDC middleware uses a nonce cookie to prevent [replay attacks](/dotnet/framework/wcf/feature-details/replay-attacks). The app throws the exception if it can't find the nonce cookie in the authenticated request. Cookies are domain-based. This means that if the cookies are set for a specific domain, all subsequent requests to that domain will include the cookies until they expire or are deleted. - -The following Fiddler traces describe how these cookies are set and used in a working flow: - -- In Frame 116, the browser sends a request to the OIDC app that's protected by Microsoft Entra ID. After receiving the request, the app detects that it isn't authenticated. It then redirects the request to Microsoft Entra ID (`login.microsoftonline.com`) for authentication. Additionally, the app sets the `OpenIdConnect.nonce` cookie in the "302" redirect response. - - :::image type="content" source="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-start-auth.png" alt-text="Screenshot of Frame 116 in Fiddler Trace." lightbox="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-start-auth.png"::: - -- After successful authentication (Frame 120-228), Microsoft Entra ID redirects the request back to the web app (Frame 229) together with the authenticated ID token. The nonce cookie that was previously set for this domain is also included in the POST request. The OIDC middleware validates the authenticated token and the nonce cookie before it continues to load the page (through another redirect). At this point, the nonce cookie's purpose is finished, and the app invalidates it by setting the expiration attribute to expire. - - :::image type="content" source="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-after-auth.png" alt-text="Screenshot of Fiddler Trace Frames related to authentication." lightbox="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-after-auth.png"::: - -## Solution - -### Cause 1: Multiple domains are used for the same website - -The browser originally navigates to the app on Domain A (Frame 9), and the nonce cookie is set for this domain. Later, Microsoft Entra ID sends the authenticated token to Domain B (Frame 91). Because the redirection to Domain B doesn't include the nonce cookie, the web app throws the `validationContext.Nonce is null` error. - -:::image type="content" source="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-multiple-domains.png" alt-text="Screenshot of Fiddler Trace Frames related to Cause 1." lightbox="media/troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-multiple-domains.png"::: - -### Solution 1 - -To resolve this issue, follow these steps: - -1. Redirect the request back to the same domain that was originally used after authentication. To control where Azure AD sent the authenticated request back to the app, set the `OpenIdConnectAuthentications.RedirectUri` property in the `ConfigureAuth` method. - -1. Configure the redirect URI (reply URL) in App Registration. Otherwise you might receive the following error: AADSTS50011: The reply URL that's specified in the request doesn't match the reply URLs that Azure configured for the app. For more information, see [Error AADSTS50011 with OpenID authentication](error-code-aadsts50011-redirect-uri-mismatch.md). - -### Cause 2: Missing SameSite attributes - -Because of the [SameSite cookie security updates](/azure/active-directory/develop/howto-handle-samesite-cookie-changes-chrome-browser?tabs=dotnet), all cookies that are involved in the authentication process (including Nonce cookies) should contain the following attributes: - -- SameSite=None -- Secure - -For more information, see [SameSite cookies and the Open Web Interface for .NET](/aspnet/samesite/owin-samesite). - -![Screenshot of missing SameSite attributes Fiddler trace.](./media//troubleshoot-validation-context-nonce-null-mvc/fiddler-trace-misisng-samesite.png) - -### Solution 2 - -To make sure that both the required attributes are included, follow these steps: - -1. Use the HTTPS protocol to navigate to the web app. -1. Update .NET Framework and NuGet packages: - - For .NET Framework apps: Upgrade .NET Framework to version 4.7.2+ and relevant NuGet packages (Microsoft.Owin.Security.OpenIdConnect, Microsoft.Owin) to version 4.1.0+. - - For .NET Core apps: - - Version 2._x_ apps should use .NET Core 2.1+. - - Version 3._x_ apps should use .NET Core 3.1+. - -Example configuration code for Startup.Auth.cs: - -```csharp -using System.Configuration; -using Owin; -using Microsoft.Owin.Security; -using Microsoft.Owin.Security.Cookies; -using Microsoft.Owin.Security.OpenIdConnect; -using System.Threading.Tasks; -using Microsoft.Owin.Security.Notifications; -using Microsoft.IdentityModel.Protocols.OpenIdConnect; - -namespace NetWebAppOIDC2 -{ - public partial class Startup - { - private static string clientId = ConfigurationManager.AppSettings["ida:ClientId"]; - private static string aadInstance = ConfigurationManager.AppSettings["ida:AADInstance"]; - private static string tenantId = ConfigurationManager.AppSettings["ida:TenantId"]; - private static string postLogoutRedirectUri = ConfigurationManager.AppSettings["ida:PostLogoutRedirectUri"]; - private static string authority = aadInstance + tenantId; - - public void ConfigureAuth(IAppBuilder app) - { - app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType); - - app.UseCookieAuthentication(new CookieAuthenticationOptions()); - app.UseOpenIdConnectAuthentication( - new OpenIdConnectAuthenticationOptions - { - ClientId = clientId, - Authority = authority, - PostLogoutRedirectUri = postLogoutRedirectUri, - RedirectUri = "https://localhost:44313", - - Notifications = new OpenIdConnectAuthenticationNotifications - { - AuthenticationFailed = OnAuthenticationFailed - } - - // Don't use SystemwebCookieManager class here to override the default CookieManager because that seems to negate the SameSite cookie attribute that's being set. - // CookieManager = new SystemWebCookieManager() - - }); - } - - private Task OnAuthenticationFailed(AuthenticationFailedNotification context) - { - context.HandleResponse(); - context.Response.Redirect("/?errormessage=" + context.Exception.Message); - return Task.FromResult(0); - } - } -} -``` - -[!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/troubleshoot-wif10201-no-validkey-securitytoken-mvc.md b/support/entra/entra-id/app-integration/troubleshoot-wif10201-no-validkey-securitytoken-mvc.md deleted file mode 100644 index c4f256df6c4..00000000000 --- a/support/entra/entra-id/app-integration/troubleshoot-wif10201-no-validkey-securitytoken-mvc.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: ASP.NET MVC Application Error WIF10201 No Valid Key Mapping Found for SecurityToken -description: This article provides guidance for troubleshooting the error, WIF10201- No valid key mapping found for securityToken. -author: genlin -ms.author: bachoang -ms.service: entra-id -ms.topic: troubleshooting-problem-resolution -ms.date: 02/05/2025 -ms.custom: sap:Issues Signing In to Applications ---- - -# WIF10201: No valid key mapping found for securityToken error in ASP.NET application - -This article provides guidance for troubleshooting an authentication issue that occurs in an ASP.NET MVC application that uses both [WS-Federation](https://github.com/Azure-Samples/active-directory-dotnet-webapp-wsfederation) OWIN middleware and [Windows Identity Foundation](../../../windows-server/user-profiles-and-logon/windows-identity-foundation.md) (WIF) to authenticate to Microsoft Entra ID. - -## Symptoms - -The ASP.NET MVC application that was previously working generates the following error message although no changes were made to the application: - -```output -Error Details: -Server Error in '/' Application. -WIF10201: No valid key mapping found for securityToken: 'System.IdentityModel.Tokens.X509SecurityToken' and issuer: 'https://sts.windows.net//'. - -Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. - -Exception Details: System.IdentityModel.Tokens.SecurityTokenValidationException: WIF10201: No valid key mapping found for securityToken: 'System.IdentityModel.Tokens.X509SecurityToken' and issuer: 'https://sts.windows.net//'. -``` - -## Cause - -To validate the signature of the token that's returned by the Entra ID after a successful sign-in, WIF uses the certificate thumbprints that are in the **Web.config** file, as shown in the following example: - -```web.config - - - - - - - - - - - - -``` - -The "WIF10201" error occurs if none of these certificate thumbprints match the one that's used by Entra ID to sign the token. - -The Entra ID uses a [signing key rollover mechanism](/entra/identity-platform/signing-key-rollover) to update the certificate that's used to sign authentication tokens periodically. This key rollover causes the initial certificate thumbprints that are configured in the **Web.config** file to become invalid. - -## Solution - -You can either manually update the certificate thumbprints that are in the **Web.config** file or automate the process through code. For more information, see [Best practices for keys metadata caching and validation](/entra/identity-platform/signing-key-rollover#best-practices-for-keys-metadata-caching-and-validation). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] - diff --git a/support/entra/entra-id/app-integration/unable-delete-app.md b/support/entra/entra-id/app-integration/unable-delete-app.md deleted file mode 100644 index 1ed638b0120..00000000000 --- a/support/entra/entra-id/app-integration/unable-delete-app.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Unable to delete an application due to disabled Delete button -description: Understand why you're unable to delete an application due to disabled Delete button. -ms.date: 02/18/2024 -author: bernawy -ms.author: bernaw -editor: v-jsitser -ms.reviewer: v-leedennis, jarrettr -ms.service: entra-id -content_well_notification: AI-contribution -ai-usage: ai-assisted -ms.custom: sap:Enterprise Applications ---- -# Unable to delete an application due to disabled Delete button - -When deleting an app in Microsoft Entra ID, the Delete button may be disabled in certain scenarios. These scenarios include: - -- For applications under Enterprise application, the Delete button will be disabled if you don't have one of the following roles: Global Administrator, Cloud Application Administrator, Application Administrator, or owner of the service principal. - -- For Microsoft applications, you won't be able to delete them from the UI regardless of your role. - -- For service principals that correspond to a managed identity, you can't delete the service principals in the Enterprise apps blade. You need to go to the Azure resource to manage it. To learn more about Managed Identity, please refer to the article [Managed Identity](/azure/active-directory/managed-identities-azure-resources/overview). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/update-your-browser-error-when-using-apps-adal-msal.md b/support/entra/entra-id/app-integration/update-your-browser-error-when-using-apps-adal-msal.md deleted file mode 100644 index c3f46bdf016..00000000000 --- a/support/entra/entra-id/app-integration/update-your-browser-error-when-using-apps-adal-msal.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Your Browser is Not Supported or Up-to-Date Error in MSAL App -description: This article describes how to resolve the "Your browser is not supported or up-to-date" error when you use an app that integrates with MSAL. -author: genlin -ms.author: willfid -ms.service: entra-id -ms.date: 01/11/2025 -ms.custom: sap:Issues signing into application ---- - -# "Your browser is not supported or up-to-date" error in MSAL app - -This article discusses how to resolve the "Your browser is not supported or up-to-date" error that occurs in a Microsoft Authentication Library (MSAL)-based app. - -## Symptoms - -When you open an app that integrates with MSAL, and you try to register Microsoft Entra ID Multifactor Authentication (MFA), you receive the following error message: - ->Your browser is not supported or up-to-date. Try updating it, or else download and install the latest version of Microsoft Edge. -You could also try to access https://aka.ms/mysecurityinfo from another device. - -## Cause - -This issue occurs if the MSAL app uses outdated web browser controls, such as WebView1. These older controls don't support Microsoft Entra ID MFA registration or the self-service password reset wizard. - -## Resolution - -### For users - -To work around this issue, register for Microsoft Entra ID Multifactor Authentication (MFA) by using a supported browser before you use the app: - -1. Open [My Apps](https://myapps.microsoft.com) in Microsoft Edge or another supported browser. -2. Complete the MFA registration process. -3. After successful registration, open the app. - -## For developers - -To resolve this issue, enable broker authentication by using [Web Account Manager](/entra/identity-platform/scenario-desktop-acquire-token-wam) in the app. - -The following sample code creates a client to use Broker Authentication: - -```csharp -var pca = PublicClientApplicationBuilder.Create("client_id").WithBroker(new BrokerOptions(BrokerOptions.OperatingSystems.Windows)) -``` - -If Web Account Manager is unavailable (such as on Windows Server 2012), consider using the [default system browser for authentication](/entra/msal/dotnet/acquiring-tokens/using-web-browsers#how-to-use-the-default-system-browser). - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] diff --git a/support/entra/entra-id/app-integration/use-netlog-capture-network-traffic.md b/support/entra/entra-id/app-integration/use-netlog-capture-network-traffic.md deleted file mode 100644 index 02d9b64ffb0..00000000000 --- a/support/entra/entra-id/app-integration/use-netlog-capture-network-traffic.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Use NetLog to Capture Network Activity -description: Provides guidance about using the Network Logs (NetLog) tool as an alternative to Fiddler and HTTP Archive (HAR) captures. -ms.reviewer: bachoang, v-weizhu -ms.date: 04/14/2025 -ms.service: entra-id -ms.topic: how-to -ms.custom: sap:Enterprise Applications ---- -# Use NetLog as an alternative to Fiddler and HAR captures - -This article provides guidance on using the Network Logs (NetLog) tool as an alternative to Fiddler and HTTP Archive (HAR) captures to diagnose network issues in Microsoft Entra. NetLog is built into Chromium-based browsers like Microsoft Edge, Google Chrome, and Electron. When standard Fiddler captures are unavailable or HAR captures from developer tools truncate necessary information, you can use NetLog to capture network activity. - -## Known limitations - -Before using NetLog, be aware of the following limitations: - -- POST request bodies aren't captured. -- Sites running in Internet Explorer compatibility mode aren't captured. - -Depending on the information you need, you might still need to use Fiddler or HAR captures. - -## Use NetLog in browsers - -Follow these steps to capture network activity using NetLog: - -1. (Optional but helpful) Close all browser tabs except one. -1. Navigate to NetLog: - - For Google Chrome: Open a new tab and go to `chrome://net-export`. - - For Microsoft Edge: Open a new tab and go to `edge://net-export`. -1. In the **Options** section, select **Include raw bytes (will include cookies and credentials)**. -1. Leave the **Maximum log size** field blank. -1. Select **Start Logging to Disk**. -1. Select a location (such as **Desktop**) to save the log file (**edge-net-export-log.json** or **chrome-net-export-log.json**). -1. In the same browser window, open a new tab. -1. Reproduce the issue. - - > [!NOTE] - > If you close or navigate away from the NetLog tab, the logging will stop automatically. -1. After reproducing the issue, return to the NetLog tab and select the **Stop Logging** button. -1. Locate the NetLog file saved in step 6. - -For more information, see [How to capture a NetLog dump](https://dev.chromium.org/for-testers/providing-network-details). - -## Use NetLog on mobile devices - -NetLog is supported on mobile versions of Microsoft Edge and Google Chrome: - -- Android: NetLog works in Edge and Google Chrome for Android. -- iOS: NetLog works in Google Chrome for iOS. - -On mobile devices, you have an email option to send the log. - -## View and analyze NetLog data - -You can view the NetLog file using the [online NetLog Viewer](https://netlog-viewer.appspot.com/#import). To do so, open the NetLog Viewer, select **File**, and then upload the exported NetLog file. - -You can use the following tabs in the NetLog Viewer to inspect different aspects of network activity: - -- **Events**: View detailed network events. -- **Proxy**: Check proxy settings. -- **Timeline**: Analyze request timing. -- **DNS**: Inspect Domain Name System (DNS) lookups. -- **Sockets**: Review Transmission Control Protocol (TCP) connections. -- **Cache**: Examine cached resources. - -[!INCLUDE [Third-party information disclaimer](../../../includes/third-party-disclaimer.md)] - -[!INCLUDE [Azure Help Support](../../../includes/azure-help-support.md)] \ No newline at end of file