of the
Steve “kick the hornet’s nest” Mordue asks:
Does anyone know of a tool
for comparing two security roles easily?
Good news Steve. There’s a Yack for that.
David Yack’s fantastic Xrm.Tools has a security role explorer that allows you to easily compare two Dynamics 365 security roles, identify what is unique to each role, and what the differences are.
In your browser, go to Xrm.Tools. Click “Sign in” and log in to your Office 365 account. Note–you can save this step by logging in to Dynamics 365 first, then opening another tab and going to xrm.tools. You still need to click “sign in,” but it will authenticate you to your Office 365 account.
In the lower left quadrant, click “Explore Roles Now!”
On the next screen, select the organization environment where you wish to compare roles.
Click “Compare Roles.”
Select the roles you wish to compare and click “compare.”
The tool will then provide you with a comparison of the two roles:
- Permissions unique to role 1
- Permissions unique to role 2
- Differences between the two roles
- Similarities between the two roles
Is Xrm.Tools secure? If I’m having to provide my Office 365 credentials, it must be requesting data from Dynamics 365 as my own identity and the privileges it has, which I will never trust this or any other application to do.
This is the standard oauth on-behalf-of mechanism. You never provide your credentials to Xrm.Tools. What you do is you prove to O365 that you are who you say you are (hence the prompt to login) and then you explicitly authorise Xrm.Tools to act on your behalf against your instance of CRM. Token generated to that access is not stored beyond the session and does expire even if it was.
If you are still concerned you can create and use non-interactive user account with a very specific restricted access role assigned to that user.
> This is the standard oauth on-behalf-of mechanism.
If it’s standard, it’s bad use of a standard.
> You never provide your credentials to Xrm.Tools.
That doesn’t matter, Xrm.Tools could do whatever it wants based on the users permissions associated to the token that it receives. Given that most people using this will be system administrators, it’s giving way too much power to an application. It could delete data or extract data behind the scenes and the user wouldn’t have any clue.
> and then you explicitly authorise Xrm.Tools to act on your behalf against your instance of CRM.
Most people won’t understand the implications of the confirmation or the brief wording that is used on the consent form. Xrm.Tools or any other application using that approach could do anything they want to your environment without your knowledge. This is a very poor decision by Xrm.Tools to use that.
> If you are still concerned you can create and use non-interactive user account with a very specific restricted access role assigned to that user.
The site doesn’t give the option of using a non-interactive user account.
This tool and any other one that uses this approach should be black listed from anyone using.
Yes it does, you just logon using that non-interactive account. Non-interactive does not mean you can’t use these credentials, non-interactive means you can’t use CRM UI.
I’m sorry you feel so negative about the use of a standard mechanism. I’m not going to argue point-by-point as this blog is not a good media to do that. You’re welcome, of course, to suggest an alternative mechanism to authenticate without providing the credentials to the tool run by one of the most trusted members of the community.
Let’s also ban XrmToolbox while we are at it. Heck, let’s ban all the tools prompting you to provide login information. After all, you don’t know what XrmToolbox does in the compiled code, do you? I think that it might be even sending your credentials to a server somewhere to do some nasty things to your instance.
I suppose the take away is to only use applications which you trust when providing your credentials and tokens to them to act upon your behalf and perform actions using your own permissions.
Right–it’s no different than connecting to the XRM Toolbox or other CRM utility.
[…] XRM tools security role comparison […]
Can we compare roles from different environment ? whether both are similar or not in DEV from two different env
Not directly, as far as I know. You can export a role from one environment, import it into the target instance and then compare in the target.