Security for Microsoft Dynamics AX 2012

Security for Microsoft Dynamics AX 2012

Security Concepts

Security Hierarchy

 

Privilege

 

Privileges are used to give access to securable objects.

A privilege contains permissions, plus one or more entry points.

How to make a privilege?

Step 1 : Make a new Privilege.

              Privileges-> New -> Privilege

Step 2 : Make an Entry Point

 

 

 

Permission to the application object.

Entry point can have

1.Menu item -> Forms

2.Service Operation -> Fro AIF Related tasks

3.Web content -> action items, managed content, URL -> For Enterprise Portal

Permission

 

A permission is the simplest security artifact. Sets of permissions are usually grouped into a privilege.

 

Hierarchy of permissions

›Read - Lets the user see data but not change it

›Update - Lets the user change data but neither create it nor delete it

›Create - Lets the user insert new data records; plus, it gives the user Update and Read permissions

›Correct - The Correct permission applies only when a time state table is involved. This permission authorizes you to issue update records in a time state table.

›Delete - Delete permission includes every other permission

›NoAccess

›If instead the object type is ServiceOperation, the value can be one of the following:

•Invoke. The server method can be called.

•NoAccess. The server method cannot be called.

 

 

Duty

A duty defines the functionality for a business process – for example, View customer accounts.

A duty can only contain privileges, but it can belong to more than one role.

 

 

 

 

Step 3: Make Enabled property  Yes in the properties of the added privilege.

 

 

Role

All users must be assigned to at least one security role in order to have access to Microsoft Dynamics AX.

The security roles that are assigned to a user determine the duties that the user can perform and the parts of the user interface that the user can view.

 

 

 

 

 

AX 2012 Export and Import a Model files (.axmodel)

AX 2012 Export and Import a Model files

A model is a set of elements in a given layer. Each layer consists of one or more models. Models can be exported to files that have the .axmodel extension. These files are called model files. Model files are deployment artifacts that can be imported into a model store.

A model is permanently associated with the layer that is created in. If you need to move one of your models from one layer to another, you must create a project from the model in the AOT, export the project as an xpo file, create a target model in the desired layer, delete the original model to avoid having to resolve layer conflicts, and import the xpo file to the target model. If you are moving elements between models in the same layer, you can use the Move to model command in the AOT.

You can use either Windows PowerShell cmdlets or the AXUtil command-line utility to export models to model files and import model files into a model store.

Exporting model files

---

Export an .axmodel file (Windows PowerShell)

1. On the Start menu, point to All Programs, point to Administrative Tools, and then click Microsoft Dynamics AX Management Shell.
2. At the Windows PowerShell command prompt, PS C:\>, type the following command, and then press ENTER.

Windows PowerShell

Export-AXModel –Model > -File > -Details

This example exports the specified model to a file that has the specified file name.

You can use the -Key parameter to specify the strong-name key pair file to use to sign a model.

3. You can also use the Sign Tool to sign the file with a digital certificate, or the AXUtil genlicense command to Authenticode sign a file.

Export an .axmodel file (AXUtil)

1. On the Start menu, click Command prompt.
2. Navigate to the directory for the management utilities. Typically, the location of this directory is %ProgramFiles%\Microsoft Dynamics AX\60\ManagementUtilities.
3. At the command prompt, type the following command, and then press ENTER.

4.  axutil export /model: /file: /verbose

This example exports the specified model to a file that has the specified file name.

You can use the [/key:SNK-file] parameter to specify the strong-name key pair file to use to sign a model.

5.       You can also use the Sign Tool to sign the file with a digital certificate, or the AXUtil genlicense command to Authenticode sign a file.

Importing an .axmodel file

---

By default, when you import a model from Windows PowerShell or AXUtil, the installation mode is set to display the Model code upgrade checklist when the Microsoft Dynamics AX client starts. If you import a model by using Setup.exe, by default, the installation mode does not display the Model code upgrade checklist.

Import an .axmodel file (Windows PowerShell)

1. On the Start menu, point to All Programs, point to Administrative Tools, and then click Microsoft Dynamics AX Management Shell.
2. At the Windows PowerShell command prompt, PS C:\>, type the following command, and then press ENTER.

Windows PowerShell

Install-AXModel -File > -Details

This command installs the specified file in the same layer that it was exported from.

By default, you will be prompted to install the model based on whether it has been signed. The following table describes the prompts shown.

If the installation fails because of a conflict, we recommend that you rerun the cmdlet, and use the -Conflict Push option to push the element that has the conflict to the related update layer. You can then resolve the conflict


Ex:
Install-AXModel -File C:\temp\MK_Patch5_AX2012R3CU11.axmodel -Details

Import an .axmodel file (AXUtil)

1. On the Start menu, click Command prompt.
2. Navigate to the directory for the management utilities. Typically, the location of this directory is %ProgramFiles%\Microsoft Dynamics AX\60\ManagementUtilities.
3. At the command prompt, type the following command, and then press ENTER.

4.  axutil import /file: /verbose

This command installs the specified file in the same layer that it was exported from.

If the installation fails because of a conflict, we recommend that you rerun the command, and use the /conflict:push option to push the element that has the conflict to the related update layer. You can then resolve the conflict

When you import a model, elements in the model that you are importing may conflict with another model in the same layer. In this situation, you can create a conflict modelin the patch layer that is associated with the layer that you are working in. You can then resolve the conflicts in the conflict model.

For More information:

http://technet.microsoft.com/en-us/library/hh352314.aspx

Export Import-AXModelStore

