Export (0) Print
Expand All

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 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.

NoteNote

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.


Security keys are set up from > > > on the 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:

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

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

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

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

  • – 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.

NoteNote

•Higher-level permissions inherit lower-level permissions. For example, a group that has permissions for a menu item also has and 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 and then select , 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.

NoteNote

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


Higher-level permissions inherit lower-level permissions. For example, a group that has permissions for an item like a form also has and 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 permissions in one user group and permissions in the other user group, then the effective is permission level is .

Explicit overrides all other permissions.

-

x

x

x

X

-

-

x

x

X

-

-

-

x

X

-

-

-

-

X

-

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 and then select ) 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 to .

Menu item access flow

  1. From a Microsoft Dynamics AX client, click > > > .

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

  3. Click the tab.

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

    NoteNote

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


  5. Under , 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 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. .

NoteNote

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


NoteNote

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


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 permission if you follow a strict security policy of least privilege. However, if developers need to create or delete AOT elements, the group requires or 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 permission so individuals can view elements in AOT.

Adjust global types

Developers may require access permission for an additional menu item: adjust global types ( > > > > key > subkey > 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 permission for this menu item.

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 > > > .

  2. Enter the parameters.

  3. Click OK.

To view user group permission reports

  1. From a Microsoft Dynamics AX client, click > > > .

  2. Enter the parameters.

  3. Click OK.

  • If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to . 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.

ImportantImportant

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 form (> ) and then click before changing user group permissions. For more information, see Remove users.


Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft