Office365 authentication for the SDK & XrmToolBox

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.

https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/xrm-tooling/use-connection-strings-xrm-tooling-connect

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:

https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication

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.