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.
AnalysisVisibility	Mandatory property for top-level security keys (keys that have no parent 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:

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