Manage security permissions for user groups and domain combinations

Security keys are the permissions that control access to functionality within the application, and are set to individual user groups and users.

Permissions determine who can access menus, forms, reports, and tables. In Microsoft Dynamics AX, you assign permissions to user groups instead of individual users. Assigning permissions to groups saves time because you do not have to adjust permissions for each user.

When you create a new user group in Microsoft Dynamics AX, by default the group is set to No access for all menus, forms, reports, and tables. This means that after you create a new group, you must use the procedure in this topic to enable permissions. Otherwise, all members of the group are denied access to all menus, forms, reports, and tables.

Note

If you have set up domains within Microsoft Dynamics AX, security is applied to the individual domains. Otherwise, security is set up for all companies.


Set up security keys

Security keys are set up from Administration > Setup > Security > User group permissions on the Permissions tab.

Within a security profile, you can assign permissions that define access to menu items, form controls, tables, and fields.

Permissions are granted in five available access levels:

  • No access – Completely restricts access to that item and any sub-items it controls. The Open command is disabled. Also, the node is not displayed in the Application Object Tree (AOT).

  • View access – Members of the user group are allowed only to view the item. The Save, Compile, Lock and Unlock commands are disabled.

  • Edit access – Members of the user group can view and edit the item. The New, Duplicate and Rename commands are disabled.

  • Create access – Members of the user group can view, edit, and create new items. The Delete command is disabled.

  • Full control – Members of the user group have full access. No commands are disabled.

Security access for each user must be determined before first logon. Access depends on which user groups the user is a member of, and which company or domain the user is a member of. Access to functionality of each security key can depend on its parent, so the calculation must be done hierarchically.

Note

•Higher-level permissions inherit lower-level permissions. For example, a group that has Create permissions for a menu item also has Edit and View permissions.

•If you grant developer permissions to a user group, the group must have developer permissions across all domains.

•A user group can have different permissions within different domains. For more information about domains, see Manage domains.

•If you assign permission to a parent-node key, for example, you select Absence approver and then select Full control, all child nodes inherit the same permission. If you do not want all child nodes to inherit the same permission, you can change permissions on individual child nodes.


To configure security keys, the administrator first selects a user group and a corresponding domain (you can select all domains at one time). The security tree is then built, and the administrator can view the tree and make the necessary changes.

Note

When a security key property is changed for any AOT object, the client must be restarted for the changes to become visible.


Permission levels

Higher-level permissions inherit lower-level permissions. For example, a group that has Create permissions for an item like a form also has Edit and View permissions also. The following table shows the inherited permissions.

When a user is in multiple user groups, the higher level becomes the effective permission. For example, if the user has Create permissions in one user group and Edit permissions in the other user group, then the effective is permission level is Create.

Explicit No access overrides all other permissions.

-

View

Edit

Create

Full control

No access

View

x

x

x

X

-

Edit

-

x

x

X

-

Create

-

-

x

X

-

Full control

-

-

-

X

-

Security key logic and organization

Security keys are used to grant user group access in Microsoft Dynamics AX. Security keys have two main properties:

  • Configuration Keys – The Configuration Key system lets an administrator set the availability of functionality for the whole system.

  • Parent (only one parent security key can be specified) – Parent/child relationships control whether a key can be disabled. If you assign permission to a parent-node key (for example, if you select Absence approver and then select Full control) all child nodes inherit the same permission. If you do not want all child nodes to inherit the same permission, you can change permissions on individual child nodes.

The following graphic shows the path that is taken to validate security access. Here, the graphic shows that the system validates whether the configuration key is enabled. If the configuration key is enabled, then it determines whether specific rights have been set to the security key. Then, if the security key is a child, it acquires the same security rights as the parent.

Security key flow

Each parent security key represents a broad umbrella of functionality within Microsoft Dynamics AX, and the underlying child security keys are divided into nine categories:

  • Daily — Contains the most accessed forms in the menu.

  • Journals — Corresponds with the Journals folder in the menu.

  • Inquiries — Corresponds with the Inquiries folder in the menu.

  • Reports — Corresponds with the Reports folder in the menu.

  • Periodic — Corresponds with the Periodic folder in the menu.

  • Setup — Corresponds with the Setup folder in the menu.

  • Miscellaneous — Controls access to all menu items used in the module that are not accessed from the menu. This is typically menu items accessed through buttons on forms.

  • Tables — Lists all the tables that are used in that module.

  • Services — Governs access to services. Users must be granted Full access in order to consume any of the service operations from an external client.

