Dynamics 365 Security Roles: Testing Best Practices

A security model in Dynamics 365 protects the Data Integrity and Privacy in a D365 organization. As a D365 Customizer, Authentication and Authorization of the D365 application is called security testing. Security roles in D365 have both Privileges and Access levels for each Entity. As you are planning to validate your system, always remember these important points:

Test Plan

security roles

security roles

security roles

Test Execution

That’s it. You’re ready to test security roles within Dynamics 365. For more tips and tricks, be sure to subscribe to our blog!

Happy testing!

Access Is Denied: How to Identify and Fix a Security Role Issue

As a Microsoft Dynamics CRM administrator, you may run into issues where end-users do a certain action and receive an error message regarding permissions like the one below:

Access Is Denied: How to Identify and Fix a Security Role Issue

Access Is Denied

You do not have enough privileges to access the Microsoft Dynamics CRM object or preform the requested operation. For more information, contact your Microsoft Dynamics CRM administrator.

It tells them to contact you, so it's your lucky day. This message means that whatever action was being performed, the security role assigned to the user performing the action does not have adequate privileges. Now YOU need to determine what exactly the user does not have access to do.

Now you have three options:

1. Give the user the System Administrator role. This is not recommended, but it will give you a very quick fix.

2. Use your best judgment to determine what right are missing. Sometimes this is the best way. For example, if a user attempts to save a contact they don't own, and they have user-only write access to contacts, you may know right away what rights are missing without doing further trouble-shooting.

BUT if they are saving a type of record that has multiple relationships and lookups, this method would become increasingly inefficient. After a couple tries you might want to move to option 3.

3. Download the log file and determine the missing privilege.

When option #2 doesn't work and you just don't feel like playing whack-a-mole with security role privileges, your best option will be to read the log file and find out exactly what is missing. Don't worry - you don't have to be a coder or overly techy to read a log file! CRM does a very nice job of laying out what privilege is missing, by listing two key items: the entity type, and the rights type.

Let's start with a simple example. Imagine a user with the following security role:

Access Is Denied: How to Identify and Fix a Security Role Issue

As you can see, this user does not have the permissions to delete orders. If they try to do so, they will receive an "Access is Denied" message. If they click download log file, you will see the following:

<OrganizationServiceFault  >
    <ErrorCode>-2147220970</ErrorCode>
    <ErrorDetails  />
    <Message>System.Web.HttpUnhandledException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #C0133EE3</Message>
    <Timestamp>2014-07-28T13:52:14.9767207Z</Timestamp>
    <InnerFault>
        <ErrorCode>-2147187962</ErrorCode>
        <ErrorDetails  />
        <Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 8bd4de8b-5a16-e411-80c2-00155dcfd317, OwnerId: 15f85c02-6dd1-e311-80bb-00155dcfd318, OwnerIdType: 8 and CallingUser: 67fb54d8-6dd1-e311-80bb-00155dcfd318. ObjectTypeCode: 1088, objectBusinessUnitId: 1292bfc5-b0f9-e311-80c1-00155dcfd317, AccessRights: DeleteAccess </Message>
        <Timestamp>2014-07-28T13:52:14.9767207Z</Timestamp>
        <InnerFault i_nil="true" />
        <TraceText i_nil="true" />
    </InnerFault>
    <TraceText i_nil="true" />
</OrganizationServiceFault>

Yikes! What is all that junk? Fortunately, it becomes easy to recognize and understand this with just a little additional info on what it all means. You only need to pay attention to two things from this entire message: the ObjectTypeCode, and the AccessRights. Let's take a closer look at that log file, and look at those two items again:

<Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 8bd4de8b-5a16-e411-80c2-00155dcfd317, OwnerId: 15f85c02-6dd1-e311-80bb-00155dcfd318, OwnerIdType: 8 and CallingUser: 67fb54d8-6dd1-e311-80bb-00155dcfd318. ObjectTypeCode: 1088, objectBusinessUnitId: 1292bfc5-b0f9-e311-80c1-00155dcfd317, AccessRights: DeleteAccess </Message>

<Timestamp>2014-07-28T13:52:14.9767207Z</Timestamp>

The access rights should be self-evident: this message from CRM is saying the missing rights is Delete Access. But what about ObjectTypeCode? What does that even mean? How is 1088 going to help me?

Simply put, ObjectTypeCode is the numerical representation of a CRM entity or item. Fortunately, Microsoft has a listing of all ObjectTypeCodes that come with CRM. If you do a search in this page for "1088", you will see that it refers to "SalesOrder," which is the Order entity.

Therefore, the log file that we downloaded contains the information that the user is missing Delete rights (AccessRights: DeleteAccess) for the Order entity (ObjectTypeCode 1088).

So now let's try a more complicated example, using custom entities.

I have a user that reported an error creating this record:

Access Is Denied: How to Identify and Fix a Security Role Issue

I then asked him for the log file, and he sent me this:

Unhandled Exception: System.ServiceModel.FaultException1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f2188e1a-85a1-e411-9423-00155dcfc00d, OwnerId: 60b7716d-b866-e411-941d-00155dcfc126, OwnerIdType: 8 and CallingUser: ca8f4a13-8ca1-e411-9423-00155dcfc00d. ObjectTypeCode: 10085, objectBusinessUnitId: 41f74f5e-b666-e411-941d-00155dcfc126, AccessRights: AppendToAccess Detail:

<OrganizationServiceFault  >

    <ErrorCode>-2147187962</ErrorCode>

    <ErrorDetails >

        <KeyValuePairOfstringanyType>

            <d2p1:key>CallStack</d2p1:key>

            <d2p1:value  i_type="d4p1:string"> at Microsoft.Crm.Extensibility.VersionedPluginProxyStepBase.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.Pipeline.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.MessageProcessor.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.InternalMessageDispatcher.Execute(PipelineExecutionContext context) at Microsoft.Crm.Extensibility.ExternalMessageDispatcher.ExecuteInternal(IInProcessOrganizationServiceFactory serviceFactory, IPlatformMessageDispatcherFactory dispatcherFactory, String messageName, String requestName, Int32 primaryObjectTypeCode, Int32 secondaryObjectTypeCode, ParameterCollection fields, CorrelationToken correlationToken, CallerOriginToken originToken, UserAuth userAuth, Guid callerId, Guid transactionContextId, Int32 invocationSource, Nullable1 requestId, Version endpointVersion) at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, UserAuth userAuth, Guid targetUserId, OrganizationContext context, Boolean returnResponse, Boolean checkAdminMode) at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.ExecuteRequest(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode) at Microsoft.Crm.Extensibility.OrganizationSdkServiceInternal.Execute(OrganizationRequest request, CorrelationToken correlationToken, CallerOriginToken callerOriginToken, WebServiceType serviceType, Boolean checkAdminMode)</d2p1:value>

        </KeyValuePairOfstringanyType>

    </ErrorDetails>

    <Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: f2188e1a-85a1-e411-9423-00155dcfc00d, OwnerId: 60b7716d-b866-e411-941d-00155dcfc126, OwnerIdType: 8 and CallingUser: ca8f4a13-8ca1-e411-9423-00155dcfc00d. ObjectTypeCode: 10085, objectBusinessUnitId: 41f74f5e-b666-e411-941d-00155dcfc126, AccessRights: AppendToAccess </Message>

    <Timestamp>2015-01-26T16:11:49.9974893Z</Timestamp>

    <InnerFault i_nil="true" />

    <TraceText i_nil="true" />

</OrganizationServiceFault>

While it contains a lot of information, again, keep in mind we are only concerned with the AccessRights and ObjectTypeCode. Looking at the above log file, we gather the following:

ObjectTypeCode: 10085
AccessRights: AppendToAccess

Therefore, we are missing Append to rights for the entity that corresponds to ObjectTypeCode 10085. Unfortunately, we can't use the link above from Microsoft that provides default entity type codes. Fortunately, there is an extremely easy way to find the ObjectTypeCode for any entity including custom ones without the need to access the database directly or write code. Simply navigate to the following URL:

https://mycrmorg.contoso.com/main.aspx?etc=10085&pagetype=entityrecord

Where etc=10085 is taken from the error log. So if your error message gave ObjectTypeCode = 10120, then the URL you would go to would be /main.aspx?etc=10120&pagetype=entityrecord

But let's go back to the example above. If I were to go to that URL as shown above, I would see the following page:

This means that ObjectTypeCode of 10085 is the Olives entity! And since the message also mentioned we are missing Append to rights, we can conclude that the missing privilege is Append To rights for Olives.

