Microsoft Dynamics AX requires Active Directory to support its user structure. The Active Directory should be configured correctly to make sure it complies with your company's security policies regarding user access. The computers that are running Microsoft Dynamics AX must have access to computers in the same domain running Active Directory configured in native mode. It may be the case that not all network users need access to Microsoft Dynamics AX. Therefore, it is more secure to simply not grant them access in Active Directory. For more information about how Microsoft Dynamics AX integrates with Active Directory for security, see Working with users from Active Directory. For the latest recommendations for configuring Active Directory, see the Microsoft Windows Server 2003 Active Directory Technology Center.

For deployments that include the Enterprise Portal component, there are additional environmental security issues to address. The network should have a firewall. It should also have one or two domain controllers. When there are two domain controllers, one should be in the internal network and the other in the perimeter network.

This configuration is performed with Active Directory. For more information about how to set up security for Enterprise Portal, see Configuring Enterprise Portal securityin the Enterprise Portal Administration Guide.

When the Application Object Server (AOS) is installed, the user for the AOS service is set to either the Network Service account or a domain account. If you decide to use a domain account for the AOS service, you should make sure that the new account has the lowest (most restrictive) possible privileges, to help reduce the risk of processes that could cause harm to the server. For more information, see Install an Application Object Server (AOS) instanceand Security requirements for Microsoft Dynamics AX serversin the Microsoft Dynamics AX Installation Guide.

Database logs can contain sensitive data. By default, any database log that is created can be queried by any user who has access to the database. Users can query the log by using Business Connector, X++, alerts, or by using direct access to the database. To protect data, restrict the permissions on the sysdatabaselogtable. For detailed information, see Table Properties in the Microsoft Dynamics AX SDK.

Use the following security best practices to prevent users from submitting to batch groups that are processed with a higher permission level:

• Limit the number of user groups that have access to the Basic> Periodic> Batch journal executionmenu item and the Basic> Periodic> Processingmenu item. For more information, see Manage security permissions for user groups and domain combinations.

• Apply record level security restrictions on the BatchGrouptable. For more information, see Manage record level security.

To help prevent denial of service attacks on your Enterprise Portal, you can adjust the values of the following configuration commands in the configuration file of the Application Object Server (AOS):

• MaxConcurrentGuestSessions– This value controls the maximum number of concurrent Guest (anonymous user) sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.

• MaxConcurrentWebSessions– This value controls the maximum number of concurrent Enterprise Portal sessions that includes Guest sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.

• MaxMemLoad– This value controls the maximum amount of memory usage (the maximum percentage of physical memory that is used on the computer). The default value is 100. By decreasing this value, you can reduce the number of sessions that an attacker can start. After you set this value, you must restart the AOS for the change to be applied.

For detailed information about how to use MaxConcurrentGuestSessions, MaxConcurrentWebSessions, MaxMemLoadand other configuration commands, see Using the command line to manage the AOS.

The following are best practices for administering security of your Microsoft Dynamics AX environment:

• All Microsoft Dynamics AX user accounts should reside in restricted, well-defined user groups. There is no need for Microsoft Dynamics AX users to have administrative privileges over the domain. Also, following the principle of least privilege, anyone using the Microsoft Dynamics AX system should have minimal rights. This starts at the domain level. A domain user account should be created and used to run Microsoft Dynamics AX.

• 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 Administratorsgroup, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of the Administratorsgroup, 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 are configuring and administering Microsoft Dynamics AX should be members of the Administratorsgroup. Access in the Administratorsgroup cannot be altered.

• Work with managers who oversee the different groups in the business or organization to determine permission levels. For example, work with a manager in the Finance department to determine permission levels for the Finance group or groups. The manager knows which groups should have permissions to items like General ledgerand Bank, including permissions on child nodes.

• Passwords should never be used across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. If this happens, a compromise of a single account or computer could lead to a compromise of the whole domain. Passwords should never be reused in this manner.

• Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible. Domain Administrator accounts are typically used as service accounts for common services such as backup systems. However, it is a security risk to use Domain Administrator accounts as service accounts, because the password must be stored, or cached, locally on every computer where the service resides. The password can easily be retrieved by anyone with administrative rights over the computer. If this happens, the compromise of a single computer could lead to a compromise of the whole domain. Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible.

• If you change permissions for a user group, especially if you demote permissions, restart the server after you make the change. If you do not restart the server, members of the group might keep their former permissions until the next time that the server is restarted.

• 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 server restart. If it is necessary, before changing user group permissions, select users in User group permissions ( Administration> Common Forms> Online users) and then click End sessions.

  For more information, see Remove users.