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

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 Opencommand is disabled. Also, the node is not displayed in the Application Object Tree (AOT).

• Viewaccess – Members of the user group are allowed only to view the item. The Save, Compile, Lockand Unlockcommands are disabled.

• Editaccess – Members of the user group can view and edit the item. The New, Duplicateand Renamecommands are disabled.

• Createaccess – Members of the user group can view, edit, and create new items. The Deletecommand 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 Createpermissions for a menu item also has Editand Viewpermissions. •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 approverand 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.

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

Explicit No accessoverrides all other permissions.

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

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 accessto Full control.

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

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

3. Click the Permissionstab.

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 Viewinglist, select a new area of Microsoft Dynamics AX for whichyou have too 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.

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 Editpermission if you follow a strict security policy of least privilege. However, if developers need to create or delete AOT elements, the group requires Createor Full controlpermission.

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 Viewpermission so individuals can view elements in AOT.

Adjust global types

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

To view user group permission reports

• 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 Administratorsuser group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of the Administratorsuser 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 Administratorsuser 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 usersform ( Administration> Online users) and then click End sessionsbefore changing user group permissions. For more information, see Remove users.