Access Is Denied: How to Identify and Fix a Security Role Issue

 

Additional items to keep in mind:

We hope this helps all you Dynamics CRM admins out there! For more on topics related to this blog, we have compiled a list of similar blogs:

Happy CRM'ing!

Assigning System Views Based on Security Roles in Dynamics CRM

Have you ever had a request to assign system views based off of security roles? This is not an out of the box function of CRM 2013, but the following tool from codeplex makes this a reality:

http://rolebasedviews.codeplex.com/

First, download the RolebasedViews_managed and RolebasedViews_executables zip files from codeplex. Then import the RolebasedViews_Managed.zip solution into your CRM environment. When that step is completed, click the RoleBasedViews Application file within the RolebasedViews_executables zip. This will open up the interface below.

Assigning System Views Based on Security Roles in Dynamics CRM

 

Using the drop down menu at the bottom left of the screen you can connect into your CRM. Once connected, click load data at the top right of the screen. This will list out all of the entities and allow you to select security roles from the drop down menu.

 

Assigning System Views Based on Security Roles in Dynamics CRM

 

Now you have the ability to select which views are visible within each entity for each security role enabling role based views in CRM! You can also select the default view within each entity. For further detailed instructions, please click on the codeplex link below.

http://rolebasedviews.codeplex.com/documentation

Happy CRM'ing!

The CRM Minute: Lock it down! Tips for Securing CRM for Dynamics 365 [VIDEO]

Your CRM for Dynamics 365 system is the cornerstone of your company's data. That means keeping it safe and sound is critical. The last thing you'd want is for your security to be compromised, right? In today's episode of The CRM Minute, hear from Alex, our rock star CIO, on five can't-miss tips to keep your CRM secure.

[php snippet=45]

Alex will be presenting more on this topic, at this year's CRMUG Summit EMEA, from April 4-6 in Amsterdam. The whole team will be there, networking and talking CRM with other users, so make sure you stop by and see us at booth #11. We'll also be giving away some sweet swag items, so don't miss it! You can learn more and register here, and make sure you check out Alex's session at the conference:

Alert! Data Breach: Securing Your CRM

Thursday, April 6, 2017: 13:00 – 14:00

Recent research suggest that 80-90% of companies have experienced some type of data breach. Is your CRM secure? Come to this session to learn what you must do to secure your CRM system. If you value your data and don’t want the bad guys to easily walk away with your customer master list, you must attend this session. Learn how to minimize data loss, design with a solid security architecture and how to detect if an account has been breached. This session applies to both CRM Online and On-premises.

Happy CRM'ing!

The CRM Minute: Tips for Dynamics 365 Security [VIDEO]

Your Dynamics 365 system is the lifeblood of your business, which is why it's so important to make sure your data stays safe, secure, and in-tact. Hear from Alex, our PowerObjects CIO, about five things to consider when setting up your Dynamics 365 security.

As you can see, there are a lot of moving parts that go into securing your system. The tips mentioned today are great and easy ways to get started. Try implementing these first, and let us know what we missed by sounding off in the comments below!

Happy Dynamics 365'ing!

Additional Resources

Using Security Roles to Disable Custom and System Dashboards

Security roles in Dynamics CRM can be configured to disable both custom and system Dashboards, which can be useful if a company adopts an existing solution but its users do not have a need for the pre-existing Dashboards that have already been configured. Disabling unnecessary Dashboards is the preferred solution over deleting them, since certain customizations or plug-ins may reference them. Let's go over how to use security roles to disable Dashboards.

To disable a Dashboard for all users, we will need to enable security roles on the Dashboard to hide it. To do so, navigate to your CRM solution's customizations settings and select Dashboards from the pane on the left-hand side. Select the Dashboard you would like to disable.

Note: Only one dashboard can be updated at a time. To disable multiple dashboards, repeat these steps for each.

Disable custom and System Dashboards

Once the dashboard is selected, click Enable Security Roles in the commands.

Disable custom and System Dashboards

A new window will open up where you can configure the security roles for the selected Dashboard. In this window, change the top radio button from Display to everyone to Display only to these selected security roles. Then, click the check mark at the top left-hand side of the list view to uncheck all security roles at once. Then uncheck the Enabled for fallback check box and click Okay.

Disable custom and System Dashboards

