A while ago, one of my colleagues contacted me with a login issue.
The colleague was trying to log into a customers environment (where she is a guest user) with her company account (from our company). When trying to login, this error appeared:
In Microsoft Entra ID, the is a functionality called Risky Sign-ins. Users that try to log in a “weird” way, for instance login from a Dutch IP one minute after login from a Swedish IP (there is a link at the bottom of the post with more detailed information.
This information is logged in EntraID and (sometimes) acted upon. The reason i say sometimes, is because the action part requires an EntraID P2 license.
When the colleague contacted me, I thought that this should not be happening, because we do not have EntraID P2 licenses for our users.
After some digging and looking at the colleagues account, in the Azure Portal, i saw that it had a risky login and when I cleared it, it started working.
Apparently the information about risky login follows the guest accounts over to our customers tenant and the customer had enforcement of risky users enabled… well, I learned something today as well đŸ™‚
Last week I needed to set up a new Dynamics 365 for Finance and Supply Chain environment and I for a strange error message which took some time to figure out.
AADSTS50011: The redirect URI 'https://enadvdemo01.operations.eu.dynamics.com/' specified in the request does not match the redirect URIs configured for the application '00000015-0000-0000-c000-000000000000'. 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.
(since I am not an EntraID expert I might be some details wrong in the explanation but this is what I think the issue is)
The issue here is that when you are working with D365FO, which is a Microsoft Saas-ish service, there is a Service Principal created for Microsofts application in your Entra ID tenant. When you set up a new environment, the URL for that environment is added to that Service Principal as two ReplyUrls. One for the base URL and one for the OAuth endpoint.
Apparently there is a limit (255) for how many of these URLs you can have for the Service Principal. This means that when you have deployed enough environments the property fills up. I am guessing that there might be a clean-up routine for these but that it might sometimes fail.
The solution is to remove a couple of old ones and manually add the new ones.