Recently I’ve been troubleshooting conditional access policy errors in relation to applications failing to allow users to login to specific applications. Conditional Access Policies (CAPs), are at the heart of identity security for Azure at present, to manage access to your applications with various conditions like where the user is logging in from, defining trusted sites and setting different access controls e.g. MFA.

One specific issue I have been troubleshooting is an error code from the Microsoft Identity Platform: AADSTS53003. A user was able to login from one specific site without any issues, but from another location the user received this application error, which was identified in the backend logs of the application.

After reviewing the Azure AD Sign-in logs in the tenant, there was nothing specific showing what this error related to, when sign-in logs were checked against the application itself. There wasn’t much available in terms of troubleshooting this error apart from backend logs, so it was time to understand the user flow to determine why one physical site the user simply could not sign in at all, but at other sites everything was fine. The trusted site was valid for the application in the CAPs, so this made the troubleshooting process a little more challenging.

Back to the drawing board

After understanding where the application was failing, I developed a ASP.Net Core Blazor web application to start troubleshooting this issue in a completely separate environment. Knowing the application was trying to call MS Graph on-behalf-of the user, which then failed, it was an easy setup to recreate in a Blazor server-side application. I used the MS Graph Client and pulled across some basic profile properties for a user in the test tenant, with an on-behalf-of flow to display the results in a basic table.

As this was a application for debugging purposes, I also added a page element, to include any errors on the page component to display any code errors. In the above screen shot, no exceptions were found. Now I had a basis to start to troubleshoot the issues.

I setup my conditional access polices in a similar manner to the production Azure AD tenant to block access from untrusted sites.

I had setup a single policy, with a single test user and tested the policy based on location. A simple setup where I had my development office location and a VM in Azure with a public IP address, which was trusted as this was an exclusion in this case.

I setup a second policy to block access to Office 365, as the production application also had API permissions to access Office 365 and also enforced MFA for the user.

Testing

Now for the test. The user accessed the application from a trusted location, but this resulted in a successful page load, with MFA as applied in the CAPs. At this point my application was only calling Microsoft Graph, just like the production application. I wasn’t concerned with Office 365 APIs at this time.

I asked the user to sign into login.microsoftonline.com, as we all know this is the Microsoft Identity Platform endpoint for all user, device and application access, which contains all the components we need to authenticate with Azure AD, and of course where we receive the AADSTS53003 error as part of the application access token request flow. At this point the user received the following error, after entering their password, even though MFA was enforced.

This was somewhat confusing as the user could sign in with MFA into the application, with MFA, but accessing login.microsoftonline.com, to sign into the users Azure AD tenant actually failed with the above error, without MFA.

The Cause

A CAP was which blocked Office 365 from untrusted locations did not have the users location trusted IP address assigned for exclusion of the policy. Well that was an easy fix, but the the application that had issues signing the user in from another location, other than their home location, failed to provide them access with the AADSTS53003 error, when it call MS Graph. What comes next?

Re-creating the behavior

I wanted to re-create the behavior in my test Blazor application, so I determined that the error was not to do with the direct relationship with MS Graph, and started to add some scopes for SharePoint Online.

I then launched the application in Visual Studio, and hey presto!! the error was re-produced.

Why did this occur?

I determined that the error was not to do with the direct relationship with MS Graph, but the fact when the application was calling MS Graph, on-behalf-of the user, requesting an access token for the MS Graph resource, it was the fact the application had scopes assigned to access Office 365 API’s in it’s manifest. So this error was then simple to re-create, the Office 365 block policy required the users site to be trusted as part of an exclusion, so the application would not be blocked from requesting an access token for the MS Graph resource.

Hopefully, this post will help someone troubleshoot a similar error.