Configuration and Security Keys Best Practice Checks

Configuration keys determine which features are turned on during the installation. Security keys determine which features that a user group has access to (from the installed set of features).

Security Keys

Microsoft Dynamics AX consists of a number of modules. For example, General Ledger, Project, and Administration. To make it easier for an administrator to set up security keys, they are organized the same way for all modules. Only nine security keys are allowed for each module in the Navigation Pane.

Enterprise Portal security keys relate to the different Enterprise Portal roles (Administrator, Sales, Vendor, and so on). Only five security keys are allowed for each role.

Using Security Keys

The security key specified for objects in the Navigation Pane must match the location of the object. Error icon For example, items that use the BasicReports security key must be located in Basic > Reports in the Navigation Pane.

If your code needs to check access permissions, match these locations as early as possible. Provide a clear error message to inform the user at the beginning of a process if they do not have permission to execute it.

Security Key Properties

Property

Rules

ID

Always ship a security key with the same ID as it has been shipped with before.

If you try to create a new security key with an ID that has already been used for a security key in Microsoft Dynamics AX, an error will occur. Error icon

Name

One of the nine security keys on a branch (the parent) should take the name of the module. For example, BOM. The other keys (up to eight more on a branch) should have the name of the module followed by one of the following suffixes: Daily, Journals, Inquiries, Reports, Periodic, Setup, Misc, or Tables. For example, BOMReports, BOMSetup, and LedgerPeriodic.

Enterprise Portal keys should have a prefix of EP followed by the name of the role. For example, EPAdmin and EPConsultant. Additional security keys for the role should take one of these suffixes: Misc, Info, Report, or Task. For example, EPAdminInfo and EPConsultantTask.

Application Integration Framework (AIF) keys should be the same as the name used for the service. The format is the module that the service is contained in, the document name, followed by Service. For example, in the Sales module, SalesSalesOrderService.

If you attempt to create a security key with a name that has already been used for a security key in Microsoft Dynamics AX, an error will occur. Error icon

Label

Mandatory property. Error icon

AnalysisVisibility

Mandatory property for top-level security keys (keys that have no parent key). Error icon

Set to High for any key that corresponds to a core module in Microsoft Dynamics AX, for example, Ledger.

Set to Low for keys associated with tables that will not usually be used for reporting.

Set to None for keys associated with system functionality that should not be shown for end-user reporting.

Configuration Keys

Configuration keys should be defined so that the installation can be set up with only the features needed for each particular installation. By disabling configuration keys, administrators can reduce the potential surface of attack, thereby helping to increase the security of their Microsoft Dynamics AX installation.

Configuration keys are often arranged in hierarchies of functionality, mirroring the hierarchies of functionality in the application.

Property

Rules

ID

Always ship a configuration key with the same ID as it has been shipped with before.

If you attempt to create a new configuration key with an ID that has already been used for a configuration key in Microsoft Dynamics AX, an error will occur. Error icon

Name

Follow the standard Naming Conventions.

If you attempt to create a configuration key with a name that has already been used for a configuration key in Microsoft Dynamics AX, an error will occur. Error icon

See Also

Security for Microsoft Dynamics AX

How to: Create and Apply Security Keys

How to: Create and Apply Configuration Keys