We often get several questions about setting up security in AX and what the overiding security rights when using several groups with dfferent security configurations. There are 3 important ways to set up Security in Dynamics AX as follows:
• By using several user groups and use intersection to give rights
• By using the permissions to give rights
• By using table properties to change rights
Our design sequence is ascending (goes from top to bottom).
First you give the parent node the highest access you need below. Then you give the child nodes the rights that are needed. If this differs from what is inheriting from the access to the child node, then it’s considered as a Specific Right and hence overrules everything else.
To avoid creating a Specific Right access, you can change the Table property MaxAccessMode to what you need, and that way avoid a specific right. This property decides what should be inherited from the parent key.
We often experience that the parent key has No Access and then tables below get Specific rights. This is an incorrect use of specifying access rights (A similar example would be the same as you are not allowed to board a flight, but have booked flight seats afterwards).
Furthermore it is important to look at security settings at both parent and child nodes.
In this example Project is the parent key (Proj), Tables (ProjTables) is both Parent Key for the tables below and child for Project.
If you assign permission to a parent-node key (for example, if you select Project/Tables and then select Full control ) all child nodes inherit the same permission (=Table property MaxaccessMode). If you do not want all child nodes to inherit the same permission, you can change permissions on individual child nodes.
What is a Specific Right?:
A specific right is when you change child permission so it differs from the parent node or the table property “MaxaccessMode”. Remember it will overrule all other access rights.
For more information on setting up security in AX, see document links “Manage table and field access” at http://technet.microsoft.com/en-us/library/aa834466.aspx (or http://msdn.microsoft.com/en-US/library/aa846430(v=AX.50).aspx), and this is the area we get most questions combined with the setup described “Create user groups” at http://technet.microsoft.com/en-us/library/aa548611.aspx. You have to combine the both the articles to get a complete picture. I have tried to summarise the complete picture below:
First an overview. I have taken the overview from http://technet.microsoft.com/en-us/library/aa834466.aspx and added the several user group situation to the overview
So as you can see from the picture you only get the highest access on several user groups if you don’t have any specific rights.
The highest access can be pictured like this:
The intersection from this will be “Edit” as long as there are no specific rights to one of the groups. If there is a specific right like “No Access” for one table in the view group and the edit group still have “Edit” right on the same table, the final access will be No Access.
So if you still have set up your security to use several user groups and need a specific right for one table you will need to change the user group structure, so you can avoid the specific right in the intersection and/or alternatively you can change the table property MaxAccessMode to the same access level as the parent node and that way you get 2 specific rights in the same intersection, and then the highest level will rule again (this needs to be fully tested in a non-production environment before applying in production).
Other relevant security related articles:
- Differences in the RLS design of Dynammics AX 4.0 SP2 and Dynamics AX 2009
- Certain User groups cannot be deleted in Dynamics AX
- User ‘UserName’ is not authorized to insert a record in table ‘TableName’. Request denied
- AX2009 SecurityProfiler Tool – The tool tracks what security keys are being used when a user navigates through the application.
|–authors:||Mansour Yahya Mohamad and Anders Madsen|