Bojensen Blogs

Tips on AX 2012 Security Development Tool – Part 2

This entry is part 3 of 6 in the series AX 2012 Security

Andre from Kaya Consulting has written a series of excellent articles on AX 2012 Security Development: here is Part 2:

Within my previous post I started a series about the Security Development Tool for Microsoft Dynamics AX 2012. I got some positive feedback, so that motivated me to continue on part 2. I have seen people using the tool and thought they could they could easily create or modify roles themselves and at the end they got stuck… So this post is about helping you prevent creating spaghetti.

Tip: Don’t use it without proper knowledge

Probably I should have started in the previous post with this tip.

Like the Security roles form in AX 2012, the Security development tool is interacting with the security objects in the application object tree. The tool uses the same objects and logic as present in the Ax 2012 Security Framework. So before start using this tool, you need to obtain proper knowledge of the Ax 2012 security architecture.


Every Role consists of one or more Duties so a user will have access to the parts of the system needed to perform his tasks. Every Duty contains one or more Privileges which is a set of Securable objects like User interface elements. Mainly menu items are part of a privilege. Per menu item in a privilege it is determined what level of access is granted. E.g. View or Full control. In fact it is also possible to link Privileges directly in a role, but that is not the best practice. The privileges are not supported to be checked in the function Segregation of duties. Only duties are used for this feature.

If you have looked at the Security Development Tool you have noticed that it contains a tree overview of the Main menu with all menu items. When you select a Role in this tool, it will show you the effective access level. So this tool translates the Duties, Privileges and User interface elements in an understandable view.


You can now ask me: “André, it is a nice story. I understand this. I can change it here, so what is your point?”

Well it is easy to select a node (e.g. All vendors) and do a right mouse click, select Set entry points for current node and expanded sub tree items. You can then change the required Access level and apply on an existing privilege.


To do this I have noticed that people are choosing the first menu option to apply it using the first context menu option. The result looks OK. See the next picture:


So now my point: If you had paid attention, the tool mentioned 5 roles. It included the current and 4 other roles. So now you updated multiple roles!

Within the architecture of the Security in AX it is possible and common to reuse privileges and duties. This happened a lot in the standard Roles. So one privilege is used in multiple duties and one duty can be used in multiple roles. So read carefully all details on the Security. You can start reading an article on TechNet: Role-based security in Microsoft Dynamics AX [AX 2012].

Some people thought they figured out that it was possible to select one Role in this part and then it updated only that role. (which is not true!)


Then the person tested the role, selected the next role which should be changed, and so on. This person told me that 10 roles were effectively changed and tested. Then I pointed out that this was not true. I asked to open the first and second role and then proofed that changes were not as they had done. So in fact many permissions were granted, revoked, changed, granted again… and so on. Also as a result I have seen over 500 modified security objects in the AOT.

So now the best way to do this: If you need to modify an existing role take notice of the following best practices:

  • Create a new role: You can duplicate an existing role by using the AOT duplicate option. You can also create a new role from scratch and assign the same or some Duties as a start. This will prevent merge challenges when you want to upgrade to future versions.
  • If you need to change details, don’t use the option Apply entry point access levels to selection. Use a duplicate of the Duty or privilege. See another tip in this blog. This will also result in keeping the standard objects as is and might be better for future upgrades.
  • Try to use the standard duties and privileges: If there is no risk if someone can run an inquiry form or a report which is not needed, don’t change it. It will prevent lots of specific copied Duties and privileges.

Tip: Duplicate duties and privileges

When you want to apply changes which would result e.g. in a changed privilege, it is possible to use the option Duplicate selection and then remove original. Then in this case AX will duplicate the standard privilege and use the duplicate in the duty. When it is copied you can apply the changes on this copy only which leaves the standard object the same and other roles using the same security artifacts are not affected. This copied privilege can also be reused in several other duties or roles.


Note that if you don’t want to change the standard duty, it is also possible to duplicate the duty with a similar action. In this case first duplicate the Duty and then the Privilege.

Tips on AX 2012 Security Development Tool – Part 2 |

Series Navigation<< Tips on AX 2012 Security Development Tool – Part 1Tips on AX 2012 Security Development Tool – Part 3 >>

Comments are closed.