Special Permission Settings in Dynamics AX 2009
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.
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).
