I’ve written in the past about Dynamics 365 for Finance & Operations Security and how it differs from previous versions of Dynamics AX, now it’s time to look at how to set up security within the application. I will show how to do this from the user interface (in this post) and from the AOT (in a follow up post) while giving pro’s and con’s of each.
Setting up security in the user interface
To set up security from the user interface, log into D365FO and navigate to System Administration -> Security Configuration. After navigating here you will be presented with a similar screen to the one below, I’ve broken the screen down into different sections based on their function.
- Green box – Allows you to switch between roles, duties, and privileges
- Blue box – Has a number of different options for performing against the currently selected role/duty/privilege
- Undo/Redo – undo/redo customizations applied to this security layer
- Create new – create a new security layer
- Show all levels – by default D365FO will only show 4 levels of fly-outs in the navigation, this option will force it to show a horizontal scroll bar to fit all fly-out levels
- Delete – remove the current security layer
- Duplicate – create a clone of the currently selected security layer, allows you to give it a new name
- Copy – copies the current security
- View Permissions – shows an entire hierarchy of security for the currently selected security layer
- Audit Trail – shows the history of all changes made to an object either from user interface or through AOT
- Red box – listing of all current objects in selected security layer
- Pink box – shows details about currently selected security layer object including Description and AOT name
- Purple box – shows all of objects that are either assigned to this security layer or that this security layer is assigned to, the plus icon (+) designates that there are objects already there. So in this case this role has duties, privileges, and tables assigned to it but does not have any sub roles or parent roles.
- Light blue – all changes made in the user interface must be ‘published’ before they go live, this object lists all of the changes that are not currently published yet
If I wanted to add a duty to this particular role I would then click on the Duties button within the References area (purple box above) and the menu bar would change slightly:
- Add references – allows you to assign a currently available security layer object from a lower layer and assign it to the current layer (ex: duty -> role, privilege -> role, privilege -> duty)
- Create new and add reference – allows you to create a new security layer and assign it to the current layer (ex: create new duty and assign it to the currently selected role)
If I wanted to remove a duty from this particular role, I would select a particular duty currently assigned to the role and the menu bar would again change slightly:
- Remove reference(s) – allows you to remove a single or multiple references that are currently assigned to a security layer
To change object permissions you will need to navigate to the Privileges area, find the privilege you would like to modify, find the object assigned to the privilege you would like to modify and select it. You will be presented with a fly-out similar to the one below. From here you can set each access type (Read, Create, Update, Delete) to a specific access level (Unset, Grant, Deny).
What’s the deal with Unpublished Objects?
When a user makes a change to security in the user interface, this change does not go live immediately. Instead it goes to the Unpublished Objects area within Security Configuration. To make security changes actually become active, you will need to go to this area once your changes are done and either select ‘Publish all’ to publish all changes made or select individual changes and select ‘Publish selection’ to only publish certain security changes.
Where do security changes done in the user interface get stored/saved?
In previous versions of AX, when you made a change to security within the application that change was propagated back to the AOT and went live immediately, this is no longer the case within D365FO. This is because of the change to the overall architecture of the application as a whole (the design time and run-time are no longer within the same environment) changes to security made within the user interface are not pushed into the AOT. Instead these changes are put within what Microsoft calls the ‘security delta’ and are stored as data within the database instead of metadata code within the AOT. So when the security framework looks to see what a particular role, duty, or privilege has access to it first looks in the AOT, then looks at the security delta to see if any customizations need to be applied. It then takes a combination of these two (with the security delta taking precedence) and uses that to determine what a security element has access to.
How do you export/import/move/source control security changes made in the user interface?
Because security changes made in the user interface are not stored as metadata in the AOT, the next question is ‘How do we manage these changes?’ Luckily Microsoft allows for that by allowing users to export/import all of their security customizations done in the user interface to an XML file. This file can then be taken to another environment to imported or can be used in source control so you always have a record of any security changes made in the user interface.
This functionality can be found under the ‘Data’ menu option in the menu bar.
Conclusion
I hope this overview helped with getting acquainted with setting up security from the user interface with D365FO. A follow up post will show how this all can be done from the AOT.
If I wanted to cancel an unpublished security change, how would I do that? I can see the item in the unpublished objects, but the Undo/Redo buttons are not enabled.
Once a change to a role, duty, or privilege is made in the user interface a record is written to the SecurityUnpublishedObjects and SecurityCustomizedDiskObject tables. There is an Undo button in the user interface which undoes the change but the records in these tables are not removed but they are reverted back to their original state. Which means it still shows up as an unpublished object but there is no change between the old and new security. To remove this you can either publish the ‘changes’ which will have no effect as there isn’t a change in security or remove the affected records in both of these tables manually.
Does setting up Security impact to Dynamics 365 Performance?
Setting up security does not effect D365FO performance.
It does impact performance as after security implementation the request would run against security data model elements to ascertain whether the request is allowed or not.
Mav,
The check to see whether a user has access to an element is done on every request, regardless of if the user has modified security or not.
Alex, thank you for the great overview of security in D3FO – well done. One quick question about the “Remove customizations” button. Does this remove ALL customizations or only the role currently in focus? Thanks in advance, -Mike
Michael, thanks for the kinds words!
To answer your question yes, that ‘Remove Customizations’ button removes all customized security made in the user interface. Customizations made in the AOT are not removed.
Hello, and thank you for this rich article,
I have a question about security roles, privilieges, and duties tables,
In AX 2012 it was easy to create them by code (not only security elements but all AOT objects)
With D365FO it’s no longer the case, we are talking about 2 separated environements (Dev &
Application) , so to add these elements i think it’s can be a little difficult,
I wanna ask you, what are technical possibilities to add for example a new record in security
privilieges or sec Role table , to be able see it in SystemSecurityConfiguration Form in D365FO,
I would highly recommend not modifying the tables surrounding security data in the database.
There are two options when setting up security in D365FO: either through the AOT or through the D365FO user interface.
Personally I think the process of creating security in the AOT for D365FO is easier than AX 2012.
I would recommend that users only make security changes in either the AOT or user interface for simplicity.
For more information about setting up security from the AOT, feel free to check out Part II of this security setup series here: https://alexdmeyer.com/2018/07/19/setting-up-security-in-dynamics-365-for-finance-and-operations-part-ii-from-the-aot/
Hi Alex,
Thank You for your detailed outline on this topic and for explaining how front-end security blends/relates with AOT. In that regard a couple of more questions, what are the functions of the “Synchronize all” and “Repair” buttons.
Regards,
Alex T
Synchronize all -> Performs the same process as a Publish All in the Unpublished objects area, takes all security changes done in the user interface that have not been published and publishes them making them ‘live’ security
Repair -> Rebuilds indexes in the database on security tables to help with performance (I’ve never had a need to actually run this)
Is it best practice to publish all your changes after your make them or if you decide you don’t want them, undo & publish? I just came on to help a client that has over 100 unpublished changes in their security setup, so I’m hesitant to make updates and publish any of the roles because I don’t know what else I’ll be publishing along with them. Would it be better to hit the Undo button and publish them all so they get removed from the list before I make my own changes & publish?
Megan,
The issue you are describing is one of the pain points of making changes from the user interface, especially in your situation not knowing what else is in those Unpublished Objects changes because Microsoft does not give you a good way to see the potential changes or an easy way to undo changes.
If this is a non-production environment, depending on the situation I would almost suggest removing all entries from the SecurityUnpublishedObjects table directly in SQL and starting over as then you would know what you are actually publishing.
I wrote about the Unpublished Objects area and why adding an undo button here is so hard.
Feel free to reach out if you have additional questions.