If you are working in the online environment where authentication requirements have started to shift towards the MFA, you might be noticing that tools like XrmToolBox (or even the SDK itself) are not always that MFA-friendly.
To begin with, MFA is always interactive – the whole purpose of multi-factor authentication is to ensure that you are who you are, not just somebody who managed to steal your username and password. Hence, there are additional verifications involved – be that an SMS message, an authenticator app on the phone, or, if you are that unlucky, a custom RSA token validation.
There are different ways to bypass the MFA.
If your organization is willing to relax security restrictions, you might get legacy authentication enabled, so you would be able to get away authenticating the old way – by providing a login/password within the connection string. Having had some experience with this, I think this solution is not quite viable. Security groups within the organizations will be cracking down on this approach, and, sooner or later, you may need something else.
Besides, MFA is not, always, Azure-based. In the hybrid environments where authentication is done through the on-premise ADFS, there could be other solutions deployed. To be fair, having to figure out how to connect XrmToolBox to the online org in this kind of environment is exactly why I ended up writing this blog post.
But the final explanation/solution is applicable to the other scenarios, too.
To be more specific, here is the scenario that did confuse XrmToolBox to the point of no-return:
It was all working well when I was connecting to CDS in the browser, but, as far as XrmToolBox was concerned, somehow it just did not want to work with this pattern.
The remaining part of this post may include some inaccuracies – I am not a big specialist in OAuth etc, so some of this might be my interpretation. Anyway, how do we make everything work in the scenario above?
This is where we need to look at the concept of OAuth applications. Basically, the idea is that we can register an application in the Azure AD, and we can give permissions to that App to use Dynamics API-s:
This would be great, but, if we wanted to bypass all the 2FA above, we would have to, somehow, stop using our user account for authentication.
Which is why we might register a secret for our new Azure App. However, application secrets are not supported in the XrmTooling connection strings:
So, what was the point of registering an app you may ask?
There is another option where we can use a certificate instead, and you may want to have a look at the following page at some point:
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/authenticate-oauth
If you look at the samples there, here is how it all goes:
It’s a special AuthType (“Certificate”), and the whole set up process involves a few steps:
- Registering an application in Azure AD
- Uploading a certificate (I used one of those I had in the certificate store on my windows laptop. It does not even have to be your personal certificate)
- Creating an application user in CDS
- Creating a connection string for XrmToolBox
To register an app, you can follow one of the links above. Once the app is registered, you can upload the certificate – what you’ll see is a thumbprint which you will need to use in the connection string. Your XrmTooling client, when connecting, will try to find that certificate on the local machine by the thumbprint, so it’s not as if you would able to use the thumbprint (as a password) without the certificate.
While trying to make this work, I’ve uploaded a few certificates to my app, so here is how it looks like:
What’s that with the application user in CDS? I think I heard about it before, I just never realized what’s the purpose of this. However:
- Application users are linked to the Azure applications
- They do not require a license
How do you create one? In the CDS instance, go to Settings->Security->Users and make sure to choose “Application Users” view:
Surprisingly, you will actually be able to add a user from that view and the system won’t be suggesting that you need to do it through the Office admin center instead. Adding such a user is a pretty straightforward process, you just need to make sure you are using the right form (Application User):
For the email and user name, use whatever you want. For the application ID, make sure to use the actual application ID from the Azure AD.
Don’t forget to assign permissions to that user (in my case, I had to figured I’d have that user as System Admin)
Once you have reached this point, the rest is simple.
Go to the XrmToolBox and start creating a new connection. Make sure to choose “Connection String” option:
Set up the connection string like this (use your certificate thumbprint and your application’s appid):
Click next, give that connection some name, and voila… You should be able to connect without the MFA under that special application user account now.
Thanks for the great post. The other way to connect to an MFA environment from XRM Toolbox is to create an app password for any CRM user from Security and & Privacy section of User account using office portal. But yes here you need to use the username and the key provided while creating the app (need to copy the key as once created it will not appear again). But you will not be able to login to interface with this. And user will be able to delete the app password if they no longer require it or create a new one.
Heh, that might work… If we only had permissions to do this:) Also, the example I used in my post was for a hybrid setup with ADFS & RSA instead of the native Azure authentication. But, realistically, I think it’s a ping-pong game between us and corporate security (“certificate-based authentication” sounds solid enough, doesn’t it?:) )
Hi,
What if we want to do the opposite and block tools like xrmtoolbox to connect to dynamics?
We donot want non admin dynamics users to use xrmtoolbox.
Hey, you are on the wrong side of the fence! But, seriously, I am not sure if there is a way since you would have to block access to the urls (WebApi and Soap endpoints) which are also used by Dynamics itself. If you are on-prem, you might probably try doing it through a set of “incoming” firewall rules for the server(for example, you might try verifying the client type, though you may still have to open it for some IP addresses). If you are in the cloud, your users might be accessing CRM from anywhere, so it won’t help to have firewall rules
Hi Jag – in the XrmToolBox documentation it is described how you can use registry keys to block usage: https://www.xrmtoolbox.com/documentation/for-it-administrators/restricting-access-to-xrmtoolbox-and-plugins/
I would however encourage you to ensure security of the system using security roles etc that are part of the platform, XrmToolBox is not doing anything any other tool (or even simple things like Excel!) can do as is just consumes the APIs exposed by the platform.