Does anyone have experience with the Security Development Tool as far as being able to change access levels by role. I was playing around with it recently and made some changes to privileges which were shared by 3 roles. All of them were affected but I really was only intending to modify one of the roles. Haven't found much documentation on this topic, hoping someone could help. Much appreciated!
If you change a privilege it indeed will have impact on other duties/roles having this same privilege. In this case you can copy the privilege and change this one. Deactiviate the original and add the duplicated. Note that you have to change the name of the privilege then to have a unique name and lateron you know which privilege to use.
Because of the shared privilege the roles are presented at the right, so you know which roles will be affected. You can mark a role, but this has no use or meaning that you only change one role.
André Arnaud de Calavon | Microsoft Dynamics AX Solution architect | My blog | My company
This post is my own opinion and does not necessarily reflect the opinion or view of my company, Microsoft, both its employees, or other MVPs.
Security Development Tool provides option of Duplicate and add in the form for updating Access Levels. Just right click the concerned privilege.
Follow up questions.
I went through a "tutorial" on TechNet for the SDT, and it did make mention of multiple roles and having to duplicate duties so they do not impact other roles as I'm changing access levels on privileges. Beyond the tutorial I try changing privileges for a specific role which shares a duties with 2 other roles. Then I go down to the privilege level and realize it also is shared amongst multiple roles.
The question is, I assume I have to be very cognizant of not just what duties are shared but also the privileges as they potentially impact multiple roles? And in some cases I would have to duplicate not just the duty but potentially the privilege if I wish to control the impact to a single role?
Other question is, the security modifications can get pretty complex so are there recommended methodologies regarding how to properly document security?
Yes, you are correct. A privilege can be assigned to multiple duties, which in turn can be assigned to multiple Roles. Hence, whenever you modify a privilege, you need to check, which other Duties / Roles refer to this object.
What we do is, usually we go top-down i.e. for Role to Privilege. We identify the privilege that need to be modified and the duties through which the privilege is available in role. Then, we duplicate the duty and replace the standard Duty with our new copy. Next, we duplicated the privilege to be modified and replace the standard privilege with duplicate copy in the duties we just created. Lastly, modify the privileges.
This helps to make sure that you are not modifying any other Standard Duties and Roles.
I would like to learn if anyone is handling it in a better way. Also, would like to learn good documenting procedures for security.
Next to the approach of Michael we also create new customized roles (some from scratch, some copied from an Original). This is also to have the standard as much as untouched.
We created an Excel sheet with gave insight in Privileges per Duties and Duties+Privileges per role and marked/filled the changed roles, duties and privileges.
For customization of Roles within an implementation we also advise the DTAP strategy. Develop security, Test, let the customer Accept before putting it into Production.
For new functionality you have to start thinking of adding security elements as well.
I understand AX out of the box gives users quite a long leash as far as access. As an example, the Setup portion of the Page Area seems to allow a basic user the ability to modify quite a few things. I was curious whether most implementations out there have modify security to remove those gaps or have managed it through business processes and training? I would think the former but at the same time the security modification process seems really tedious and quite unwieldy.