Security in Dynamics 365 F&O: Less is More

I’m starting this blog about security with the words Less is More! This is a concept about simplicity. In life, we look at certain things in an overcomplicated way or try to make them too advanced. We don’t see it ourselves until someone helps us think in a different direction. When you just start working with Dynamics 365 and the security architecture, you might wonder why you sometimes don’t have the permissions or data visible as you would expect. In this blog, I will share some scenarios and background information where by granting more security roles, the user will have fewer permissions than expected on particular features.

Less is more…

This post is not about the least-privilege principle where you would like to provide only access to entry points that are relevant for the particular role. It will be a bit related, but this post is to make you aware of some standard security, provided out of the box which will cause records to be not visible or buttons disappearing. From my experience, most new persons starting to work with Microsoft Dynamics 365 F&O will first try out the standard security roles. Maybe all roles related to purchasing will be granted to a user to test what is available or they will start with a single role and then add additional roles in case e.g. the user should e.g. also manage released products. With this approach, they are not fully focussing on what other functionality is granted to this user and how to ensure that there is a focus on the segregation of duties.

From my experience and the implementations I participated in, there was no role used from the standard roles except the System administrator role and in some cases the Timesheet user role. Usually, I present the standard roles as example roles. Mostly, within the customer environment, we created specific roles for their organization. This depends on the required features, the number of users, and the level of segregation of duties that needs to be implemented. The privileges and duties are like building blocks that can be reused and are quite sophisticated for many security scenarios. Of course, for particular use cases, there is a need for additional privileges or duties.

One example is the vendor invoice approval journal. Out of the box, the full permissions are part of the Accounts payable manager and Accounting manager role. If a user should create the invoice register and fill in the details of the approval journal, in some cases, people will assign both the roles Accounts payable clerk and Accounts payable manager. For sure, the user will have too much access to the application and there is a risk of committing fraud. For this scenario, it would be good to review if the Accounts payable clerk role should be extended with some permissions or create a new role with fewer permissions, but more internal control and security. With this obvious example, I trust you will now also consider the standard roles as examples and will focus on creating tailored roles per organization.

Roles with data security

Continuing on the exploration of the application where multiple roles will be added to a user… Suppose a user already tested the Purchasing agent role. With this role, a user can maintain vendors and perform more purchasing-related features. Now add the Vendor admin (external) role and the user will complain he can’t see all his vendors anymore. This is due to a standard data security policy created with help of the eXtensible Data Security (XDS) framework. The standard roles in the application with the word “external” between brackets are designed for external users which should not have access to all data. The external vendor roles are part of the vendor collaboration features where external contacts are able to see and interact with a selected number of features like inquiries in purchase orders or can reply to a request for quotation. In general, the external roles are restricted to particular records only. In the past, I also had similar experiences with public sector security roles. Other examples of roles with out-of-the-box data security are:

• Lease clerk – Delete restrictions on Leases table with a check on confirmed payments
• Retail store manager – Restriction on retail-related data where users can only see selected records based on Address books.

Assigning the Retail store manager role has also an impact on the number of customer records visible to users. All security policies for this role are linked directly to this Retail store manager role. If you would create a copy of this role, the policies are not enforced and users will see all records. If you want to have the same data restriction, you would need to create new security policies with the same purpose and content, but linked to your role(s).

Besides data policies linked to roles out of the box, there is also a feature where private location details (addresses, contact information) are visible to only the user related to the record itself or a configurable set of security roles; mostly used for Human resources. You can read more about private location security here: About the private location security in Finance & Operations and Human Resources

Denied access

As of Dynamics 365 F&O, Microsoft added the option to specify ‘Deny’-permissions on securable objects. This option was not available in Dynamics AX 2012 and all previous versions. When deny permissions are used, this has higher priority than grant permissions, regardless of the number of security roles linked to a user. In fact, the deny permission means NEVER.

If you want to learn more about the deny permissions, when to use them, and get some examples, you can read the next blogs from my blog, and also a great post created by Alex Meyer:

• How to Utilize Deny Permissions in D365FO – Alex Meyer (alexdmeyer.com)
• Security how-to: Only a finance user is allowed to change the on-hold status of vendors and customers – Dynamicspedia
• Security how-to: A purchasing agent is not allowed to maintain vendor bank details – Dynamicspedia

As you might guess, also the Deny (NoAccess in AOT) permission is used on standard security objects. I don’t have an extensive list of all examples, but I’m aware of one example. You will encounter the issue with a combination of security roles. When you assign an accounting role, like the Accountant role, the user is able to post the general journals. If you add the role Project assistant, then this role has a privilege called Maintain expense journals where the Post button has been hidden with the deny permission. As project expense journals and general journals are based on the same journal entry forms, not only on the expense journal but also on all other journals, like the general journals the post button is not visible anymore. This is just one example, but there might be more in the standard security.

Conclusion

Setting up security in Microsoft Dynamics 365 F&O can look easy at first sight, but it is more than only providing access to menu items via privileges, duties, and roles. Before doing the actual implementation, you should be aware of what roles and exact content are required. Playing around with the example roles is a good start for learning the basic concepts, but if you get stuck, reread the details above and check if the securable objects are restricted with data security or deny permissions. You can try to remove some roles or objects and check the behavior or you can create own privileges, duties, and roles where you can verify differences. If you are still wondering about differences in behavior with standard and custom roles or unintended outcomes when using a combination of roles, leave a comment below or ask a question on the Microsoft Dynamics 365 Community.

I do hope you liked this post and will add value for you in your daily work as a professional. If you have related questions or feedback, don’t hesitate to use the Comment feature below.


That’s all for now. Till next time!