Leader Board

Manage table and field access

Whereas security keys control access to functionality within the application, this security access is limited to menu items. To help protect the system at a more granular level, it is important to set up security for table and field access.
All tables and fields are available in the security system, and access can be set up individually for each user group working within a company or domain without affecting other user groups. Table and field access is configured when you set security keys ( >  >  >  on the  tab).
The following graphic shows how to access and configure table and field access from the  window.
Table and Field Access
User group access to a table is defined by several factors:
  • The table rights defined for the user group within the domain or company.
  • The table's security key and the user group's security key rights within the domain or company with regard to the table.
  • The setting of the MaxAccessMode table property.
NoteNote
The MaxAccessMode property affects only access through the user interface. Code can still access the table, even if the MaxAccessMode is set to No access.
These factors are used for the calculation of a user group's permissions to each table in the application.
The following chart shows how table rights are calculated during startup. Tables have two properties: Configuration key and Security key.
Table access flow
Like user group table access, user group access to a field is defined by several factors:
  • The field rights defined for the user group within the domain.
  • The field's security key and the user group's security key rights within the domain for the field.
  • The setting of the Visible field property.
  • The setting of the AllowEdit field property.
These factors are used for the calculation of a user group's permissions to each field in the application. The calculation is performed during startup.
The following chart shows how field rights are calculated during startup.
Field access flow
After the user group's access to a field has been calculated, this access is compared to the one defined for the table. A user group's access to a field can never exceed the group's access to the table that the field belongs to. The final field access becomes the lesser of the field and table rights.
No comments:

Security considerations and best practices

The first step toward helping to secure Microsoft Dynamics AX is to make sure that it is deployed in a secure environment. For a network connected to any other network, including the Internet, extranets, and other internal networks, this means making sure that sufficient measures are taken to keep the network secure from external threats.
Additionally, whenever you make a change to the system, part of your planning should include attention to helping make the new system secure. For more information, see the Microsoft Dynamics AX Installation Guide.
For the latest information about security, see the TechNet Security Center. It provides security tools, security response information, such as security bulletins and virus alerts, and the most prescriptive security guidance Microsoft has to offer to help IT Professionals in securing their systems.
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 security in 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 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 sysdatabaselog table. 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:
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, MaxMemLoad and 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. A domain user account should be created and used to run Microsoft Dynamics AX.
  • We recommend restricting user group access to the Admin domain. To do this, in the  form, select a non-administrator user group and select the Admin domain. On the tab, click . Repeat this procedure for each non-administrator user group. Create separate domains containing just the companies that users should have access to.
    To prevent user groups from accessing information in domains that they do not belong to, set the permission level on the Open domain access security key to .
  • Following the principle of least privilege, anyone using the Microsoft Dynamics AX system should have minimal rights. If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to . 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 Administrators group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of theAdministrators 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 are configuring and administering Microsoft Dynamics AX should be members of the Administrators group. Access in the Administrators group 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 ledger and 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  ( > Common Forms > ) and then click .
    For more information, see Remove users.
No comments:
Subscribe to: Posts (Atom)