Security and Audit Field Manual for Dynamics 365 for Finance and Operations, Enterprise Edition Book Announcement

A little different post than normal, but some very exciting news coming today.

For the last couple of months, the Fastpath team has been working on taking our in-depth knowledge of D365E security, audit, and compliance to create an educational book on the topic. I’m very pleased to announce that the Security and Audit Field Manual for Dynamics 365 for Finance and Operations, Enterprise Edition is officially released. This book is the culmination of work by Fastpath team members Mark Polino, Andy Snook, and myself and dives into the security and audit side of D365E. This book is unique in that Mark and Andy cover the audit side of things with their vast knowledge of compliance and overall auditing best practices and I cover the application security side, so you get perspectives from both how you should set up your security, design process control, etc and then how to actually do those actions in the D365E application itself. Also as D365E changes (and we all know it will) we will revisit this and ensure to release updates if the information changes.

The book is available in paperback and Kindle formats and can be found here:

Dynamics 365 for Operations and Financials, Enterprise Edition, Security and Audit Field Manual

Also for anyone who will be coming to the Microsoft Dynamics Communities User Group Summit in Nashville, we will have a limited number of copies at the Fastpath booth. So feel free to stop by and say Hi!

 

An Update on How to Simulate the Security Development Tool in Dynamics 365 Enterprise

In an earlier blog post I went into great detail on the changes to the Security Development Tool from AX 2012 to D365 Enterprise: How To Simulate the Security Development Tool in Dynamics 365 Enterprise

In that post, I pointed out that one of the features that was currently missing was the ability to open a test workspace for a particular role or roles to analyze their access. Well through numerous posts with different D365 Enterprise community members, a way to add this functionality has been found. Here is how to add this functionality.

1. So the first thing to know, is that this tooling already existed internally at Microsoft we just have to expose it to the Visual Studio user interface. If you RDP to your D365 development box and go to the following path you will find a Visual Studio extension installer:

<PlatformUpdateRoot>\Services\DevToolsService\Scripts\Microsoft.Dynamics.Framework.Tools.InternalDevTools.vsix

So as an example, on my machine this happened to be the following path:

E:\rainfndprod\7.0.4612.35162\retail\Services\DevToolsService\Scripts\Microsoft.Dynamics.Framework.Tools.InternalDevTools.vsix

This is a Visual Studio extension file, if you double click and install this extension you will notice that a number of options are added to your Dynamics 365 -> Add-ins menu.

Before:

After:

2. One of the added menu items in this list is ‘View with Role Set’ which is the tool we are looking for

3. Click on this opens the dialog below, from here you can select a ‘Role Set’ that you would like to use. One nice feature is that you can select an already existing users and see what roles that user is currently assigned or you can create a new role set and start from scratch. The idea below is to move the roles you would like to test to the Assigned Roles side from the Available Roles. Users who have experience with this feature in AX 2012 will notice one big difference is that you can now very easily select multiple roles to test at once, by default in AX 2012 you could only test one role at a time (you could get around this by using subroles but it was not very user friendly). Once you are satisfied with your choices you can click the OK button.

4. This will launch a test environment with the role(s) you have selected to let you see what a user would have access to if they were to be assigned those roles. Some things to point out:

  • A test user is actually created for this purpose and is assigned the role(s) selected, this user will show up in your user list in your environment (this user also has to be enabled)
  • All tests need to be assigned the SystemUser role otherwise you will get errors launching the test environment as most roles do not have explicit access to the initial dashboard (which is always the first screen to load in the testing environment)

 

This feature set was the last piece to the puzzle of features that existed in the Security Development Tool that did not exist in D365 Enterprise. Hopefully this feature will become part of the default Visual Studio experience and become a little more user friendly but it’s definitely a good thing to know that this feature is there.

New Out of Box Security Reporting in Dynamics 365 Enterprise

