Scribd
Upload
8 views3 pages

configuration and security keys in ax

The document outlines the configuration and security keys in Microsoft Dynamics AX, detailing their importance in managing user access and protecting sensitive data. It describes the process for applying and creating security keys and configuration keys, including their properties and naming conventions. The document emphasizes minimizing the attack surface by setting appropriate security and configuration keys for various application components.

Uploaded by

Peter Janssen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
8 views3 pages

configuration and security keys in ax

The document outlines the configuration and security keys in Microsoft Dynamics AX, detailing their importance in managing user access and protecting sensitive data. It describes the process for applying and creating security keys and configuration keys, including their properties and naming conventions. The document emphasizes minimizing the attack surface by setting appropriate security and configuration keys for various application components.

Uploaded by

Peter Janssen
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Configuration and Security Keys in Axapta

Configuration and Security Keys in Axapta


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.
Security keys allow administrators to set security on a user group level. Minimizing access
on a user group level helps to reduce the attack surface against potential attacks.
Applying Security Keys

The main reasons to apply user-level security are to:

 Allow users to do only their designated tasks.


 Protect sensitive data in the database.
 Prevent users from inadvertently breaking an application by changing code or
objects on –which the application depends.

You need to apply a security key to:

 Tables
 Views
 Menus
 Menu items
 Form controls
 Report controls

To create security keys in Microsoft Dynamics AX:

1. Expand the Data Dictionary node in the Application Object Tree (AOT).
2. Right-click the Security Keys node, and then select New Security Key.
3. Right-click the security key object, and then click Properties.
4. Rename the security key by modifying the Name property.
5. Right-click the object, and then click Create from the shortcut menu.
6. Right-click the object, and then click Save from the shortcut menu.
7. Right-click the object again, and then click Check In. This opens the Check in form.

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.
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.

Label Mandatory property.


AnalysisVisibil Mandatory property for top-level security keys (keys that have no parent
ity key).
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 allow administrators to enable or disable features in the application
for all users. Disabling features helps to minimize the attack surface against potential
attacks.
Applying Configuration Keys

Configuration keys are applied to:

 Tables
 Fields
 Indexes
 Views
 Menus
 Menu items
 Form controls,
 Report controls
 Extended data types
 Enumerations

Configuration keys are applied by setting the ConfigurationKey property on these objects
in the Application Object Tree (AOT).
Creating Configuration Keys

To create a configuration key

1. Expand the Data Dictionary node in the AOT.


2. Right-click the Configuration Keys node, and then select New Configuration Key.
3. Right-click the configuration key object, and then click Properties.
4. Rename the configuration key by modifying the Name property.
5. Right-click the object, and then click Create on the shortcut menu.
6. Right-click the object, and then click Save on the shortcut menu.
7. Right-click the object again, and then click Check In. This opens the Check in form.

configuration key Properties:


Proper
Rules
ty
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.
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.
for complete Post plz follow below link
Configuration and Security Keys Best Practice Checks
-Harry

You might also like