Microsoft Dynamics AX security architecture consists of infrastructure and application security capabilities. Security measures consist of the following:

  • Authentication – Infrastructure security such as Active Directory directory services.

  • Access – Broad organizational constraints, which are applied in Microsoft Dynamics AX by managing domains and user groups.

  • Authorization – Specific business-level constraints, which are applied in Microsoft Dynamics AX by managing table and field access and by applying record level security.

  • Audit – Security reporting (including reports of user permissions, user group permissions, record level security, user log, user last logon, and user online time).

Infrastructure security

Microsoft Dynamics AX infrastructure security is built on the following:

  • Microsoft Dynamics AX user accounts. Users must first be in Active Directory directory services. Microsoft Dynamics AX relies on users who are already in Active Directory.

    Active Directory directory services are configured in native mode. For detailed information about Active Directory user topology, see Working with users from Active Directory. For information about how to configure Active Directory, see the Microsoft Windows Server 2003 Active Directory Technology Center.

  • Integrated Windows authentication.

  • A perimeter network that has a firewall for Internet-facing Enterprise Portal.

  • Secured servers. Many of the servers that run Microsoft Dynamics AX components have specific security requirements. For detailed information, see Security requirements for Microsoft Dynamics AX serversin the Microsoft Dynamics AX Installation Guide.

    Follow recommended Microsoft practices for securing the servers you are running, and stay up-to-date on understanding and implementing recommendations that make sense for your environment. For the most recent guidance, see the Microsoft Technet Security Center.

Application security

The application security architecture of Microsoft Dynamics AX includes the following features:

  • Domains that are groups of company accounts.

    Domains make it easier to maintain user group security if several companies use the same Microsoft Dynamics AX system, and have unique security needs. Domains enable you to restrict permissions to user groups to a single company, or to set up user groups that have permissions to data across companies. The domains feature requires a separate license. For more information about domains, see Manage domains.

  • Microsoft Dynamics AX user groups that are granted permissions.

    By adding a user to a group, you grant that user all the permissions assigned to that group. Users who are not assigned to groups cannot access Microsoft Dynamics AX. A user can be a part of more than one group; that user inherits the highest permissions level of the two groups. For more information about how to set up user groups, see Manage user groups.

    Important Important

    An Administrator user (Admin) and an Administrators group are created the first time that a Microsoft Dynamics AX client is run. The user who opens the first client to connect to an Application Object Server (AOS) instance after installation is set to the Admin user. The Admin user is added to the Administrator group. Members of the Administrator group have complete access to everything in Microsoft Dynamics AX, and to the Application Object Tree (AOT) when the MorphX Developer license is purchased. Restrict the number of users in the Administrators group. We recommend that as a security best practice, you create a Developers group (see Manage user groups) to help minimize the number of users in the Administrators group. By default, only members of the Administrators group can make changes in Application Object Tree (AOT) the central repository for classes, tables, and other development elements in Microsoft Dynamics AX. Give the Developers group access permission to make changes in AOT. Restrict the number of users in the Developers group.

  • Active Directory users who have been added to Microsoft Dynamics AX.

    Users who are not in Active Directory cannot be added. Users cannot be granted permissions directly. For more information about this, see Working with users from Active Directoryand Import users from Active Directory.

  • Security keys that control access to menu items, forms, reports, tables, and fields within a form.

    Security keys are disabled by default, and can be set for user group/domain combinations. Only administrator users have all security keys enabled by default. For more information about security keys, see Manage security permissions for user groups and domain combinations.

  • Table and field security that let you restrict access to tables and fields.

    For information about table and field security, see Manage table and field access.

  • Record level security that lets you set permissions on rows in tables, to restrict access to those particular areas of a table.

    No record level security is set by default. For more information about record level security, see Manage record level security.

Microsoft Dynamics AX security hierarchy

Microsoft Dynamics AX lets you add and remove functionality by adjusting the licensing, configuration, and security subsystems.

  • Licensing– The licensing system allows a customer to unlock purchased sets of functionality for use throughout an installation.

  • Configuration Keys– The configuration key system lets an administrator set the availability of functionality for the whole system. These configurations are subsets of module functionality that are currently not necessary to have enabled within the system. From a security perspective, enabling only the necessary functionality reduces the surface that is open to attack.

  • Security system– The security system lets an administrator control access of users to system elements (such as forms, menu items, and tables). These settings are set by managing user group and domain combinations.

The following figure shows the security hierarchy in a Microsoft Dynamics AX system.

Security configuration hierarchy

See Also