Microsoft Dynamics AX infrastructure security consists of the following:

• Active Directory configured in native mode.For detailed information about Active Directory user topology, see Active Directory user topology. For information about how to configure Active Directory, see the Microsoft Windows Server 2003 Active Directory Technology Center.

• Active Directory domain user accounts.To log on to Microsoft Dynamics AX, users must first exist as domain accounts in Active Directory.

• Integrated Windows authentication.Microsoft Dynamics AX uses integrated Windows authentication. Authorization is managed by the Microsoft Dynamics AX application.

• Perimeter network.The Internet-facing Enterprise Portal requires a perimeter network that has a firewall. For more information on perimeter network, see Enterprise Portal Administration Guide.

• Secured servers.Many of the servers that run Microsoft Dynamics AX components have specific security requirements. For detailed information about setting up servers, see the Installation Guide. Stay up-to-date with the latest security guidance by visiting the Microsoft TechNet Security Center.

The application security architecture includes the following features:

• Domains.A domain in the Microsoft Dynamics AX system is a group of company accounts. Domains enable setting up specific user permission for a group of company accounts.

• User groups.In the Microsoft Dynamics AX application, you can only assign permissions to groups and not to individual users.

  Important

  An Administrator user (user ID "Admin)" and an Administrators group (group ID "Admin") are created the first time that a Microsoft Dynamics AX Windows 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 Administrators group. Members of the Administrators group have complete access to everything in Microsoft Dynamics AX. Restrict the number of users in the Administrators group. We recommend that as a security best practice, you create a Developers group to help minimize the number of users in the Administrators group. By default, only members of the Administrators group can make changes to the AOT, which is the central repository for classes, tables, and other development elements. Give the Developers group access permission to make changes in the AOT. Restrict the number of users in the Developers group.

• Users.Microsoft Dynamics AX users are Active Directory users who have been added to the Microsoft Dynamics AXuser list.

  You can use the Active Directory Import wizard to add users from Active Directory to the Microsoft Dynamics AX application. The import wizard ( Administration > Common Forms > Users > Importbutton) provides a flexible way to search for users or groups.

• Security keys.Security keys allow administrators to set security on a user-group level and provide an efficient way to control access to functionality and data of the Microsoft Dynamics AX application. Security keys control access to menus, tables and views. Access to forms and reports is controlled by menu items. This way, the application can allow different types of access to the same form depending on where you access the form from. For example, Batch jobmenu item ( Basic > Inquiries > Batch job) and the Batch job list—Usermenu item ( Basic > Common Forms > Batch job list—User) both refer to the same form but the Batch jobform shows data for all users and so is restricted to the Administrator and batch operator roles. Security keys are disabled by default, and can be set for combinations of user group and domain. Only users in the Administrators group have all security keys enabled by default.

Note
You cannot change or disable the default Administrator access.

• Tables and fields.Table and field security lets you restrict access to tables and fields.

• Records.Record-level security lets you set access permissions on individual table rows. No record-level security is set by default.

• Table permission framework.The table permission framework (TPF) governs access to system tables. The table permission framework has been implemented in the kernel to protect specified system tables. Developers can use the AOSAuthorisation property to query Microsoft Dynamics AX and determine if a specific system table is identified as a protected table within TPC. Features that use the system tables should first perform an explicit or implicit authorization check to provide a better user experience.

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

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

• Configuration keys– The configuration key system lets an administrator enable or disable subsets of functionality within a specific module or feature of the Microsoft Dynamics AX application. From a security perspective, enabling only the necessary functionality reduces the surface that is open to attack.

Note
The changes made to the Microsoft Dynamics AX application with the configuration keys apply to the entire installation.

• Security system– The security system lets an administrator control user access to system elements such as fields, 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.