As support for Dynamics AX nears its end,* more and more organizations are considering upgrading to Microsoft Dynamics 365 for Finance (D365 Finance). Understandably, this transition will come with many functional and technical changes – some of which involve maintaining application security. In this two-part blog series, we will explore the high-level differences in security features between AX 2012 and D365 Finance. The first part of this series will cover the Dynamics security model and changes in the way security is managed, while the second will focus on the tools available to identify, troubleshoot and resolve security-controlled access.
*Support for AX 2009, AX 2012, and AX 2012 R2 will end in 2020 and support for AX 2012 R3 will end in 2021.
Dynamics security model
Unlike some ERPs, the shift from on-premise to cloud did not come with a major security overhaul. Fortunately for Dynamics security teams who are making the transition from AX 2012 to D365 Finance, the overall security model remains largely the same.
Table access
One difference to note involves the way users are granted access to tables. In AX 2012, a user must always be explicitly granted access to the menu item and the underlying table in order to see or modify the corresponding data. This can lead to some confusion because the level of access (display/update/delete) can be adjusted on both the menu item and the table, and it can be hard to diagnose exactly where a user’s access is coming from.
In D365 Finance, this aspect of the security model has been simplified. Granting a user access to a menu item will automatically grant them the same level of access to the underlying table. Therefore, in most cases, identifying and assigning the correct table is not required (although still possible – and there are a few scenarios where an additional table assignment might still make sense).
Access level options
Another minor change in D365 Finance is that objects may be assigned multiple access levels in the user interface. When setting an access level in AX2012, a security administrator would choose between permissions such as view, edit, create, correction or full control – with each access level encompassing the access level below it (e.g. if you can create, you can also edit and view).
In D365 Finance, the security administrator can select multiple options from read, update, create or delete. Technically, this means a security administrator could assign the create permission without assigning the read permission; however, the leading practice would be to continue assigning access levels in a hierarchical fashion (with the hierarchy being read, update, create and delete from the lowest level of access to the highest level of access). For example, if create is assigned, also assign update and read; if assigning delete, also assign create, update and read, etc.
Other changes related to managing security
There are a few other changes to the way security is managed in D365 Finance that Dynamics security teams should be aware of:
AOT and security development tool
AX 2012 security teams are undoubtedly familiar with the benefits of leveraging the Application Object Tree (AOT) and the security development tool while managing security. In AX 2012, system administrator access automatically grants access to the AOT (CTRL + D). In D365 Finance, the AOT still exists, but it requires a few extra steps to access (this involves remoting into the virtual machine hosting the Application Object Server (AOS), running Visual Studio as an administrator, and launching the application explorer.
While the AOT and security development tool are not as easily accessible in D365 Finance, most of the features are still inherently available within the application itself. For example, instead of using the AOT to explore role, duty, and privilege hierarchies, you can view this information on the Security Configuration screen (Security administration > security configuration).
One useful feature of the security development tool that is not available through the user interface is the ability to directly simulate security access without logging in through a test user account. For system administrators who are unable to remote into the AOS, this means test user accounts will need to be leveraged to experience role access first-hand.
Security migration
In AX 2012, there is one main approach to migrating custom security from one environment to another. Security teams would create a project in the AOT and choose security components to add to the project. Then, a deployable package can be exported from the current environment and imported into the desired target environment. While this is still an option in D365 (more to come on the technical differences in this approach for migration in our next blog) – there is one additional way to migrate security at the user interface level in D365 Finance.
On the Security Configuration screen, a user has the ability to export all security customizations (System administration > Security Configuration > Data > Export/Import). This method is arguably easier than creating a deployable package, but gives security teams almost no control (there is no easy way to choose which customizations should be included – it is all or nothing). When the XML file is imported into the next environment, all existing customizations will be overwritten.
Change publishing
When making security changes in D365 Finance, security teams will also notice a new concept next to the Roles, Duties and Privileges menus called “Unpublished objects”. In AX 2012, a member of the security team could make a change to a security object, save that change, and it would immediately become live in the system. In D365 Finance, the security team must make the change to the security object, find that change in the Unpublished objects menu (populates automatically), and then select and publish the object from that screen in order to make the change live. Once the change is published, any affected user just needs to refresh their browser window to see the change reflected in their access
For organizations transitioning from AX 2012 to D365 Finance, the overall security model may be considered a familiar face in a crowd of changes.
While a couple of useful security features from AX 2012 may be harder to access in D365 Finance or require a couple of additional steps, experienced security teams should have little trouble making the transition. In fact, D365 Finance also has a few new features related to troubleshooting security that should alleviate, if not improve, the security team’s ability to maintain application security during and after the upgrade. Stay tuned for Part 2 of this blog series, where we will cover helpful new features in D365 Finance such as task recorder and security diagnostics.
To learn more about Protiviti’s Microsoft capabilities, please visit our Microsoft Solutions site or contact us.
Join our Microsoft Dynamics 365 for Finance and Operations Webinar, Thursday, March 26 at 1:30 p.m., eastern. Register now!
