One thing about Dynamics which I love and hate at the same time is that I’m constantly getting challenged. In the old days we had an on-premise system where the updates were rare, where we had access to the database, and where, to a certain extent, we were in control. At least it sometimes felt like this (and it’s such a nice memory, so let’s just pretend we never had to deal with the Generic SQL errors)
Things have changed, though, and Dynamics is now part of the huge online ecosystem which goes far beyond Dynamics or PowerPlatform. There are different concepts, principles, applications, and technologies involved there, and it’s almost impossible to know all of them.
However, and this is where that love-hate cliché comes into play, if you are working with Dynamics these days, you are almost inevitably getting exposed to the other parts of this ecosystem.
Anyway, if you think this post was too abstract so far, here is how my morning started today:
- XrmToolBox was not connecting to the Dynamics instances
- Deployment automation scripts were throwing errors
And, yet, Dynamics was working just fine in the browser or when we tried PluginRegistration tool
Besides, XrmToolBox and some console applications (which were using SDK) were connecting just fine to the Dynamics instance hosted in another tenant.
Have I mentioned that it was all working yesterday?
Having done a few more tests, we decided that it’s probably Office365 authentication that was not working anymore.
But why? Of course there were voices claiming Microsoft did a silent update..
This is where I should probably clarify that it is a relatively big environment, and not everyone working with Dynamics would have global administrator permissions. In other words, we don’t always know what’s happening in this tenant outside of Dynamics.
Turns out there are settings in the Azure Active directory we did not even know about. They were updated the night before by the tenant admins, and that affected our ability to use Office365 authentication.
Here is another link:
And here is a screenshot:
Yes, it turns out that it’s possible to disable Office365 authentication through the conditional access policies in the Azure Active Directory.
Once required exclusions were added there, everything went back to normal and we had XrmToolBox and other tools are working now.
And the takeaway? Well, just keep in mind that Office365 authentication falls into the category of legacy authentication methods, and, so, it can be disabled through the conditional access policies. So if you want it to work for the time being, and if you have conditional access policies set up as per the link above, you’ll need to make sure those policies implement all required exclusions.
PS. Why did we have to use Office365 authentication in the first place? Normally, we have multi-factor authentication enabled for the users. So we were looking at how to bypass the MFA for our tools(would not be very convenient if we had to go over the MFA process every time we wanted to prepare a nightly build, for example), and it turned out Office365 authentication ignores MFA. Which is, probably, one reason it is considered “legacy” from the policy standpoint.
Thank you for this post. I’m not sure why you call the O365 Auth as legacy. Can you clarify please. Ty
I’m not sure if it’s the right term.. There is a link in the post that’s describing how to use Conditional Access Policies to block legacy authentication, and that’s how we unintentionally got our Office365 authentication blocked (which we used in the SDK and/or XrmToolBox connection strings) authentication blocked. That policy does not block OAuth, though, so, in that sense, Office365 authentication is a legacy one
As per the documentation. I understand the reason of considering Office 365 as legacy, is only because there was no MFA setup. Once this setup it should be OK, even with this condition.
Hi Natraj, I don’t know enough about Azure security to be 100% certain.. But at least MFA is definitely there. Office365 authentication seems to ignore the MFA (actually, this is also interesting.. You can use app passwords to bypass the MFA.. or, as in our case, when MFA passwords are not even enabled, it seems Office 365 authentication simply ignores the MFA all the time)