Some time ago I encountered an issue where users in AX 2012 were able to modify records even when the security role should have read rights only. More people have experienced this issue and others will do in future. This post will tell you about the cause and how to solve it in your environment.

What is the issue?

Suppose you have assigned some users to a role where they are able to view the main accounts and/or dimension values. You are probably proud because you have created the role yourself. Then a user notices that he is able to change the name of the main account or dimension values. This was not how this role was meant to be. To solve the problem you start evaluating the role. Stop searching in this role as it is probably not caused by this role, but the system user role.

Out of the box the System user role has access levels granted to tables to be able to handle some basic functionality like using Alerts. Also the role should ensure you have read access to many tables related to e.g. main accounts, financial dimensions and account structure setup to be able to use functionality which reads e.g. setup related to inventory posting. Some tables do have higher access levels which is really needed, but there are also some tables with e.g. create access level which will cause the issue as mentioned above.

When you open the Security roles form (System administration > Security), you can select the System user role and click the button Override permissions. You will notice there are many tables having view access rights, but also some with higher permissions.

SysUser01

There are some tables within this role which causes the user has edit rights in stead of view only:

  • DimensionAttributeValue
  • DimensionAttributeValueCostAccounting
  • DimensionAttributeValueFinancialStmt
  • DimensionFinancialTag
  • MainAccount

You can solve the issue by overriding the permissions. Select each table and clear the Do not override field. Then set the access level to View.

SysUser02

These changes will cause the access on forms are correct. I don’t know the reason of the higher access levels. Until now I have not seen any other feature impacted that was not working anymore. This is no guarantee that everything is still working as expected in each module for every single environment. So you can use this as guideline, but please test if all your process are working without other interruptions caused by this change.

There is more

Override of the permissions causes the security role to be changed in Dynamics AX.  If you are familiar with the Dynamics AX development environment you can go to the security role and also apply these changes via the AOT.

SysUser04

The privilege DimensionEssentials has the detailed table permissions which causes the access levels set too high.

SysUser03

That’s all for now. Till next time!

5 replies
  1. G. van Olst
    G. van Olst says:

    These tables are used for creating dimensions and apart from the custom financial dimension list (DimensionFinancialTag) I think this is correct for the system user role.
    For instance, if the project in the project module is configured as a financial dimensions.
    If the user is creating a project via the project manager role, it should also create a value in the financial dimension tables.

    Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Thanks for your comment. In fact you don’t have to worry about your concern. The (direct) full access rights on the Dimension framework tables are not required on the system user role to create e.g. projects where also the project is setup as financial dimension. Like mentioned in my blog I have not seen issues related to my recommendations. I have managed security on multiple environments where these tables were downgraded to read only and also where they use entity backed dimensions with no issues.

      Reply
      • Gerrit van Olst
        Gerrit van Olst says:

        André,
        Thanks for the heads up.
        Recently I decided to downgrade the table DimensionFinancialTag for a customer and it is still in a test phase.
        I don’t have experienced in downgrading the system user role in relation to the other mentioned tables. The “project example” was the only thing I could think of. Nice that downgrading does not have any effect on the functionality.

        Reply
    • André Arnaud de Calavon
      André Arnaud de Calavon says:

      Hi John,

      Performance depends on what exactly you are doing. In fact the tables for the system user role were already “overridden” by Microsoft. In my blog, I only described to change the access level.
      Can you possibly create a question on the Dynamics community forum for the last part of your question? Then also provide possible examples as benefits are depending on what you need to achieve.
      In general, the benefit would be easier upgrades when you didn’t override standard security objects.

      Reply

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.