<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

What’s In the New Security Model in Microsoft Dynamics 365FO?

Nobody moves their ERP to the cloud to take advantage of the improved security model. However, Microsoft has introduced several changes in their security model from AX 2012 to Microsoft Dynamics 365 Finance and Operations (D365FO). Users should be aware of the changes in the security model between these applications and how these changes might affect their licensing.

Changes in object permissions assignments

In AX 2012, Microsoft introduced roles, duties, and privileges to control security using a pessimistic security model, which means a user has no access to anything unless permission is explicitly granted to them. Objects are assigned to a privilege (view, edit, create, full control, etc.) by access type with only one access level per object.

D365FO provides multiple access levels per object, giving administrators more granular control over the access types, including unset, grant, or deny.

  • Unset – Unset is the default permission and does not grant access, but also does not prohibit access from being assigned by another role.
  • Grant – Granting permission provides the user access to a particular object at the specified access type level.
  • Deny – Denying a user permission will ensure a user does not have access to a particular object regardless or any other rules set for that user.
Impact the system environment has on security

Where security is created/modified (whether in the application itself or in the AOT) impacts where these changes are stored for D365FO. This is different from AX 2012, where regardless of where the change was made, security was stored in the AOT. The reason for this is because of the separation of the design time (where code is developed) and runtime (where code is executed) elements in D365FO.

For D365FO, if a security change is made in the AOT that change is stored as a ‘development artifact’ and is treated the same way as code. If a security change is made from the user interface, that change is stored as data within the data. When the security framework determines what the ‘effective’ security is, it takes into account security from the AOT and the user interface.

Customizations performed in the UI will override changes performed in the AOT. Customizations done in the UI are not ‘development artifacts’ and do not exist as code in the AOT. It’s important that a customer has a process for modifying security and ensure that the process is followed. An easy way to think of this, is to treat your security as ‘code’, meaning that it should go through the same testing and deployment process as any custom code.

Security is tied to licensing

The privilege and object permissions assigned to the users within the application affects the licenses required for those users. Limiting the access given to a user will help reduce that user’s licensing requirements, saving your company money.

Read the complete eBook based off of the webinar, "Don't Ignore Security When Migrating to D365FO in the Cloud", by clicking HERE.

Get the eBook: Don't Ignore Security  When Moving to D365FO in the Cloud