Microsoft Dynamics AX includes several features to help manage access to modules, forms, data, and reports. These features include domains, user groups, and record-level security.

To add an additional layer of security to your computing environment, the Microsoft Dynamics AX application requires that all users be listed in Microsoft Active Directory directory services on your domain controller before they can be enabled on the Microsoft Dynamics AX Usersform. If a user is not enabled on this form, no access to Microsoft Dynamics AX is granted.

By default, individual users cannot access Microsoft Dynamics AX resources such as forms, data, and reports. You must assign users to one or more group and then assign appropriate permissions to these groups. You can further refine access by grouping multiple companies into domains and by using record-level security.

Recommendations for managing security access include:

• As part of your business processes, document and communicate appropriate policies and procedures for infrastructure security and the Microsoft Dynamics AX application security within the information technology department and user departments of your organization as appropriate.

• Ensure that you provide only the necessary permissions for users to do their jobs effectively and nothing more. For example, restrict access to forms that may contain personal information to only those groups of employees that require this access for business reasons.

• Consider encryption of client/server communication and database storage of sensitive information. For details on encryption considerations, see Encryption considerations.

• Restrict access to reports that may list personal information to only those groups of employees that require this access for business reasons.

• Restrict direct access to the Microsoft Dynamics AX database to application administrators only. See your database documentation on controlling access.

• Do not install the Business Connector on a Microsoft Dynamics AX Windows client computer unless it is required for third-party integration.

For more information about how Microsoft Dynamics AX is structured for security, see Overview of the security architecture. For details on setting up application security, see the Server and Database Administration Guide.

If external user access to Enterprise Portal is required, domain accounts must be set up for the external users. For details about setting up Web users, see the Server and Database Administration Guide. The location of the external user domain accounts depends on the structure of your perimeter network. For more information about perimeter network, see Active Directory user topology.

By following a few simple rules in administration, you can increase the security of your Microsoft Dynamics AX environment.

• There is no need for Microsoft Dynamics AX users to have administrative privileges over the domain, so all Microsoft Dynamics AX user accounts should reside in restricted, well-defined user groups. 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 permission level set to No access. It is better to deny permission to an item and force an individual to request permission for a group than to grant permission to an area that a group should not be able 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 they should not be allowed 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 your 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 might create Domain Administrator accounts in each domain that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. Under these conditions, a compromise affecting a single account or computer could lead to a compromise of the entire domain. Passwords should never be reused in this way.

• Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible. Domain administrator accounts are commonly 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 entire 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, ask the users in the group to log off and then log on. If users do not log off and log on, they might retain their former permissions until the client application is restarted. As a best practice, ask members of a group to log off Microsoft Dynamics AX before changing permissions. If necessary, before changing user group permissions, you can check the User group permissions( Administration> Common Forms > Online users) to see online users.

For more information on session management, see Server and Database Administration Guide.

As you implement a Microsoft Dynamics AX system, work with your implementation team to help ensure that any personal information stored in your system is secured in accordance with the laws and regulations of the countries you operate in.

Personal information includes any information relating to an identified or identifiable individual. Such information may include name, country/region, street address, e-mail address, credit card number, Social Security number, government identification number, IP address, or any unique identifier that is associated with personal information in another system.

If you choose to send error reports to Microsoft, personal information could be unintentionally collected by Microsoft Dynamics AX. If it is present, it will not be used to identify you or anyone in your corporation. You can review the data collection policy for the Microsoft Error Reporting engine on the Microsoft Online Crash Analysissite.

You may choose to collect personal information using Microsoft Dynamics AX from customers, employees, or vendors as part of your business processes. It can be collected directly from customers registering through Enterprise Portal, or it can be collected by an employee on behalf of a customer or another employee.

Personal information may be stored in the Microsoft Dynamics AX database. The following list includes some (but not necessarily all) tables that may contain personal information:

• Any table that begins with BANK

• Any table that begins with COMMISSION

• COMPANYINFO

• CONTACT

• CUSTTABLE

• EMPLTABLE, and any other table that starts with EMPL

• ECPCUSTSIGNUP

• Any table that begins with HRM

• SYSCOMPANYUSERINFO

• USERINFO

• VENDTABLE