Syntax
Parameter Set: Default
Import-AXModelStore [-Apply ] [-BackupSchema ] [-Config ] [-Database ] [-Details] [-File ] [-IdConflict ] [-NoPrompt] [-SchemaName ] [-Server ] [ ]

Examples
Import Model store 
PS C:\Windows\system32> Import-AXModelStore -File P:\SCAX2012_model.axmodelstore

Syntax
Parameter Set: Default
Export-AXModelStore -File [-Config ] [-Database ] [-Details] [-Server ] [ ]

Examples
Export Model StoreCommand

PS C:\Windows\system32> Export-AXModelStore -File P:\SCAX2012_model.axmodelstore -Database SCAX2012_model -Details

With SQL server running on different system

Export-AXModelStore -File C:\Temp\SCAX2012_model.axmodelstore -Server tscAX2012dbs -Database SCAX2012_model -Details

https://technet.microsoft.com/en-us/library/jj720286.aspx

https://technet.microsoft.com/en-us/library/jj720259.aspx 

PowerShell commands

Here I'll start a collection of useful PowerShell commands:

Get-Content writes the content of a file to PowerShell window:
Get-Content c:\scripts\test.txt - wait

To get the last x lines use Select-Object - last x: (it might take some time :) )
Get-Content c:\scripts\test.txt | Select-Object -last 5


Microsoft Dynamics AX 2012 Management Shell

List Models

Get-AXModel -Config AOSName
Model Content:
(Get-AXModel -Model "USR Model" -Details).Elements | Out-String

Install / Uninstall a model

Install-AXModel -File Filename.axmodel -Config AOSName
Uninstall-AXModel -Database "NameOfDB" -Model "NameOfModel"

you could always use -Config AOSName or -Database "NameOfDB".

to overwrite existing elements in a model use -conflict: overwrite

Export a model

Export-AXModel –Model "NameOfModel" -File "FileName"

you could always use -Config AOSName or -Database "NameOfDB".

Export a modelstore

Export-AXModelStore -Config AOSName -File Filename.axmodelstore -Details

With SQL server running on different system

Export-AXModelStore -File C:\Temp\SCAX2012_model.axmodelstore -Server tscAX2012dbs -Database SCAX2012_model -Details

Import a modelstore

Stop the AOS for the import

Import-AXModelStore -Config AOSName -File Filename.axmodelstore

To reduce the downtime of the AOS the modelstore could be imported to a temporary schema 

Import-AXModelStore -File Filename.axmodelstore -SchemaName TemporarySchema

Drain all client connections from the AOS instance and apply the temporary schema

Import-AXModelStore -Apply:TemporarySchema -Config AOSName

Import Model store with ID Conflit

 Import-AXModelStore -File F:\ModelStore\SCAX2012_model.axmodelstore -IdConflict Overwrite

SSRS Reports

Get a List of Reports starting with A and store it in a variable
$reports = Get-AXReport -ReportName A* -ServicesAOSWSDLPort 8109 
To view the List 
$reports 

Deploy Reports:
Publish-AXReport -ReportName CustTransList -ServicesAOSWSDLPort 8109

SSRS Reporting Framework in AX 2012

SSRS Reporting Framework in AX 2012

We will start with understanding basic concepts in Reporting Framework to examples.

Reporting Framework Terminologies

As you all know, the reports in AX 2012 have moved to SSRS reporting, so MS has introduced a robust reporting framework wrapping over the basic SSRS reporting functionality. There are many terms used in reporting framework in AX that I will try and explain here:

·         Report Definition Language: RDL is an XML application primarily used with Microsoft SQL Server Reporting Services. RDL is usually written using Visual Studio. AX has Report Definition Language Contract classes that can generate and build the RDL for an AX SSRS report. This contract provides a weakly typed representation of parameters. It contains methods that can be used to get or set values. It also contains a map of parameter names and the SrsReportParameter class. The base class is SrsReportRdlDataContract.

·         Report Data Provider (RDP): A framework that helps in building, processing and rendering data to reports. Most of the reports require RDP classes that help in implementing business logic required to process data and provide data in readable, presentable and required formats design. The base class is SrsReportDataProvider. This class has two main sub classes,SrsReportDataProvderBase and SrsReportDataProviderPreProcess. We will discuss about these classes in future posts.

·         Report Data Contracts: The Report Data Contracts framework is used to provide and manage the parameters to an SSRS report. The report data contract contains all the other relevant instances like Report Data Provider contracts, print contracts, RDL contracts and query contracts that will be used by a report.

·         Printing Contracts: The framework that manages report printing (to different mediums). The base class is SrsPrintDestinationSettings. There are other supporting contracts that are used for printing, we will discuss about them in future posts.

·         Query Contracts: This framework manages the queries used to process report data. This framework is also responsible for providing dynamic filters (similar to our ‘Select” buttons on report dialogs that open the Query specification form to filter data on report queries).

·         Report Controllers: Report controllers control the report execution and dialog forms. Report controllers can be used to modify report dialogs, validate report parameters and other validations necessary before report execution. The base class is SrsReportRunController. Reports utilizing report controllers can only be used for printing data on client side. Reports controlled by controllers cannot be used in Enterprise Portals.

·         Report UI Builders: UI Builders are used to modify the report dialogs at run-time or to add additional parameters and write custom business logic to report dialogs. Ex: You want to perform some task based on data modified for one parameter, that affects other parameters or build a custom lookup etc (something that was provided by RunBaseReport framework class in previous versions. The base class is SrsReportDataContractUIBuilder