1. Security Overview of Dynamics AX and D365FO
Alex Meyer
Director of Dynamics AX/365FO Development
Fastpath, Inc.
Twitter: @alexmeyer_ITGuy
Blog: d365foblog.com

2. Agenda Welcome AX 2012 Security Model Overview
D365FO Security Model Overview
Security Development Tool
Demo
Common Data Service
GDPR Features
Questions

3. AX 2012 Security Model
Hierarchy based users are assigned roles which are made up of duties which are made up of privileges and access to tables, forms, menu items are assigned to privileges.

4. AX 2012 Security Model AX 2012 D365FO Pessimistic security model
Template Roles, Duties, Privileges are delivered
Roles are system wide
User roles can be restricted by legal entity
Record level security is available
Replaced by Extensible Data Security (XDS) Policies
Setup users via Active Directory Groups
Security reports – limited
D365FO
Follows the same security model with minor differences
Pessimistic security model – user only has access to objects they have explicitly been given permissions to
XDS – Restrict access to data based on effective date, sales territory, or organization
Setup users via Active Directory Groups – authentication in AX is done by Active Directory, so you can create an AD group, put AX users into that group, then setup and assign security to that group within AX, all users in that group will be granted the security of the group

5. Assigning Object Permissions
AX 2012
D365FO
AX 2012:
Hierarchy based
No access -> View -> Edit -> Create -> Correction -> Full Control (Delete)
One access level per object
D365:
Still hierarchy based
Can have multiple access levels per object
Unset – No access is assigned
Grant – access level is granted for this access type
Deny – explicitly denying access to an object overrides any grants assigned to the user from any other role, duty, or privilege

6. Environment Differences
AX 2012
Design time and runtime
lived in same environment
D365FO
Design time is on development
VM, runtime is web app in Azure
Design Time: Where code is developed and customized
Runtime: Where application is actually ran
D365FO
Design Time: Visual Studio environment
Runtime: Azure
If you create/customize a role, duty, or privilege in the UI, a delta is created and applied to the environment to reflect that change
Customizations done in the UI are not ‘development artifacts’ (code) in that they cannot be moved from the runtime to design time currently (Microsoft working on making a method to do this)
This is a big deal because if you want to move roles between environments (dev/test -> prod) you need your security to be in the design time(code) to be able to create a package to move
Best advice, is to create all role, duties, and privileges in your design time environment (Visual Studio) so all of your security changes are captured and can be applied to other environments.

7. D365FO Data Security
Transparent Data Encryption – Data and logs in Azure SQL are encrypted at rest
Table Permissions Framework (TPF)
Used for High Business Impact (HBI) data
Users must be given explicit access to field otherwise it will be hidden
Can be applied at field level
Extensible Data Security (XDS) still available
Transparent Data Encryption – client does not have to do anything to set this up, it is all done by Azure SQL behind the scenes
Table Permissions Framework – With Dynamics 365 can not be applied at the field level for the table, in AX 2012 this had to be turned on at the table level first and then each field of the table would have to be set manually

8. Entry Point Security If accessing the form through menu item 1:
In AX 2012, the effective permission to the table is DELETE
In D365, the effective permission to the table is READ
D365 honors the menu item permission when accessing the form
One main difference in security from AX 2012 to Dynamics 365 is entry point security.
In the scenario we’re looking at here we are going to assume you are accessing a form within either AX/Dynamics 365 through a menu item (in our case menu item 1) that you have READ access to. You also have access to this form through another menu item at a DELETE level. In AX 2012, the security framework took the highest permission level that you had through a menu item and applied it to the table. Which means in this case, you would have DELETE access to the table and because command buttons on the form were tied to table access this would inadvertently allow users who had accessed the form through a READ menu item to modify the object (an example of this would be the DELETE button being enabled).
In Dynamics 365, the menu item permission is honored when accessing a form. So if you access a form through a READ menu item, you will only have READ access to the table, if you access the form through a DELETE menu item you will have DELETE access to the table.