Microsoft has added some additional new security reports that can be accessed through the web application. These can be found by going to System Administration -> Inquiries -> Security. Under this section you will find four reports:

  • User Role Assignments
  • Security Role Access
  • Role to User Assignments
  • Security Duty Assignments

User Role Assignment

Shows the user to role assignment and if the access is restricted to any legal entities.

Security Role Access

Shows the roles effective access based on the duties, privileges, and tables assigned to the role. Also shows the effective license required for the role based on its access to entry point objects. It breaks out the access into the following types:

  • Menu Items (Display, Action, Output)
  • Form Control
  • Table Field
  • Data Entity

Role to User Assignment

Shows the role to user assignment and if the access is restricted to any legal entities.

Security Duty Assignment

Shows the role to duty assignment, especially useful if using the out of the box segregation of duties functionality. This report again also shows the effective license type required for users assigned to this role as well.

All of these reports allow for a number of filtering, output options, and options for batching the report execution. They also allow exporting to Excel, PDF, and XML as well a number of other file types.

These reports have been sorely missed in previous versions of D365 Enterprise and AX 2012, I will say that the layout of these reports (especially in Excel) makes it a little hard to discern the information and filter but it definitely is a step in the right direction for baseline security reporting.

New Security Data Entities in Dynamics 365 Enterprise Update 8

With Update 8, Microsoft has added some more data entities surrounding security.

SecuritySubRoles – shows the relationship between role -> subroles

SecurityDuties – shows relationship between role -> duties, this could be used if using the out of box Segregation of Duties functionality from Dynamics 365 Enterprise

SecurityPrivileges – shows relationship between role -> privileges

SecurityPermissions – shows role -> resource (name and type) -> access, this is essentially a role access report

All of these data entities are available by going to <BaseD365URL>/data/<NameOfDataEntity>.

So for example, if your base URL is https://D365Update8 then the calls would be as follows:

  • https://D365Update8/data/SecuritySubRoles
  • https://D365Update8/data/SecurityDuties
  • https://D365Update8/data/SecurityPrivileges
  • https://D365Update8/data/SecurityPermissions

Having these data entities exposed, makes it very easy to programmatically consume these and generate reports off of them. I would point out there there are still some glaring data entities currently missing from the out of box ones generated by Microsoft, specifically:

  • There is no data entity to return all of the roles, duties, or privileges in the system, just the associations between them
  • There is no data entity to return the role -> duty -> privilege hierarchy (missing the duty -> privilege association currently)

I would also be cautious about writing to or deleting from these data entities to change security, as by doing this you have no real control over how this security is implemented (won’t be in version control via AOT change and don’t really know in what layer the security will be modified).

Changes to X++ Development in Dynamics 365 Enterprise

While the end user experience has changed dramatically from AX 2012 to Dynamics 365 Enterprise, arguably the bigger changes are to the development side. This post will go through some of the highlights of this and hopefully give a better understanding of some of the changes that will impact developers in Dynamics 365 Enterprise.

Overview of Development in AX 2012

Need to start by giving a baseline of where development of X++ code was in AX 2012.

AX is broken up into multiple coding layers, these layers allow for independent development and allow higher layers to make modifications to lower layers. Therefore modifications made at the USR level overrode customizations made at the CUS or lower levels.

There is also different levels of grouping your code and metadata together. At the lowest level is a XPO, which is as close to pure source code as you can get within X++, it represents objects and their attached metadata and source code. At the next level is a model which is a collection of source code that normally represents a full solution. These are normally created by clients and delivered by ISVs/VARs as the preferred method of making customizations to AX. These are added to your environment, modifications can then be made (if necessary), and then finally compiled together with the rest of your code for the customizations to take effect. At the highest level is the Model Store which contains all source code, metadata, p-code and CIL. Since this contains already compiled code you do not need to recompile when moved. This is as close as you could get to a compiled binary in AX 2012.

When developing X++ the source code was compiled into p-code which was interpreted by the X++ interpreter at runtime.

Where We’re Going in Dynamics 365 Enterprise

