D365 for Finance and Operations: Security Refresher

Posted on: March 16, 2018 | By: Jarrod Kraemer | Microsoft Dynamics AX/365

Authored by: Dave Occhionero

I recently participated in the AXUG- Chicago Chapter meeting, and additional information was provided to us regarding D365 On-Premise deployments.  We learned about the minimum AOS requirements (3), and that there were no minimum user requirements.  This has been the case for all on premise deployments for AX.  As the presentation continued, 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.  For additional information please feel free to reach out to us at info@loganconsulting.com or (312) 345-8817.  


All the best!
Logan Consulting

www.loganconsulting.com



2020 Nucleus Research Report on ERP Technology

Free Download:

2020 Nucleus Research Report on ERP Technology

Download the guide ›