9. Data Entities New to Dynamics 365
Encapsulates a business concept that may exist across multiple tables with Dynamics 365
Allows for easy CRUD operations (especially from outside of Dynamics 365)
Template Data Entities come out of the box, can create customized ones as well
Have their own security property called Integration Mode
Basically it’s a SQL view that allows for CRUD operations
As far as security, treat them as a table
Data services - The ability to use OData services (API) for the entity.
Data Management - The ability to use asynchronous integration options for the entity, such as import/export and connector integration.
Gives ability to interact with the system without writing X++ or going directly to SQL

10. Security Development Tool in AX
‘Beta’ tool from Microsoft
Security reporting
Task Recording
Test workspace
Reduces need for test user accounts
Limitations
Cannot open test multi-role assignment (Can use sub-roles)
Does not work if you use AD Groups for user provisioning
Licensing
D365 – Where’d it go?
Beta tool from Microsoft, it’s been in beta since AX 2012 was released and probably will probably never be ‘officially’ released
Had it’s own model file you had to import to add to your environment
Allows for getting very granular security reporting (role -> duty -> privilege breakdowns)
Task recordings (recording steps taken within the application)
Allows for testing a role within a test workspace without having to assign the role to a test user for testing
Has licensing reports surrounding users
There is no separate security development tool in Dynamics 365, Microsoft has decided to bring most of the features over and put them directly in the application itself
The reason they did this is because in AX 2012, the design time and run time environments sat on the same machine so it could interact with both
With Dynamics 365, the design time is completely separate from the runtime so the tool had to be written into the application itself

11. Demo

12. Common Data Service
Centralized database to aggregate data from multiple systems
Includes mappings from source to destination environments
Comes out of the box with standard entities called the Common Data Model, can also create custom elements
Being transitioned to new version called Common Data Service for Apps (built on XRM platform with Power Apps front-end)
Since CDS is built on XRM platform, security model follows CRM security model
Roles -> Privileges
Sharing Access Levels: Global, Deep, Local, Basic, None
CRM Security Model
Out of box: Roles (14) -> Privileges (580+)
Access Levels:
Global - This access level gives a user access to all records within the organization, regardless of the business unit hierarchical level to which the instance or the user belongs. Users who have Global access automatically have Deep, Local, and Basic access, also.
Because this access level gives access to information throughout the organization, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the organization.
The application refers to this access level as Organization.
This access level gives a user access to records in the user's business unit and all business units subordinate to the user's business unit.
Users who have Deep access automatically have Local and Basic access, also.
Because this access level gives access to information throughout the business unit and subordinate business units, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business units.
The application refers to this access level as Parent: Child Business Units.
Local - This access level gives a user access to records in the user's business unit.
Users who have Local access automatically have Basic access, also.
Because this access level gives access to information throughout the business unit, it should be restricted to match the organization's data security plan. This level of access is usually reserved for managers with authority over the business unit.
The application refers to this access level as Business Unit.
Basic - This access level gives a user access to records he or she owns, objects that are shared with the user, and objects that are shared with a team of which the user is a member.
This is the typical level of access for sales and service representatives.
The application refers to this access level as User.
- Example usage would be creating a user or sales order in one system and wanting to push that data into D365FO, you would push that data into CDS from the source system and D365FO as the destination system would consume that
- Continuing with this example though, now you can modify D365FO data from outside of D365FO and could bypass the application security all together
- Also your D365FO data could live in this database as well (GDPR concerns)
- If you are planning on using this system you should have a plan in place for auditing this feature for security

13. GDPR Features Roles with Sensitive Access
Located in System Administration -> Inquiries -> User Log
Records all user logins to environment, can also specify roles that have ‘sensitive access’ whenever a user logs in and is assigned one of those roles it is recorded

14. GDPR Features Asset Classification on table fields
Available on all table fields
Added in PU8
Allows for classification of data that resides in the table field

15. GDPR Features Asset Classification on table fields
Customer Content – data collected and managed by the controller
End User Identifiable Information (EUII) – natural value used to identify a user of the service
End User Pseudonymous Information (EUPI) – generated value used to identify the user of the service
Organizational Identifiable Information (OII) – value used to identify the organization using the service
System Metadata – value that describes the software or used by the software
Object Metadata – value that describes the software or used by the software
Account Data – value provided by or used by the tenant to identify the billing information or identify the software
Support Data –information used to provide customer support