With the release of Dynamics 365 Enterprise a number of changes to the development environment, lifecycle, and methodology have occurred.

Changes to X++

The X++ compiler has been completely rewritten and now generates .NET CIL (Common Interface Language) only, so there is no more p-code. This is step forward for a number of reasons:

  • .NET CIL is normally faster than interpreted p-code
  • Can interface easier with other managed languages (like C#)
  • No need for the .NET Business Connector

Models File vs Deployable Package

A model file in AX is development object that contains source code and metadata, in AX 2012 this is the preferred method of transferring customizations and deploying code to clients. Client’s can see the actual source code and could make customizations to it before compiling it into their solution. A deployable package in Dynamics 365 Enterprise is a .NET CIL compiled version of your source code and metadata, it can contain multiple model files. This is the preferred method of transferring and deploying code in Dynamics 365 Enterprise, especially in production instances as you would not have access to the AOS or AOT to add a model file. One of the many benefits of this from an ISVs perspective is that the client can no longer see your source code as the source code is already compiled to .NET CIL, they can however still create extensions of your code (we will go into details of what this is in the next section).

Extensions vs Overlayering

In previous versions of AX, when a customization was added to an environment (either from a client or from a VAR/ISV) it was delivered in the form of a model file. This model file would be applied to the correct code layer and the customizations of this model could modify elements of code that were at a lower code level. This idea of modifying code at a lower code level is called overlayering and is a staple of development in AX. With the move to the cloud of Dynamics 365 Enterprise and the need for Microsoft to be able to control their source code (specifically for updating their platform on a periodic basis), the idea of overlayering has gone away and has been replaced with the idea of extensions.

Extensions are still customizations of objects but instead of making modifications to the actual object, you are leaving the default object functionality and creating new functionality to implement your customization. Extensions can be created by either subscribing to pre/post events on methods or by creating class extensions. It is vital for customizations to be moved over from the overlayering methodology to extensions because Microsoft is actually locking down all models from overlayering customizations. They are doing this in a two step process, first a model will be soft sealed and you will receive a warning during the compilation of your solution, then it will be hard sealed and you will receive an error during compilation of your solution and it will no longer build. The ‘tentative’ roadmap of this process is below.

Changes to Development Environment

All development is now done within a modified version of Visual Studio that lives in a virtual machine running Windows Server and an entirely contained instance of Dynamics 365 Enterprise. For those who have written code in the old MorphX editor this is an absolutely huge improvement as you are now able to use all the tools and features already built into Visual Studio. These include:

  • Native integration with Team Foundation Services (TFS)
  • Merge tool features
  • 3rd Party Addins (Resharper, etc)
  • Other native functionality of Visual Studio

The version of Visual Studio installed on the VM includes a Dynamics 365 menu, this menu has a number of options that are needed for development and deployment of X++ solutions.

Deploy – if you need to create a deployable package from your solution

Model Management – where you can create a model or update a model’s parameters

Build models – where you can build any model that is currently in your environment

Synchronize database – If you create/modify/remove a database element (table, view, stored procedure, index, etc), or if you create/modify/remove a role, duty, or privilege you will need to run this process for your change to be synced to the database

One thing to note is that development environments should not (and cannot) be shared between developers, each should have their own VM environment to develop on. Developers should also be using some sort of code repository (TFS, Git, etc) to organize your code, and best practice is to use some sort of branching methodology (Dev/Main/Release etc) with your code check ins and releases.

Another Name Change?

Yeah you read that right, it is looking more and more like Dynamics 365 Enterprise will once again get another name change. This image showed up on LinkedIn and was shared by a number of Microsoft employees. No final decision has been made on when the name change would go into effect but looks to be around July 1st.

Sources

Programming Language Support

Development Changed in Dynamics 365 Enterprise

Announcing Application Extensibility Plans

MorphX Development Tools for AX 2012

Customize with Extensions and Overlayering

TFS Branching

Comprehensive 3 part series showing the shift from AX 2012 Development to Dynamics 365 Enterprise (written by Joris de Gruyter of Microsoft)

Design-Compile-Run Part 1: 2012 Paradigms

Design-Compile-Run Part 2: Run in AX 2012

Design-Compile-Run Part 3: Run in AX7

Security Reporting for Dynamics 365 Enterprise in the AOT

Reporting on security within Dynamics AX/365E has always been tough but after sitting through a number of talks at the D365 Tech Conference there looks to be a push to improve this reporting. Reports have been slowly making appearances as new D365E releases emerge but in kind of a hidden place, in the Dynamics 365 Visual Studio toolbar menu in the AOT. To find these reports launch Visual Studio in your D365E development environment and go to Dynamics 365 -> Addins. Under this menu are a number of reports that pertain to security as well as other reports that help with customizations.

 

Import Task Recording

This feature allows you to import a task recording you have previously exported and it will create a new D365E project with a test case that will perform the steps you did in the recording. In the screenshot below I uploaded a recording where I modified a vendor’s number of employees. This can be very useful for creating test cases for individual steps of the task recording or to troubleshoot where issues are arising in the process the task recording is performing.

View Related Roles For All Duties

This option exports an Excel file that shows the role -> duty assignments. This report is not easily generated in through the user interface.

View Related Objects and Licenses For All Roles

This option exports an Excel file that shows two tabs: License Information and View Related Objects

On the License Information tab you will be able to see all roles, duties, and privileges and the license type that is required for that particular security type. This report is not easily generated in the user interface.

The View Related Objects tab has a very large report that shows the entire hierarchy from role -> duty -> privilege -> resource -> resource type -> access levels assigned to the resource as well as the license type tied to that particular access. It is a very comprehensive report that mimics the report you can find in the View Permissions feature in Security Configuration through the user interface.

Another option for getting security reports is open any role, duty, or privilege with the Designer and right click and going to AddIns.

View Related Objects – shows the same report as the View Related Objects report from above for one specific role, duty, or privilege

View Related Roles – if you execute this function against a duty you will see the role(s) that this duty is assigned, if you execute this function against a privilege you will see the role the roles and duties that this privilege is assigned to.

An advantage of exporting these reports in the AOT is that all the results of the report are exported in the resulting Excel file, if you export these reports through the user interface you will be limited by the top 2000 results.

Determining User Licenses in Dynamics 365 Enterprise

Microsoft’s licensing in Dynamics AX and Dynamics 365 Enterprise is based on the access each user has to entry points (menu items etc) in the system. Each entry point has two separate user license properties, ViewUserLicense and MaintainUserLicense. The ViewUserLicense property is applied if the user has view rights to the entry point, the MaintainUserLicense property is applied if the user has above view rights to the entry point. Based on the access a user has to the entry point will determine which user license property is applied to the user, and therefore which license a user is required to have to have access to that entry point.

You can see what license type each access requires by going into Security Configuration selecting a role, duty, or privilege and clicking on ‘View Permissions’ in the menu bar.

You can also see what license type each entry point has in the AOT by looking at the properties.

In AX 2012:

In Dynamics 365 Enterprise:

There are four hierarchy-based license types in AX 2012:

  • Enterprise User (highest)
  • Functional User
  • Task User
  • Self Serve User (lowest)

 

In Dynamics 365 Enterprise this hierarchy has been simplified to only include two levels:

  • Operations (will be listed as Enterprise in AOT)
  • Team Members (will be listed as Universal in AOT)

 

From a pricing perspective, the higher the license type is in the hierarchy the higher the cost associated for that license. With this is mind, it is very important to not over provision a user’s access and be charged for a higher license than is really needed. Along with this idea it is also important to note that the highest user license a user is assigned, based on their access, will be applied to that user. By that I mean that if a user has access to 100 entry points and only one of those entry points is at an Enterprise level that user is required to have an Enterprise/Operations license.

The simplification of user licenses from AX 2012 to Dynamics 365 Enterprise as well as the added reporting around user licenses makes it much easier for clients to determine how many licenses of each type are needed for their environment. But it is still important to keep licensing in mind while designing and applying user security.

References:

Microsoft Dynamics AX 2012 R3 Licensing Guide

Introduction to Microsoft Dynamics 365 licensing

Batch Jobs in Dynamics 365 Enterprise

A batch job in Dynamics 365 is a collection of tasks that are processed automatically by the AOS. Tasks in a batch job can be run sequentially or simultaneously. You can also create dependencies and decision trees between tasks based on whether previous tasks succeed or fail.

The first step of creating the batch job is to create the X++ batch class with the code you would like to execute, a simplistic version of the required setup of this class is below.

Code Side Setup

public class YourBatchJob extends RunBaseBatch
{
 public void run()
 {
 //Code to execute
 }

//Needs to be set to true so class can be ran in a batch
 boolean canGoBatch()
 {
 return true;
 }

//Stores parameters of the batch
 public container pack()
 {
 return conNull();
 }

//Returns the stored object for the batch to use
 public boolean unpack(container packedClass)
 {
 return true;
 }

//Determines whether to run on server or client
//True - Server; False - Client
 public boolean runsImpersonated()
 {
 return true;
 }
}

Setup within Dynamics 365

  1. The first step in setting up a batch job is creating a batch group, a batch group allows you create a collection of batch jobs to execute
  • To set up a batch group go to System Administration -> Batch Groups
  • From here you can create new batch groups as well as determine which batch servers you want to process a certain batch group

2. Next, you can actually create a batch

  • To do this go to System Administration -> Batch Jobs
  • When you create a new batch job you will be able to give the batch a description
  • Batches within Dynamics 365 can have a number of Statuses the most important ones are below:
    • Withhold – batch will not be picked up for execution, batches need to be in this status to edit
    • Waiting – batch will be picked up for execution at next recurrance schedule
    • Executing – batch is currently being executed
    • Ended – batch processes successfully

3. Once you create the batch job, selecting the batch job row in the grid and then clicking Batch Job menu bar will give you options on what you can do next

  • View Tasks – shows the individual tasks of the batch
  • Batch Job History – shows status of previous executions of the batch
  • Recurrence – set up the schedule to execute the batch
  • Alerts – set up alerts for different events of the batch
  • Change Status – changes the status of the batch

4. If you navigate to View Tasks you can set up the tasks the batch will execute, if you add a task you will need to set:

  • Task description – allows you to provide a description of the task
  • Company Accounts – displays which legal entity the batch runs against
  • Class Name – the X++ class name that you want to execute
  • Run Location – will either be client (if no impersonation) or server (if using impersonation)
  • Batch Group – can be set to the batch group that you want the batch to execute with

5. The next step is to set the recurrence of the batch job, this will determine on what schedule the batch job is executed

6. The final step is to change the status of the batch from ‘Withhold’ to ‘Waiting’, once this is done the next time the batch is set to execute the batch process will pick it up and process it

 

Final Note: It appears in DEMO/DEV instances of Dynamics 365 that the Batch Management Service is not set to start by default with the machine, this service needs to be on for batches to be processed.

How to Simulate the Security Development Tool in Dynamics 365 Enterprise

The Security Development Tool is a feature developed initially for AX 2012 that helps to more easily create and maintain security artifacts such as roles, duties, and privileges. Technically this is still a beta tool offered by Microsoft through Life Cycle Services which provides the following features:

  1. Displays entry point permissions for a given role, duty, or privilege
  2. Provides the ability to record business process flows and identify the entry points that are used
  3. Allows for testing a newly created or modified security role, duty, or privilege without having to use a test user account

 

It is an extremely helpful tool that Security Administrators of AX can use during the development of user security. In Dynamics for 365 Enterprise though, the Security Development Tool doesn’t exist as a separate application but instead its features are implemented directly in the application itself.

Here’s a breakdown of where the features of the Security Development Tool now live in Dynamics 365 Enterprise:

  • Full hierarchy view of role, duty, privilege, entry point security assignments
    • On the System Administration -> Security Configuration page if you select a role and choose View Permissions
    • You will then be presented with a report that shows an overview of the role, duty, privilege, and entry point assignment 
    • You can also follow this process to get the same information at a duty and privilege level
  • Breakdown of the roles, duties, and privileges that have access a particular page/form in Dynamics 365 Enterprise
    • On a particular record or form go to Options -> In the Page Options section -> Select Security Diagnostics
    • A Security Diagnostics window will open and show the roles, duties, and privileges that have access to this page/form
  • Record a task/process
    • To start recording a process go to gear in the menu bar and click on Task Recorder
    • Give the recording a name and description
    • Navigate the steps required to complete the task, each step will be recorded in the right hand pane
    • When you are done, click the Stop button in the top menu bar and you will be presented with options to save the task steps in a number of ways

To help with the process of figuring out which menu items are used during the task, I have created a tool to help parse out a Developer’s Recording, it is available on my GitHub and a screenshot is below.

UPDATE:

Dynamics 365 Enterprise has now added an easy way to parse the task recordings to get the menu item data from it. In the system administration module, under the Security heading you will find an entry for ‘Security diagnostics for task recordings’.

If you click on that you will be presented with a couple options, with the Open from this PC option you can upload previously downloaded task recording XML files, you can also open any saved task recording from LCS.

Once the file is processed, you will be presented with a screen with very similar output from the utility I wrote. It will show you the label name, AOT name, and type of each menu item found in the task recording. One really cool feature, is that you can select a user from the User ID drop down and the system will tell you whether that user currently has the necessary permissions. In the example below, you can see that this user is missing the necessary permissions to perform this process.

Resources:

YouTube Tutorial on Simulating the Security Development Tool in Dynamics 365 for Operations (5:35)

Security Development Tool user interface (AX 2012)

Task Recorder in Microsoft Dynamics 365 Enterprise

 

What’s New in Dynamics 365 Enterprise Permissions?

There are a lot of questions about the new Dynamics 365 Enterprise and how it differs from previous versions of AX. If we look specifically at user permissions we can see a couple of things that have changed.

In AX the access level is hierarchy based with one access level being assigned to each object:

No Access -> Read -> Update -> Create -> Correct -> Delete (Full Control)

An excerpt from an MSDN on the topic has the following:

Read is the weakest permission, and Delete is the strongest. Delete permission includes every other permission. Create permission includes Update and Read. You can set the permission value to NoAccess to prevent all access to the entry point.

The Correct permission applies only when a time state table is involved. This permission authorizes you to issue update records in a time state table.

Below you can see that you are only able to assign one Access Level per object.

ax_maintainvendors

In Dynamics 365 Enterprise the permissions still follow this hierarchy of permission strength but allow for a piecemeal assignment. This means you can individually select Read, Update, Create, or Delete for each object you are securing. There are also different access types for each access level: Unset, Grant, and Deny. Grant means that the user has the ability to this access level for this object, and Deny means that the user is explicitly being denied this access, and Unset means you are not granting nor denying access to the object so if another role, duty, or privilege grants access to the object then the user will have access.

One thing to keep in mind, is that the Deny access type overrides any Grants assigned to the user for this object from any role, duty, or privilege.

d365_maintainvendors

Dynamics 365 Enterprise also has a new data type called a Data Entity. A data entity is basically a SQL view that will take a normalized database object that could exist across multiple SQL tables and creates one object that an end user can interact with. It is a very powerful feature that can be used by developers and 3rd party applications to interface with Dynamics 365 Enterprise.

Permissions for a data entity include one more property called Integration Mode. This setting will dictate if this element is accessible from OData and/or an import/export or connector integration.

d365_integration

Entry point Description
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.

These changes in the security model will need to be kept in mind when designing and applying security to an end user.