By un-assigning all security roles from the 'Display to' list for a particular Dashboard, it will not be visible to any user that logs into Dynamics CRM. If you deactivate the default Dashboard, be sure to activate another new dashboard as the default.

That's all for today's blog! Check out these other resources for using security roles in Dynamics CRM, and as always, happy CRM'ing!

How to Disable Exporting or Printing Reports in Dynamics CRM 2016

Depending on the sensitivity of an organization's data, it is often necessary to disable the ability to export or print reports. This ensures that reports with confidential information such as sales numbers, company earnings, personal contact data, or lists of accounts do not leave the confines of CRM. The export permission is set at the Security Role level. In today's blog, we'll be showing you to disable exporting or printing reports in Dynamics CRM 2016.

To disable these options, follow these steps:

1. Expand the Menu from the Ribbon.

2. Select the Settings option.

3. Select Security.

Printing Reports

4. Select Security Roles.

Printing Reports

5. Select the desired security role and navigate to the Business Management tab.

6. Scroll to the Privacy Related Privileges section. Ensure that the Export to Excel and Print options are disabled.

7. Save the changes.

Printing Reports

Once the changes have been saved, all users assigned to the modified security role will no longer be permitted to export or print reports. Check out the following links for more information regarding the hierarchical security data model or applying field level security.

Happy CRM'ing!

Solving Security Headaches: Display Rules Based on Security Roles

Some organizations need to allow certain users to access buttons on the Ribbon or Command Bar, while allowing others to utilize them based on the users' security privileges. If you think this cannot be done, good news! It can! There are a few different ways to accomplish this functionality, and in today's blog, we will show you how to solve your security role headaches. Let's dive in!

The steps outlined below require no coding and can be easily implemented utilizing the Ribbon Workbench and out-of-the-box security roles. To accomplish this, we created a custom entity (po_Security) to manage the display rules, however, this is not required as the exiting entities and privileges can be used. We created the new entity to ensure that no existing entity privileges were going to be effected, but the same principles will apply regardless if you chose to create a new entity or not.

1. First, start by downloading and installing the Ribbon Workbench.

2. In CRM, create a new solution that will contain only the entities you wish to update the button display rules for.

3. Next, launch the Ribbon Workbench from the Solutions section in Settings.

Security Roles in CRM

4. In the Ribbon Workbench, select a solution to open. We'll select the solution that we created for the purposes of our button display rule edits.

Security Roles in CRM

5. When the solution loads in the Ribbon Workbench, select the entity to start with.

Security Roles in CRM

6. In this example, we will be removing the ability for certain users to create and add existing Leads from a sub grid on the Account entity as well as the ability to delete or remove Lead records from the grid. Select the first button to create and apply a display rule to. Right click on button and select Customize Command.

Security Roles in CRM

7. Navigate to Commands in the Solution Elements tab.

Security Roles in CRM

8. Right click on the Command and click Edit Display Rules (or select the lookup on the Display Rules field as shown on the right).

Security Roles in CRM

9. Select +Add New in the display rules viewer.

Security Roles in CRM

10. Select Add Step.

Security Roles in CRM

11. Select Entity Privilege Rule and then click OK.

Security Roles in CRM

12. Create the New Display Rule:

Security Roles in CRM

13. Next, select OK and the Display Rule will be added to the Command. Select OK again on the Display Rules viewer to enable the rule.

14. To apply the same rule to additional buttons, select the next button you wish to add the Display Rule to. Right click and select Customize Command.

Security Roles in CRM

15. Navigate to the Command section and select the command to customize. Right click and choose Edit Display Rules.

Security Roles in CRM

16. Select the previously created rule and click Add > to button commands. Then click OK.

Security Roles in CRM

17. Repeat these steps for all required buttons. In our example, notice all of the buttons required to be hidden in order to achieve the desired functionality.

Security Roles in CRM

18. Now that the Display Rules are applied to the necessary buttons, notice that we no longer have the ability to add a new Lead from the sub grid.

Security Roles in CRM

With a basic understanding of how Display Rules work and how to utilize out-of-the-box security roles, you can provide more flexibility to how users perform specific functions in CRM.

Want to learn more about Dynamics CRM? Did you know that we have an entire library of Webinars on Demand? Watch and learn more about CRM anywhere, anytime! Make sure you sign up for our event notifications as well, so you can be notified about any new and upcoming webinars!

Happy CRM'ing!