Moving D365FO security from user interface to AOT

I wanted to show how you would use this tool to actually take changes made in the user interface and move them to your AOT.

1. Export user interface security changes from D365FO

• Go to System Administration -> Security Configuration -> Data tab -> Export

This will export an XML file with all security customizations that have been done in the user interface.

2. Download the D365FO Security Converter

• When you launch it the input file will be the exported file from the user interface.
• The output location is the location where the output files will be saved.
• Click ‘Process’ button, this will parse the input XML and display the different security layers that have been customized in the user interface (and therefore exist in your security delta).
• You can then modify the Name, Label, and Description parameters of any security layer.
• When you are ready you can click the ‘Export’ button and the files will be exported.

One thing to note here is that the Name field will almost always have to change based on one of the following conditions:

• If you are modifying an out of the box role/duty/privilege:
  • You will want to either rename using your company ‘customization prefix’.
• If you created a new custom role/duty/privilege:
  • D365FO will create a random GUID for the system name of the security layer, as this isn’t very descriptive you will want to change this.
• If you are modifying a custom role/duty/privilege you created previously:
  • You will want to be sure you change the name column to the same value as you did previously.

The reason you have to change the name is that if you take an AOT XML to an environment that already has an element of the same name you will get build errors when you try to compile the project.

What is a Customization Prefix?

A company should have a 2-4 letter prefix they attach to all custom objects they create in AX/D365FO, and that includes security layers. In the highlighted example above you can see I added ‘Abc’ to the front of WHSWarehousePlanner. This lets everyone in your organization know that this is a custom object that has either been created by or customized by your company.

3. Now – you can actually create this security in a D365FO project.

• If you have a process for making security changes already; go ahead and follow that procedure, otherwise, my suggestions for setting this up would be:
  • Create a model just for security (this way you segregate security changes from any other code changes), prefix model with a decided company customization prefix.
  • Create a security project, with Roles, Duties, and Privileges folders.

• Setting up your security project in this way allows you to easily and efficiently manage security, make modifications, and build deployable packages as needed without affecting other code customizations.

4. Copy the AOT XML files from the output of the D365FO Security Converter to the appropriate development folder in your D365FO security project.

• So for example, copy any roles from the AxSecurityRole folder in your output to the Roles folder in your D365FO Security project.

5. Go to the appropriate folder in your project for the security layer you are looking to add, right-click -> Add -> Existing Item… and find the XML file you just copied into your project directory.

Once it is added you will see Visual Studio will immediately recognize it as a security element (in this case a security role) and list its properties. You can validate that the Name, Label, and Description are correctly brought over from the changes you made in the D365FO Security Converter tool.

And if you open the security layer up, you can see all of the duty and privilege associations and object assignments are still there as well.

6. After a build and a database sync of the project, you can validate that the security layer has been added successfully by confirming it in the user interface and AOT.

• In the AOT:

• In the user interface:

7. Once the security has been moved to the AOT, it becomes part of your custom code and should follow your normal code promotion process from DEV -> PROD (and all the steps in between in your org).

8. Optional final step – if you are moving security from the user interface to AOT within the same environment you will probably want to remove all user interface customizations at this point as they all exist in code. This can be done from the System Administration -> Security Configuration -> Data tab -> Remove Customizations. If this step is not done, any further security changes done to the security layers you brought over in the AOT will not be reflected as the user interface version will still be overriding it.

Conclusion

In my view, managing security as code is much easier which is why I went about writing the D365FO Security Converter in the first place.

I hope this has helped show how it is possible to take changes made in the user interface and move them to your AOT. If you have any questions on the process please feel free to reach out!

D365 for Finance and Operations: Security Features

I recently participated in the AXUG- Orlando Chapter meeting, security and the four license types were brought up.  As the meeting went on it appeared that there was some confusion around security so I want to dive a bit deeper into how it is configured in D365.

D365	AX 2012 Equivalent
Operations	Enterprise
Activity	Functional (introduced last summer)
Device	Retail and Warehouse (Mobile)
Team Member	Record T&E, Contacts, Tasks, Activities

Assigning Security

Let’s first start at a high level.  Only authenticated users who have rights and security setup in D365 can connect to the application.  This is similar to the way AX is configured.  You cannot log into AX without an account.  your account also needs to be established in the Microsoft Azure Active Directory.  Without the active directory account, you will not be able to locate your account to add to D365.  Once an account has been created in D365, security will need to be placed on the account.  Much like AX 2012, users will see the same breakdown of Role> Duty> Privilege> Permission in D365.  A security administrator will add roles to the newly created account. 

D365 comes with approximately 85 roles, 850 duties, 8000 privileges, and 25,000 permissions so security can be broken down at granular level.  From a naming standpoint, AX 2012 users will feel familiar with Inquire/View equaling a read access, Maintain equaling full control, and Enable equaling a setup duty or privilege.

Creating Security objects

Just like there was in AX 2012, there are two ways to create security objects in D365.  The first way is in the backend where a developer can create & edit roles, duties, and privileges in the AOT and deploy those changes.  The second way is within the front end of the application where an end user containing appropriate permissions can make changes.  There is a slight difference between AX 2012 and D365 when making front end changes.  In prior versions of AX, a change automatically updated objects on the back end, whereas D365 has these changes stored as data and they need to be published for a commit.  Note: Since these front-end changes are data, there may be instances where the changes get overwritten.  Please be aware of this risk.

Highest Access changes

In AX 2012 there was a rule of thumb that if we had multiple menu items accessing the same table, the highest access would win, and the user would inherit the higher access.  That is no longer the case as D365 applies the lowest access.  As an example, if a user has 5 menu items that call the same table, 4 of which have delete access and 1 that has read access, the read access would supersede all 4 deletes.  This new “highest access” rule of thumb also applies to a scenario where a user has two roles.  If a user has a role that allows them to create a customer, and a second role that prevents them from creating a customer, the prevention will supersede the create and the user will not be able to create a customer.

Task Recorder Feature

A new security feature has also been intertwined with Task Recorder, and is extremely beneficial.  This allows users to create task recordings of a business process, and figure out what type of security is needed.  This analysis can be executed in a Dev environment for all security testing.  Simply create a process in Task Recorder, save the task file to your PC, Navigate to System Administration> Security Diagnostics for task recordings, select the “Open from this PC,” select the .axtr file you want to analyze, and click open.  My example was creating a vendor with a bank account, and from the analysis you can see that I needed the VendBankAccounts menu item name.

Analysis

From this screen I can also grant security to a user based on the Menu Item Name.  If I click the Add Reference button, a list shows up that displays all security objects ttied to the entry point.  The screenshot below shows everything associated with the VendTableListPage.  From here we can add Roles to ISAAC’s user ID simply by clicking the Add roles to user.  You will be redirected to the accounting manager role, and will be able to manually add ISAAC.

One Click Security Diagnostic

Each form in D365 also has a Security Diagnostic Button.  To access this button, navigate to the options button on a form, and click Security Diagnostics.  This will show all roles, duties, and privileges that grant access to the current form.  This is a very handy tool for quick reference.

These are some of the main differences between prior versions of AX and D365, and rolling out security in your D365 instance is no longer as daunting as it may seem.