One of the questions I get quite often is now that I know that security created/modified from the AOT is stored differently than security created/modified from the user interface, what is the best way to move security between environments effectively and ensure the validity of the tested security in each environment?
Treating Security as Code
What I mean by this is that your security should go through all of the same testing, deployment, and version control processes you have for code… because it is code. Just like you wouldn’t let a developer make code changes directly in production, you should not allow your security to be modified directly in production and instead should use the same promotion process you already have set up for your code. This concept is called Application Lifecycle Management, to learn more about this there is a great free course offered by Microsoft available here.
Joris de Gruyter has a great blog that consolidates all of the Microsoft posts surrounding this idea for various versions of Dynamics AX/365FO.
The basic idea is to use version control and code promotion to move security. So instead of doing something like this, where the user would go to each environment and make the security change:
You instead do something like this, where the user makes the changes in a development environment, that change then gets promoted to a test environment and finally it gets promoted once again to a production environment.
One thing to note here, this setup is a very basic setup and there can be multiple more layers between development and production.
Utilize Tools To Help Automate Process
Fastpath Security Designer Security Migration Tool – as part of the Fastpath Security Designer module, there is a Security Migration functionality to convert the SecurityDatabaseCustomization.xml output file a user gets from exporting security from the user interface in D365FO to the XML needed to either:
- Create security elements in code via the AOT
- Generate security XML to import via D365FO user interface into another D365FO environment
You have the ability to select which security layers you would like to export and to be able to rename the Name, Label, and Description properties of the security layers.
D365FO Security Converter – a free tool I developed to mimic the functionality of the Security Migration Tool as a standalone tool
Alex,
I make changes to the security only on the front end. I have always just made the change in each environment like you mention is not best practice.
what kind of file needs to be given to the technical lead to deploy instead of doing the direct changes?
Also, we are in the middle of implementing this for 11 different legal entities, all will be in the same instance, for me it has just been easier to make the changes like I have been since there are so many moving pieces. What might be the best way for me to transition from the process I have been doing to your suggested way of deploying the changes?
It takes so much time to move the code over, and involves more internal resources, that is the reason for doing it the way I do.
Sami,
The final part of this blog post goes into how to Export/Import security changes from a D365FO environment. Keep in mind that this process export all customizations, so if you only want to move over some changes but not all you would have to look at something like the Security Converter Tool which is available on my GitHub or as part of the Fastpath solution.
The reason I talk about ‘treating your security’ as code, is to put people in the mindset of bringing this into the application lifecycle management that Microsoft is promoting within D365FO with things like OneVersion etc. Any customization that goes into D365FO should be a part of your source control and should be getting checked in and moved between environments. This may be cumbersome or difficult at first, but once a process is put in place within an organization it should be able to be sped up and streamlined.
There are many reasons for doing this, some include:
– Making it easier to prove who made security changes and when
– Making it easier to show your auditors (internal/external) when security changes were made (or in most cases, proving that changes were not made)
– Making it easier to administer security (you only have to set up security once in a lower level environment, and it gets promoted to other environments as part of code promotion process)
– Removes risk from human intervention (intentionally or inadvertently) from changing/modifying security in between environments
– This also saves a lot of troubleshooting time if a user has access to perform a task in environment A but not in environment B for example
Hopefully this overview shows the importance of this process. The steps I laid out in this post are not something that can be implemented overnight and may take some effort, but in the end will hopefully make administering security easier and more efficient within your organization. If you would like to discuss further, I would be happy to set up a virtual meeting the best way to reach me is meyer@gofastpath.com
Hi Alex
I have a question for you: have you ever had a scenario where a privilege was created in the AOT (code) and then you delete the privilege on the front end by mistake. Now when you try to deploy the security changes to another environment using the front end export and import in D365, you get an error “Could not find object with identifier xxx” which points to the AOT name of the privilege? How do I get this privilege back on the front end? This is actually preventing further deployment of security permission changes.
Steven,
You have two options:
– In the new environment create a privilege in the AOT using that object identifier (when you deploy the new front end .XML it will be removed)
– In your current environment if it is non-prod, go into the database and remove the front end customization manually
– For a role, this data is stored in the SecurityRoleDisabledDisk table, delete the record that corresponds to the role you want to be reenabled
– You will have to do a database sync after you perform this and the role should come back into your environment