Licensing Advent Calendar – Day 11 – Security architecture

Another door unlocked for the Licensing Advent Calendar. Today, a post about the Dynamics 365 F&O security architecture. It is important to know about this to understand how the securable elements that are part of the calculation are linked to the security roles and the users. It will be the basis for knowing what to do for mitigating excessive license requirements.

Security architecture

When looking at the relation between security and license requirements, I thought that it would be good to talk about the security architecture. I can talk for hours about this topic. Those who attended my 4- or 6-hour workshop a few years ago can confirm that. I will limit it this time to what is relevant to licensing only.

In the post yesterday, I explained about the securable objects part of the license calculation and the indication when they are entitled in a license or not. In the diagram below, the securable objects are within the Permissions for application elements. The diagram is based on the picture Microsoft used in their documentation page about Security architecture.

A user needs to have the licenses assigned triggered by all permissions for the application elements that are used within security roles.

On privileges, the menu items, data entities, and service operations are referenced with specific access. Menu items are a specific type of UI element. Form controls are securable UI elements too. There are different access levels that can be set.

The access levels are:

• Read
• Update
• Create
• Delete
• Correct
• Invoke

The Correct and Invoke permissions are not used in Dynamics 365; this is a legacy from Dynamics AX 2012.

According to the license guide, Read access is granted throughout the application with the Team members license. In case Grant permissions are only set on the Read access and all others are Unset or Deny, then it is considered as Read-only for the license calculation. In case any of the other access levels are granted, then it is considered as write access, and the license depends on the metadata maintained by Microsoft. Although Correct and Invoke aren’t used anymore, this still activates the write access level.
Note that two privileges with permissions for a write action, where one is having Grant access and the other Deny, will be considered as write access. This is a known issue for the Microsoft team.

One privilege can contain multiple menu items, data entities, or service operation references with specific access levels. These are usually created per task. E.g., for maintaining customer records, the privilege grants access to the All customers list page, details form, the quick create form, address details, contact information, direct debit mandates, and a few more.

Multiple privileges are grouped into a duty, which supports a part of a business process. For example, the duty Maintain customer master has not only the option to maintain customer records, but also the option to create a customer from a prospect, maintain name changes, and has access to related data entities.

One or more duties are linked to a security role that gives then the access to the user access to the elements in the application. You can also link privileges as references to roles directly, but this should be done as an exception, e.g., fine-tuning a security role. Note that the standard Segregation of Duties (SoD) functionality can check the duties linked to roles only. When you use privileges on roles, this can’t be used for the SoD rules.

Individual security permissions are combined into privileges, and privileges are combined into duties. The administrator grants security roles access to the program by assigning duties and privileges to those roles.

With the above-provided information, you should now know that the contents of the security role trigger the licenses. The more licenses required, the more money you need to pay for granting a user access to the application.

In the application, there are a lot of standard duties and privileges. Usually, there is a duty and a privilege for maintaining data, and another one for viewing data. In case you want to restrict write access, you can use the duty intended for reading the data. In case only a few items need to be reduced to read permissions, you can also duplicate the duty and replace some privileges. In case the permissions on a privilege are still too high, you can also create a new privilege with the access levels as per your requirements.

There is more…

During the Advent period, each day in December, I will share some thoughts and tips related to the Dynamics 365 user license enforcement. If you have questions about this topic, feel free to contact me via LinkedIn, the comments section below, or the contact form on this blog. I will then either update one of the planned blogs for the coming 24 days or answer questions in a new post.

Dynamics 365 Licensing Enforcement Advent Calendar

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!