Have you run into the cryptical “AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.” error? I have. This post will tell you how to fix it.
How to fix AADSTS50059?
Request Id: <guid> Correlation Id: <guid> Timestamp: 2018-04-27T20:58:36Z Message: AADSTS50059: No tenant-identifying information found in either the request or implied by any provided credentials.
Okay – so the error claims Azure AD fails to recognize your tenant, as the request or provided credentials didn’t provide that. But is that even true?
The URL of the login page will look something like this:
So.. Wait a minute. The log-in URL actually has all the info about the tenant and everything! You should be able to log in with that. What’s wrong, then?
The issue is, that you’ve already got login information on your machine – just not the correct one for this tenant! It’s all cached in the Local Storage, and the info conflicts with what you have in the URL. So the whole login process is trying to implicitly use the wrong cached credentials to log in to the tenant automatically.
Solution: Remove everything related to ADAL from Local Storage
ADAL login, when successful, caches the login info into your browser’s local storage. That’s convenient, as it eliminates the need to log in again anytime soon, but in a situation where you’ll be authenticating against multiple Azure AD instances (such as when you’re switching between different SharePoint tenants running code against Graph API), it’ll mess up the authentication. You’ll be trying to use the wrong tenant’s info automatically – and there’s very little you can do about it by default!
The solution is simple – you’ll just need to clear the browser’s local storage. Below, I’m showing what to remove in case you’re using Google Chrome. You’ll need to hit F12 to open developer tools, browse to “Application” tab, and then find your tenant from the “Local Storage” -section.
After removing all the storage entries for ADAL, refresh the page that threw the error before, and you should be greeted with a fresh, neat login screen!
At this point, whatever you’re selecting, will then be cached for your browser, and used automatically the next time you try to log in again.
So, for now, you should be good!
Latest posts by Antti K. Koskela (see all)
- Fastest way to verify your Client Id and Client Secret are valid with PowerShell - August 9, 2018
- How to get the user count for Azure AD Enterprise Application - August 1, 2018
- Solving “Tenant app deployment is only supported in the app catalog site. The current site is not the app catalog site.” error - July 31, 2018
- Solving “Sorry, your files couldn’t be uploaded. The upload might be too large or the server might be experiencing high network traffic.” in SharePoint - July 24, 2018