16. GDPR Features Person Search Report
Can search by Id, Name, or Address Information

17. GDPR Features Person Search Report Results
Example results of the person search report

18. Common Security Challenges
Access security is low priority for project team
Everyone assigned System Administrator
Security is in the domain of IT/Sys Admin not BPOs
Expensive customizations in place of security
No consideration for segregation of duties
Process controls not part of the design
Dilution of ‘go-live’ security design
Access security is a low priority for project team
If user says they need permissions to x, y, and z it’s easy to just give them this access without thinking of ramifications of that
User productivity > validating user should have this access
Everyone assigned sys admin
Easy cop out
Something to watch out for if using customizations or 3rd party vendors (make sure to get a least privilege role set up)
Security is in domain of IT not BPOs
BPOs know what user should have access to but don’t have permissions or understanding of system to correctly assign rights to user, IT has ability to assign these rights but no idea if users should have these rights or issues that could arise from assigning these rights
Expensive customizations in place of security
Instead of addressing security directly, sometimes complex customizations are applied to enable/disable certain features
Can add unneeded complexity and might incur a performance impact
No consideration for segregation of duties
During designing of security, very rarely are SOD principals kept in mind.
Much easier to design initial security with SOD in mind rather than going back after the fact and reconfiguring security to include this
Process controls not part of the design
During security design, controls for SOD issues are not designed and/or documented.
Being able to effectively document current controls ahead of time will save you a lot of time/stress during an audit
Dilution of ‘go-live’ security design
It is important to get security set up correctly at ‘go-live’ but also to important to revisit your security on a periodic basis
‘Permission creep’ can occur where users just accumulate permissions and user access is not reassessed
No user is ever going to complain about having too much access

19. Reviewing Security Take a risk based approach to reviews
Monitor and report on user access
BPOs should review access
Update process controls and SOD rules to reflect security changes
Take a risk based approach to reviews
Not every permission within AX is important or critical when reviewing access
Limit down scope to critical areas when doing reviews
BPOs should review access
IT does not know whether a user should have a particular access
BPOs should be involved in access reviews to validate security
Monitor and report on user access
Have a process to be able to report on user access
If an auditor came to you tomorrow and asked which users have access to a particular object could you answer them?
SysAdmin - Obviously very important to know who is assigned this role at all times
‘Firefighter access’ situation, make sure role is revoked
Update processes, rules, and matrices
As security changes, you will want to revisit controls and SOD rules

20. Resources Book Whitepaper Security Matrix
Security and Audit Field Manual for Microsoft Dynamics 365 Finance and Operations
2nd Edition available at Summit Phoenix
Whitepaper
Develop and Implement Least Privilege Security for Dynamics 365 for Finance and Operations
Security Matrix
AX 2012
D365FO

21. Fastpath for Dynamics AX/365FO
Fastpath ensures our customers can confidently answer
these three critical questions:
Who has access
to their systems? 
What did they
do with that access? 
Where are they
vulnerable?
Assure
Segregation of Duties and
Security Access Reviews
Audit Trail
Critical Data Change Tracking
Identity Manager
Compliant User and Emergency Access Provisioning
Security Designer
Create and Change Security in Dynamics
Assure – shows where users have access and how they are getting that access
Audit Trail – shows what users are doing with their access
Identity Manager – workflow around user provisioning and modifications
If you have questions or interest about our products feel free to contact or

22. Links Dynamics 365 For Operations Blog (Personal Blog)
YouTube Tutorial on Simulating the Security Development Tool in Dynamics 365 for Operations (5:35)
D365 Wiki
Task Recorder in Microsoft Dynamics 365 for Operations
Security Development Tool User Guide
Microsoft Dynamics AX 2012 R3 Licensing Guide
Introduction to Microsoft Dynamics 365 licensing
Dynamics AX Server Team Blog
Role-based Security Use Patterns for Developers
Developing Extensible Data Security Policies
Security Roles & Licensing Whitepaper‎
Table Permissions Framework
Transparent Data Encryption
Understanding Security in Microsoft Dynamics AX 2009

23. Questions? Alex Meyer Director of Dynamics AX/365FO Development
Fastpath, Inc.
Twitter: @alexmeyer_ITGuy
Blog: d365foblog.com