Skip to main content

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: 

PropertyRules
IDAlways 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.
NameOne 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 byService. 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. 

LabelMandatory property.
AnalysisVisibilityMandatory 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: 

PropertyRules
IDAlways 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.
NameFollow 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

Comments

Popular posts from this blog

Process of Sales order in Technical terms in D365Fo

 🔥 Sales Order Technical Flow in D365FO (Creation → Confirmation → Picking → Packing Slip → Invoice → Accounting) 1. Sales Order Creation Tables SalesTable → SO header SalesLine → SO lines CustTable → Customer master InventDim / InventDimCombination → Dimensions InventTable / EcoResProduct → Item master Framework Classes SalesTableType / SalesLineType Responsible for validation, defaulting, creation logic Key Methods SalesTable.initValue() SalesLine.initFromSalesTable() SalesTable.validateWrite() SalesLine.validateWrite() Events (Extensions) SalesTableType.createSalesTable() SalesLineType.createSalesLine() 2. Reservation (Optional) If reservation is done: Tables InventTrans (Reservation status) InventReservation Classes InventUpd_Reservation InventTransReservation Reservations impact picking and inventory availability. 3. Sales Order Confirmation Confirms order and freezes price/quantity. Posti...

Top 200 Q&A in D365FO Technical

  SECTION 1 — X++ BASICS (10 Q&A) 1. What is X++? A proprietary object-oriented language used in Dynamics 365 Finance & Operations for business logic, similar to C# but integrated with D365 runtime. 2. What is a TableBuffer? It is an in-memory object referencing a table. Example: CustTable custTable; 3. What is difference between select and select firstonly ? select → returns all matching rows firstonly → returns only the first matched row 4. What is ttsbegin & ttscommit ? Used to wrap database transactions; ensures atomicity. 5. Can we write SQL queries directly in X++? No. X++ uses a database-abstracted select statement. 6. What is a container? A collection datatype used to store mixed data types. 7. Difference between container and map? Map stores key-value pairs; container is indexed and immutable. 8. What is a temp table? A table that stores data temporarily in memory or database depending on property. 9. What is recursion in X++? A method c...

Process of Purchase order in Technical terms in D365Fo

  Purchase Order Technical Flow in D365FO (Step-by-Step) (From creation → approval workflow → posting → product receipt → invoice → accounting) 1. Purchase Order Creation Tables involved PurchTable → PO header PurchLine → PO lines VendTable → Vendor master InventDim / InventDimCombination → Item dimensions EcoResProduct / InventTable → Item master Classes / Framework PurchTableType / PurchLineType Framework that controls creation, validation, defaulting. Key methods PurchTable.initValue() PurchLine.initFromPurchTable() PurchTable.validateWrite() PurchLine.validateWrite() Events (Extension points) PurchTableType.createPurchTable() PurchLineType.createPurchLine() 2. Purchase Order Confirmation Document Status update PurchTable.DocumentState → Confirmation PurchParmBuffer tables used for versioning. Posting Class PurchFormLetter_Confirm Called internally via PurchFormLetter::construct(DocumentStatus::Co...