In a previous post, I showed how to set up security from the user interface. In this post I want to focus on D365FO security setup and configuration from the AOT.
Finding the AOT
The first thing we have to know is where the AOT is located in D365FO. In a development environment, the AOT can be accessed by RDP-ing to virtual machine where the AOS is hosted. On that machine will be a modified version of Visual Studio, under the View menu option you will find the Application Explorer (can also be launched by hitting Ctrl + E).
This will bring us to the AOT we are all familiar with.
Under the Security heading you will be able to find all roles, duties, and privileges that come out of the box from Microsoft as well as other roles, duties, and privileges that have been set up via the AOT. To create a custom role, duty, or privilege (or customize an out of the box role) you will need to create a new D365FO project. I recommend when creating this project to also create a separate model specifically for security and I’ll explain later on.
Creating a new security layer
If adding a new security layer right click -> Add New Item and select if you want to create a role, duty, or privilege. The name you provide will be the AOT name for the security layer you are creating, you can set the label for this later.
You can then start adding in subroles, duties, or privileges you want to associate with this new role by right clicking on that layer and selecting ‘New’. This process will allow you to create a new associations between the role and whatever child security layer you want.
You now need to provide the AOT name of the child security layer that you want to create the association with, in the example below we are creating an association between the FastpathTestRole and the ACOInquire_BR duty.
Modifying object access
If you are looking to create a privilege and want to actually modify object access you’re Properties window will look slightly different. In the below example, I created a FastpathTestPrivilege and assigned it the CustTableListPage menu item display at the Delete level.
In the Properties window, the Name, Access Level, Object Name, and Object Type parameters must all be set.
Modifying out of box security
You can also modify out of box security by creating an extension. In the Application Explorer search for the role, duty, or privilege you would like to modify, right click and select Create Extension.
You can then edit the out of box security. When creating an extension, you are not modifying the underlying object (like you would with over layering in previous versions of AX) but instead are creating an additional piece of data that is attached to the original object. In this way, Microsoft can update out of box roles, duties, and privileges without breaking customizations customers have already created.
In the example below, I am modifying the AuditPolicyManager role by add an association to the AccountantEntityMaintain privilege.
Synchronize changes with database
Just like with setting up security in the user interface, changes made to security in the AOT do not go live immediately. Since security is now stored as data in D365FO, there is a database sync process that needs to occur for your security to become live in the system. This can be done by right clicking on the Visual Studio project you have been making your security changes in and select ‘Synchronize <project> with database’.
Security configuration best practice
Now we can circle back and address why I said you should create a new model for just your security changes. If you have a separate model/project just for security you have the following advantages:
- Can more easily make security changes without effecting other areas of your environment, if all security changes happen within one project and it has it’s own separate module then you know when you build/sync the project you are only affecting security and not pushing unintended code into your environment
- Makes the security much more portable, if you have just a security model you can then create a deployable package from this and use that to apply to other environments very easily (just like you would with other code customizations)
- Makes it easier for source control and code management, with all of your security changes being in one place if anything needs to be changed there’s no guessing which project you need to update also because all of your changes you are making are code (and not data like it would be if you made changes to security in the user interface) you can use all of the benefits of source control around any changes
In my view, making changes to security in the AOT is a much better practice than modifying security in the front end but not every company is going to have an extra AX/D365FO developer that has the knowledge or time to be able to handle this. I hope these overviews of how to set up security in the user interface and AOT have been helpful, please feel free to reach out with any questions or if you have ideas of other topics I should cover.
which version of visual studio is used in this article ?
The version of Visual Studio that is shipped with a D365FO development environment is VS 2015 Professional.
and how to integrate the D365 F&O in visual studio?
Here is an excerpt from the article, there is a modified version of D365FO that is automatically integrated with D365FO on the development VM:
Hi Alex, I have a more basic question. I created a privilege pointing to a display menu item and I assigned that privilege to a role. Will the display menu item be visible only to the user who has the role assigned ?
I am a developer starting to work with X++ and Dynamics 365.
Thanks and regards,
You are exactly correct, the hierarchy would look like this:
User -> Role -> Privilege -> Menu Item Display
D365FO has a pessimistic security model, meaning that a user has no access in the system until they are explicitly assigned access.
So a user would only be able to see this menu item display if they were assigned a role that had access to this object.
So happy to have found your blog, i do appreciate your series articles and they have been very helpful. Question: What happened to server methods that we used to add to privileges in ax12? I couldn’t find a way to add them as i was fiddling around with 365. Many thanks
Thanks for the kind words, as far as server methods in D365FO they no longer exist in the way they did in AX 2012. The closest object in D365FO would be the service operations.
Hi Alex, Great article and this has gotten going on my security project. My question is if you have your own custom module and are trying to design security for the users how do you lay that all out. So in my case I have custom tables, forms, menus, etc… Would you create privileges for all the different areas and then develop duties from those? I’m not sure which direction to start fully building permissions out from. Any advice would be greatly appreciated. Also it has been a quite difficult finding articles or resources on security that weren’t geared for extending the existing Microsoft ones so if you have any resources please share.
Thanks for the kind words, hopefully the blog helps! The approach I recommend when setting up user’s security is to take a business process approach utilizing least privilege. This is the concept of assigning the least amount of access necessary for a user to perform their day to day operations. This involves 1) determining what a user does during the day and 2) categorizing these processes into logical privileges, duties, and roles
Luckily there are native D365FO tools to help with this process, I go into depth on the least privilege process in my D365FO security class if you are interested. There are also ISV solutions that can help with this type of setup, like Fastpath Security Designer which I am the lead developer on.
Feel free to reach out with any additional questions! You can also reach out via email at email@example.com.