Error code 53003

by , Published on August 25, 2022August 25, 2022

Last Updated on 6 months

Microsoft is known for making quality software that doesn’t often run into errors, but when it does, it can cause major problems for the end user. Whether it’s Windows or something simple like Teams, these are essential programs that are used on a day-to-day basis and encountering fatal errors can cause issues. 

In this article, we’re taking a look at the error code 53003, its causes and what you can do to fix the problem. 

What causes this error code?

The error code can be triggered by a number of things, but the main reason lies in a conditional access bug in Microsoft’s servers. Other common causes include:

• Outdated target app.
• Outdated operating system version. 
• Invalid permissions.

Also read: Microsoft Teams exploratory license: Everything you need to know

How to fix this?

Here are seven fixes you can try out. 

Check your internet

When you see an error like this, you should first check if you’re connected to the internet. If you’re on WiFi, make sure you have a stable signal and an active internet connection. If you’re on mobile data, check to see if it’s enabled and that you have good network coverage.

Try logging in again

Invalid or outdated credentials in your Teams app can also cause these errors. Regardless of the platform, try logging out of teams and signing back in again to see if that resolves the error. 

Check for outages

A server outage from Microsoft’s end can also cause this error. You can check Microsoft’s Server Status website for Office applications or a third-party website like DownDetector to see if Teams is working as it should. If Teams is down, all you can do is wait for the service to come back online before giving it another shot. 

Clear the cache

Clearing the app’s cache can eliminate any corrupt files or data that might interfere with Team’s functionality.

• Tap on Apps and notifications.
• Tap on Show all apps and find Teens from the list. If you’ve recently used Teams, it’ll show up in the recent apps as well.
• Tap on Teams.

• Then tap on Storage & cache.
• Then tap on the Clear Cache button.

This should resolve the problem.

Check out our detailed guide on how to clear Microsoft Teams' cache on Windows here. 

Update your Teams app

More often than not, if you’re running an outdated app, it can cause problems. Head over to your respective app store to check if any updates are available. If they are, update your app and try again.

Check out our detailed guide on how to update Microsoft Teams on Windows here.

Update your OS

Another potential cause of the issue can be an outdated OS version. Whether you’re running Android, iOS or Windows, try updating your OS to the latest version available to see if that fixes the problem. 

Reinstall the app

Reinstalling your app can fix many issues, including those that cause your notifications to stop working. Regardless of whether you’re on Android or iOS,  try reinstalling the app to see if it resolves the issue.

Check out our detailed guide on how to reinstall Microsoft Teams on Windows here.

Also read: Teams.Microsoft.com refused to connect: 6 Fixes

EDIT — issue resolved. Issue was on other business’s side. Thank you!

received an invite from another business to join their Teams; however, I click to join, sign in but then receive an error when I start my Teams application.

«You cannot access this right now. Your sign-in was successful but does not meet the criteria to access this resource.»

Upon further investigation, it is error code 53003 and Azure states

Message: Access has been blocked by one or more Conditional Access policies with access controls configured to block.

Action: The user sign in was blocked by a conditional access policy. If this block was unexpected, review the conditional access policy configuration which applied to the sign in attempt. The conditional access policy can be found in the Azure AD sign in event entry in the Conditional Access tab. Simply click on the policy or policies to view the settings or change the settings as needed. If the block was an expected result for the sign in attempt more details can be found for review in the sign in event as well.

I just looked and we don’t have any conditional access policies — do I have to create one to allow access to Teams? I tried using the web application and the application itself — one note, we do have Okta and upon clicking to join the Teams invite it redirects me to sign into Okta, put in 2FA (as it always does) but then it fails. Any help would be greatly appreciated — thank you!

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.