For each module, a set of ten security keys exists. They all have the same naming, and the prefixes indicate the module. For the Accounts Receivable module, the security keys are as follows:

  • Cust

  • CustDaily

  • CustSetup

  • CustJournals

  • CustInquiries

  • CustReports

  • CustPeriodic

  • CustMisc

  • CustTables

  • CustServices

Each menu item is present underneath one (and only one) security key. The access to the menu item ranges from No access to Full control.

Menu item access flow

Set access permissions for user groups

  1. From a Microsoft Dynamics AX client, click Administration > Setup > Security > User group permissions.

  2. On the Overview tab, select a user group and then select a domain.

  3. Click the Permissions tab.

  4. In the list, select the item or items for which you want to set permissions, for example Absence approver.

    Note

    To select multiple items, press and hold the CTRL key.


  5. Under Access, select a permissions level. After you have selected a permissions level, the selected item shows a check mark to indicate that permissions have been set.

  6. In the Viewing list, select a new area of Microsoft Dynamics AX for which you have to set permissions.

  7. Press CTRL+S to save changes.

  8. If you changed the permissions of an existing group, especially if you set more restrictive permissions on that group,restart the Microsoft Dynamics AX server. Instruct all group members to restart their Microsoft Dynamics AX clients. .

Note

When a security key property is changed for any AOT object, the client must be restarted for the changes to become visible.


Note

If you have to set permissions for a group in a different domain, repeat this procedure and select the new domain in step 2.


Set access permissions for developers

Restrict user group access permissions to Application Object Tree (AOT), the central repository for classes, tables, and other development elements in Microsoft Dynamics AX. By default, only members of the Administrators user group have access to AOT. As a security best practice, create a Developers group (see Manage user groups) and give this group access permission to make changes in AOT. The Developers group could have Edit permission if you follow a strict security policy of least privilege. However, if developers need to create or delete AOT elements, the group requires Create or Full control permission.

Ideally, you should not give any other group access permission to AOT, especially access permission where members of that group can make changes in AOT. If it is required, you can grant View permission so individuals can view elements in AOT.

Adjust global types

Developers may require access permission for an additional menu item: adjust global types (Administration > Setup > User groups > Permissions > Administration key > Setup subkey > Modify data types menu item). Administrators typically adjust global types only during installation. If it is possible, avoid adjusting global types after the initial installation because these changes affect the whole Microsoft Dynamics AX application. If a developer has to adjust global types for the whole application, that person must be granted Full control permission for this menu item.

Permissions reports

Microsoft Dynamics AX includes user and user group permission reports (also referred to as security reports). These reports list the permissions for a selected user or user group. Use these reports to help you create a consistent security policy when you are creating new users or user groups, or when you are setting up a domain.

To view user permission reports

  1. From a Microsoft Dynamics AX client, click Administration > Reports > Security > User permissions.

  2. Enter the parameters.

  3. Click OK.

To view user group permission reports

  1. From a Microsoft Dynamics AX client, click Administration > Reports > Security > User group permissions.

  2. Enter the parameters.

  3. Click OK.

Best practices

  • If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to No access. It is better to deny permission to an item and force an individual to request permission for their group than to grant permission to an area that a group should be unable to access.

  • Restrict the number of users who are members of the Administrators user group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of the Administrators user group, they can potentially view reports or data that they should not be able to see, or change configurations and business logic in the system. Ideally, only those individuals who configure and administer Microsoft Dynamics AX should be members of the Administrators user group.

Important

If you change permissions for a user group, especially if you demote permissions, restart the Microsoft Dynamics AX server and instruct all group members to restart their Microsoft Dynamics AX clients after you make the change. If group members do not restart their clients, they might keep their former permissions. As a best practice, ask members of a group to log off Microsoft Dynamics AX before changing permissions and inform all Microsoft Dynamics AX users of the impending client restart. If it is necessary, select users in the Online users form (Administration > Online users) and then click End sessions before changing user group permissions. For more information, see Remove users.


See Also

Manage user groups

Manage users

Manage domains

Set up Microsoft Dynamics AX security