Security in D365 F&O is often not the priority in any ERP implementation. That topic is most of the time tackled after all other major topics and that is a mistake in my opinion. A resource should be assigned to that task and a specific security stream should be created. That article describes shortly how to implement security changes in D365 F&O, how to test them, and how to embed segregation of duties rules in D365 F&O.
*OOB = Out of the box
Migrate security in D365 F&O
There are two approaches to migrate security from one D365 F&O environment to another :
● Development: make all your adjustments in Visual studio and none through the user interface
● User interface: make all your adjustments in the security interface and export your customizations through the data management framework
I detailed the pros and cons of both solutions
● Easy to create a deployment package or model that you move between D365 F&O environments
● Out of the box Visual studio version control
● Option to create several models if specific security changes need to be delivered separately
● Harder to setup for a functional profile and maintenance is more difficult as any modifications is a code change
User interface (Security configuration)
● The changes are made through the user interface (easier for set up and maintenance)
● No technical resources required
● All your changes are stored in a xml file that can be imported in any environment. That means no specific changes can be migrated
● No version control system (just an audit trail as below)
● No change in the code, just a delta in the database
● Re-import xml after each update
I recommend choosing the development solution for a control purpose. That means you need to enforce a strict governance around security changes.
To develop security, in the AOT, open Visual studio and navigate to the Security tab.
You can view the security elements hereunder:
- Why do we have those two approaches in D365 F&O?
– Because the design time (code development) and runtime (code execution) environments are now separated in D365 F&O which was not the case in Dynamics AX.
- – The design time is on a virtual machine with Visual Studio.
– The runtime is a web application running in Azure.
- The changes that are stored in the security delta will override changes made in the AOT
Security Tools in D365 F&O
D365 F&O provides several tools to identify the permissions behind a form or business process.
a) How to view permissions?
Navigate to System administration > Security > Security configuration, then select a role and choose View Permissions
You can follow this process to get the same information at a duty and privilege level.
You also see the license associated with that security role (New in 10.0.15).
You also get that information when you assign roles to a user.
b) How to view the breakdown of the roles, duties, and privileges that give access to a particular page/form in D365 F&O ?
Go to Options -> In the Page Options group -> Security Diagnostics
c) How to get Form information in D365 F&O?
Right click on the form, then select Form information
d) How to run Security diagnostics for task recording in D365 F&O?
Run the task recorder for a process you would like to perform in D365 F&O and save the axtr file.
Navigate to System administration > Security > Security diagnostics for task recordings
Pick the file generated from task recorder and see menu item during process
You can also run it against user access to see if the user has access to that object
e) Table permission framework
It provides an additional layer of security to your highly critical data (VAT number, social security numbers…). It is also an additional check that requires that users have been granted correct rights to the table field. The property that enables this feature is called AosAuthorization. When it is turned on, it activates the table permission framework.
When you need to give access to a form, you should perform those tasks:
You should start from standard roles and duplicate them in your project. Then, you can remove the duties you want and deep dive in them if needed.
You need to modify a duty, follow the same steps, and remove the privileges you want and assign the custom duty to your custom role.
💬: I recommend strongly to keep the standard security hierarchy when you develop new roles. I ‘ve noticed that some clients assign many privileges directly to the security role. You will not be able to use the SOD framework described in that article.
Test security changes
You developed security roles and you would like to test them. There is a nice tool for that!
Install an add-on in Visual studio
In my VM, the path is: E: AppRing3 > 10.0.169.XXXXX > retail > Services > DevToolsService > Scripts
Click on the highlighted addon InternalDevTools
Then, open Visual studio as administrator
Go to Dynamics 365 > Add ins
Select View with role set
Drop your developed roles to the assigned roles box
It opens a web application where you can test your combination of roles.
Yes, that is right you can even test a combination of security roles. What a game changer!
💬: the name of the role is the technical name
Segregation of duties (SOD)
SOD is a key element of an effective control environment. There needs to be an adequate division of responsibilities. It is often managed outside the
ERP in an Excel spreadsheet and that’s why Microsoft introduced a simple feature described hereunder.
Navigate to System administration > Security > Segregation of duties > Segregation of duty rules
Segregation of duties are done at the duty level. So, if a user has access to duty 1 and duty 2, that would be considered a SOD conflict.
The SOD conflicts report is done at the user level and mitigations are documented manually. When a conflict pops up, it is saved in the Segregation of
conflicts unresolved conflicts form.
You can allow or deny the assignment of those conflicting roles.
It is not perfect but that is a first step, but I am sure there are more to come from Microsoft.