Configure the Firewall on the Enterprise Portal Server

After you install Enterprise Portal, enable Web Server (HTTP) in Windows
Firewall. If you do not enable the web server in Windows Firewall, you can view
the site on the local server, but no other users can view the site. By default, when
you enable Web Server (HTTP) through the firewall, you enable port 80. If you
configured the Enterprise Portal site for a port other than port 80, enable that port
in Windows Firewall.

Regards,
Hossein Karimi

Configure Files for Sites in a Web Farm

If your Enterprise Portal site is not a part of a web farm, skip this procedure. Use
the following procedure to specify values for machineKey properties in the
web.config file of each server in the web farm. MachineKey properties
(validationKey and decryptionKey) are used for hashing and decrypting
authentication tickets and cookies. Values for machineKey properties must be the
same on all servers in the web farm. If they are not, Enterprise Portal pages might
display authentication and access errors.

1. On the web farm administration server, open the web.config file in a
text editor such as Notepad. By default, the file is located in the
following directory:

C:\Inetpub\wwwroot\wss\VirtualDirectories\PortNumber.

2. Locate the machineKey section and copy the validationKey and
decryptionKey values to a separate text file. The following is an
example of a machineKey section:

<machineKey
validationKey="4785A9C8F5FA32B47E5245AC48671291F1CE55
735A475EB7"
decryptionKey="D961976E181646326D64E01AB2052F5D076F0A
BDE2C702FB" validation="SHA1" />

3. Edit the web.config files on the other servers in the web farm.
Replace the existing machineKey values with the values that you
copied from the web farm administration server.
For more information about how to configure machineKey properties, refer to
How to: Configure MachineKey in ASP.Net 2.0

(http://go.microsoft.com/fwlink/?LinkId=117441), and specifically read the
section called "Web Farm Deployment Considerations."

Regards,
Hossein Karimi

Install Enterprise Portal and Role Centers

Use the following procedure to install Enterprise Portal and Role Centers using
Setup on a server that includes either Microsoft SharePoint Foundation 2010 or
Microsoft SharePoint Server 2010.

1. Start Microsoft Dynamics AX Setup.

2. Step through the initial wizard pages.

3. On the Modify Microsoft Dynamics AX installation page, selectAdd or modify components. Click Next.

4. On the Add or modify components page, expand Server
Components, expand Web Server Components, select Enterprise
Portal (EP). Click Next.

5. On the Prerequisite validation page verify that the prerequisites are
installed and when all the errors are resolved, click Next.

6. In Domain\user name, type "CONTOSO\SQLService".

7. In Password, type "Pa$$w0rd", then click Next.

8. On the Configure a Web site for Enterprise Portal page, select a
web site. If no web sites are available in the list, you must cancel
Setup, create a web site by using SharePoint Central Administration,
and then try the installation again.

9. In Site URL, type "DynamicsAxTestInstall". Click Next.



BEST PRACTICE: It is recommend that you select the Configure for Windows
SharePoint Services option. If you select this option, Setup verifies that the site is
a SharePoint site. If it is not a SharePoint site, Setup extends the site in
SharePoint. Setup also sets the application pool to run under the service account
and sets the authentication method to Windows NTLM.

IMPORTANT: Note the following important information about the Create Web
site option:

Clear this option if you are installing Enterprise Portal for a public site, such as
an unsolicited vendor portal. For public sites, you must create the Enterprise
Portal site by using the public site template.
If you are installing Enterprise Portal for a stand-alone installation, or on an
administration server for a Web farm, select the Create Web site option to create
a site at the following URL: http://ServerName/sites/DynamicsAX. Setup creates
a new site that uses port 80.

When you install Enterprise Portal on subsequent servers in a server farm, you
must clear this option. The site must be created only on the administration server
for the Web farm.

10. On the Prerequisite Validation page, click Next.

NOTE: If your business or organization purchased a Microsoft Dynamics AX
developer license, you can change the web site URL, title, and description before
completing the installation by modifying the EPSetupParams file in the
Application Object Tree (AOT) by opening Web > Web Files > Static Files >EPSetupParams.

11. On the Ready to install page, click Install.

12. If appropriate, select the option to restart IIS when the installation is
complete. Before you select this option, consider the effect of an IIS
reset on other applications on the web server.

13. Complete the wizard.

14. Repeat this procedure on every web server in the server farm.

NOTE: By default, Setup creates a site on port 80 when you install Enterprise
portal. However, you can create additional sites. For more information, refer to
Create an Enterprise Portal Site (http://technet.microsoft.com/enus/library/dd362092(AX.60).aspx)page on TechNet.

Regards,
Hossein Karimi

Users and Communication

In Microsoft Dynamics AX, Enterprise Portal users, or Web users, can be any of
the following individuals:

• Employees who access Microsoft Dynamics AX through an intranet
or an extranet

• Customer or vendors who access Microsoft Dynamics AX through
an extranet

• Unsolicited vendors who want to sign up to be vendors, and who
access Microsoft Dynamics AX through a public Internet site

• All Web users access Microsoft Dynamics AX through Enterprise
Portal.

Note the following information about Enterprise Portal client connections and
communications:

• All browser-based clients and Microsoft Dynamics AX clients access
Role Centers through Enterprise Portal. Microsoft Dynamics AX
clients use a browser control to display Role Centers.

• Enterprise Portal uses the Report Web part to display reports that
exist on the SQL Server Reporting Services server.

• Enterprise Portal uses ASP.NET user controls and the Enterprise
Portal framework to display Microsoft Dynamics AX data and
reports.

• Enterprise Portal uses Windows Communication Framework (WCF)
and .NET Business Connector to interact with an Application Object
Server (AOS).

The language that is used in the user interface for Enterprise Portal is determined
by the user interface language that is specified for each user in the Microsoft
Dynamics AX client. The user interface language also determines how values are
formatted.

Regards,
Hossein Karimi

Customizing Enterprise Portal

Enterprise Portal is built on ASP.NET. All Enterprise Portal objects are located
in the Web node of the Application Object Tree (AOT).

Microsoft Dynamics AX includes a standard Web part that can host a User
Control. Developers can write or modify User Controls in Microsoft Visual
Studio. User Controls are used to present Microsoft Dynamics AX content on a
page, and they are the primary way to add new functionality to Enterprise Portal.

Regards,
Hossein Karimi

Enterprise Portal

This topic introduces concepts that pertain to the architecture of Enterprise Portal
for Microsoft Dynamics AX. The topic also describes the various components of
the Enterprise Portal architecture.

Sites and Pages

An Enterprise Portal site consists of a root SharePoint 2010 products site and
collections of sub sites. The subsites approximate the features and functionality
of the modules in the Microsoft Dynamics AX client. For a detailed description
of each Enterprise Portal module, and the common tasks, features, and reports
that are available in each module, refer to the Overview of Enterprise Portal for
Microsoft Dynamics AX topic on TechNet.

An Enterprise Portal page can include standard Microsoft Dynamics AX Web
parts, such as the toolbar, or User Control Web parts that display Microsoft
Dynamics AX data. An Enterprise Portal page can also include standard
SharePoint 2010 products Web parts, such as lists, announcements, and
discussions. Users can modify these Web parts as needed. If you set up and
configure Enterprise Portal with Role Centers, Role Center pages can include the
following elements:

• Cues that provide a visual representation of records based on the
status of the records. For example, there can be cues for pending
sales orders or items that are on backorder.

• Key performance indicators (KPIs) that provide information from
predefined data cubes. You can use this information to monitor
business performance against a defined goal.

• A Report Web part that provides access to SQL Server Reporting
Services reports.

• A Business Overview Web part that displays historical performance,
such as year-over-year performance or month-over-month
performance.

• A work list that displays action items that are generated either by a
workflow or by an alert, according to business needs.

• Community links that provide access to items that are published on
community sites for Finance, Services, and Sales and Marketing.

• Links that provide access to important internal and external sites.

Regards,
Hossein Karimi

Configure security settings in Reporting Services

Complete the following tasks in Reporting Services:

• Assign users to the DynamicsAXBrowser role in Reporting Services.
For detailed instructions about how to assign users to Reporting
Services roles, refer to the SQL Server documentation on MSDN.

• Identify the account that is used to run the Application Object Server
(AOS) service and the account that is used as the Business Connector
proxy. Assign those accounts to the DynamicsAXBrowser role in
Reporting Services. For detailed instructions about how to assign
users to Reporting Services roles, refer to the SQL Server
documentation on MSDN.

• Restrict access to report folders and reports. Reporting Services
includes security features and tools that you should use to help
control access to report folders and published reports. Refer to the
SQL Server documentation on MSDN for detailed conceptual
information and step-by-step tutorials that will help you administer
security in Reporting Services. 

Regards,
Hossein Karimi

Configure security settings in Microsoft Dynamics AX

Complete the following tasks in Microsoft Dynamics AX:

• Determine which reports each Microsoft Dynamics AX role should
have access to.

• Verify that each Microsoft Dynamics AX role has the correct duties
and privileges assigned to it in order to access the reports.

• Assign users to Microsoft Dynamics AX roles.

• Secure the data shown in reports.

Regards,
Hossein Karimi

Securing Confidential Reports

Reports that contain confidential information should be secured at the data-access
level, by requiring users to provide credentials to access sensitive data. For more
information, refer to the Specifying Credential and Connection Information for
Report Data Sources (SSRS) topic on MSDN. You can also secure a folder to
make it inaccessible to unauthorized users. For more information, refer to the
Securing Folders topic on MSDN.

Grant Users Access to Reports

To grant users access to reports, you must configure security settings in
Microsoft Dynamics AX and in Microsoft SQL Server Reporting Services. The
following sections describe the tasks that you must complete in each application.

Mitigating SQL Injection Attacks in a Parameterized Report

In any report that includes a parameter of type String, be sure to use an available
values list (also known as a valid values list) and ensure that any user running the
report has only the permissions required to view the data in the report. When you
define a parameter of type String, the user is presented with a text box that can
take any value. An available values list limits the values that can be entered. If
the report parameter is tied to a query parameter and you do not use an available
values list, it is possible for a report user to type SQL syntax into the text box,
potentially opening the report and your server to a SQL injection attack. If the
user has sufficient permissions to execute the new SQL statement, it may
produce unwanted results on the server.

If a report parameter is not tied to a query parameter and the parameter values are
included in the report, it is possible for a report user to type expression syntax or
a URL into the parameter value and render the report to Excel or HTML. If
another user then views the report and clicks the rendered parameter contents, the
user may inadvertently execute the malicious script or link.

To mitigate the risk of inadvertently running malicious scripts, open rendered
reports only from trusted sources.

Regards,
Hossein Karimi

Mitigating Script Injection Attacks in a Hyperlink in a Published Report or Document

Reports can contain embedded hyperlinks in the value of the Action property on
a report item or part of a report item. Hyperlinks can be bound to data that is
retrieved from an external data source when the report is processed. If a
malicious user modifies the underlying data, the hyperlink might be at risk for
scripting exploits. If a user clicks the link in the published or exported report,
malicious script could run.

To mitigate the risk of including links in a report that inadvertently run malicious
scripts, only bind hyperlinks to data from trusted sources. Verify that data from
the query results and the expressions that bind data to hyperlinks do not create
links that can be exploited. For example, do not base a hyperlink on an
expression that concatenates data from multiple dataset fields. If necessary,
browse to the report and use "View Source" to check for suspicious scripts and
URLs.

Regards,
Hossein Karimi

Report Parameters and Script Injection

Report Parameters provide flexibility for the overall report design and execution.
However, this same flexibility can, in some cases be used by an attacker in luring
attacks. To mitigate the risk of inadvertently running malicious scripts, only open
rendered reports from trusted sources. It is recommended you consider the
following scenario that is a potential HTML Renderer script injection attack:

1. A report contains a text box with the hyperlink action set to the value
of a parameter which could contain malicious text.

2. The report is published to a report server or otherwise made available
in such a way that the report parameter value can be controlled from
the URL of a web page.

3. An attacker creates a link to the web page or report server specifying
the value of the parameter in the form "javascript:<malicious script
here>" and sends that link to someone else in a luring attack.

Regards,
Hossein Karimi

Mitigating HTML Injection Attacks in a Published Report or Document

In Reporting Services, reports and resources are processed under the security
identity of the user who is running the report. If the report contains expressions,
script, custom report items, or custom assemblies, the code runs under the user's
credentials. If a resource is an HTML document that contains script, the script
will run when the user opens the document on the report server. The ability to run
script or code within a report is a powerful feature that comes with a certain level
of risk. If the code is malicious, the report server and the user who is running the
report are vulnerable to attack.

When granting access to reports and to resources that are processed as HTML, it
is important to remember that reports are processed in full trust and that
potentially malicious script might be sent to the client. Depending on browser
settings, the client will execute the HTML at the level of trust that is specified in
the browser.

You can mitigate the risk of running malicious script by taking the following
precautions:

• Be selective when deciding who can publish content to a report
server. Because the potential for publishing malicious content exists,
you should limit users who can publish content to a small number of
trusted users.

• All publishers should avoid publishing reports and resources that
come from unknown or untrusted sources. If necessary, open the file
in a text editor and look for suspicious script and URLs.

Regards,
Hossein Karimi

Role-Based Access to Reports and Resources

To grant access to reports and resources, you can allow users to inherit existing
role assignments from a parent folder or create a new role assignment on the item
itself.

In most cases, you will probably want to use the permissions that are inherited
from a parent folder. Setting security on individual reports and resources should
only be necessary if you want to hide the report or resource from users who do
not need to know that the report or resource exists, or to increase the level of
access for a report or item. These objectives are not mutually exclusive. You can
restrict access to a report to a smaller set of users, and provide all or some of
them with additional privileges to manage the report.

You may need to create multiple role assignments to achieve your objectives. For
example, suppose you have a report that you want to make accessible to two
users, Ann and Fernando, and to the Human Resource Managers group. Ann and
Fernando must be able to manage the report, but the Human Resource Managers
members need only to run it. To accommodate all of these users, you would
create three separate role assignments: one to make Ann a content manager of the
report, one to make Fernando a content manager of the report, and one to support
view-only tasks for the Human Resource Managers group.

Once you set security on a report or resource, those settings stay with the item
even if you move the item to a new location. For example, if you move a report
that only a few people are authorized to access, the report continues to be
available to just those users even if you move it to a folder that has a relatively
open security policy.

Regards,
Hossein Karimi

Assembly Access on a Report Server

If an administrator grants an assembly access to the SessionManager API (which
wraps .NET Business Connector), then the assembly must be given the
AxSessionPermissionSet in the rssrvpolicy.config file on the report server.

NOTE: This is the recommended setting for business logic assemblies
(depending on the main report project name length, either .BusinessLogic.dll or
.BL.dll), and it is added by default for the business logic assemblies that are
created for a deployed reporting project. This includes the business logic
assemblies from referenced reporting projects.

Giving a custom assembly full trust in the report server security policy file allows
the assembly to directly access .NET Business Connector running under the
Business Connector proxy account. This is an account that has elevated
privileges that allows for access to the LogonAs functionality. In this case, the
assembly could impersonate any user and access their records.
Granting a custom assembly ReflectionPermission with MemberAccess could
allow the assembly to retrieve cached sessions from the session cache. Those
sessions are logged in for a specific user, and the custom assembly could have
access to that user's data.

The following code must be present in the custom code section of the RDL file if
the report is expected to make use of the SessionManager API:

Protected Overrides Sub OnInit()
Microsoft.Dynamics.Framework.Reports.SessionManager.BeginRequest(Report)
End Sub

Entries in the security policy file will not be created for any assemblies
referenced by business logic assemblies. 

Regards,
Hossein Karimi

Projects and Builds Reporting

When building a project from the command line, Microsoft Dynamics AX
reporting tools does not perform any checks for unsafe entries in the project file.
The project file entries are not analyzed by Microsoft Dynamics AX reporting
tools from a security perspective. Therefore, it is strongly recommended that you
do not build third-party reporting projects from the command line. Build from the
command line only in trusted scenarios.

Microsoft Visual Studio, with the help of MSBuild, analyzes unsafe entries in a
project file when it is loaded and warns you about them. An example of an unsafe
entry is the redirection of the project output path to a system folder. For example,
the output path could be redirected to C:\Windows, which could overwrite a
system file. Or, the output path could be redirected so as to overwrite a default
MSBuild property for Microsoft Dynamics AX reporting tools projects. When
attempting to open a reporting project that contains unsafe entries, a dialog box
displays that prompts you not to open the project. If you experience this, you
should inspect the unsafe entries as you decide whether to open the project.
Project files, model files, code files, and referenced assemblies should always be
placed in a safe location whether it is a local folder, network share, or source
code control database. The default project location for Microsoft Visual Studio
projects is \My Documents\Visual Studio 2010\Projects, which is protected by
the administrator and current user access control lists.

Threat detection in a business logic project is limited to the functionality
provided by standard C# and Visual Basic project systems in Microsoft Visual
Studio. The current implementation of the C# and Visual Basic project systems
displays only the first detected threat in the project file. Therefore, if you skip the
threat and load the project file, all other threats that exist in the project file will
be skipped.

The build cache file has an internal binary structure. The first violation of this
structure that is discovered will force the compilation to regenerate the file. If the
file is modified without violating the structure, the issue will not be mitigated,
but you can invoke a clean build to regenerate the build cache file to eliminate
the threat.

Regards,
Hossein Karimi

Data Access Reporting

When accessing data from the Microsoft Dynamics AX database, it is
recommended that you use the predefined Microsoft Dynamics AX data sources
to ensure that appropriate security is enforced. For more information about the
predefined Dynamics AX data source, refer to Securing Reports and Resources
on MSDN and Securing Reporting Services in SQL Server 2008 Books Online.

Regards,
Hossein Karimi

Configure Report Servers

When you install the business intelligence components for Microsoft Dynamics
AX 2012, setup will automatically create a report server configuration. Setup
uses the information provided in the wizard to set the parameters in each field.

You can use the Report server form to manage Microsoft Dynamics AX AOS
connections to a Microsoft SQL Server Reporting Services instance. This might
be necessary for example when setting up a test environment, or after you refresh
the data in a test from a production you must configure the report server to make
sure that the reporting servers are configured to point to the correct test servers
instead of the production servers.

Open System administration > Setup > Business Intelligence > Reporting Services > Report servers.



To configure a report server, follow these steps.

1. Open System administration > Setup > Business intelligence > Reporting Services > Report servers.

2. Either click New to create a new report server, or select the desired
report server to modify. You can use the Use default settings button
to reset the Report Manager URL, Web service URL, andMicrosoft Dynamics AX report folder fields to their default entries.

3. Enter a name to identify the Reporting Services and AOS instances
that you are connecting in the Configuration ID field.

4. Enter a brief description to help you identify the Reporting Services
and AOS instances that you are connecting in the Description field.

5. Select the Default configuration check box if the Reporting
Services instance specified in this configuration is the default report
server for the AOS instance.

6. Enter the name of the server on which Reporting Services is
installed.

7. Enter the name of the Reporting Services instance.

8. Enter the URL of the Report Manager website. The default URL is
http://SSRSServerName/reports.

9. Enter the URL of the Reporting Services web service. The default
URL is http://SSRSServerName/reportserver.

10. Enter a name for the folder that will be created on the Report
Manager website in the Microsoft Dynamics AX report folderfield. If a folder does not exist, you can use the Create report folderbutton to create the folder.

11. Select an AOS instance.

12. When you are finished making changes, click Validate settings to
verify that the AOS instance can communicate with the Reporting
Services instance.

Regards,
Hossein Karimi

Deploy Reports in PowerShell

After you have loaded the Microsoft Dynamics AX PowerShell module and
retrieved a list of reports, you can deploy the reports. The Publish-AXReport
cmdlet is used to deploy the reports. The following examples show you how to
use this cmdlet.

1. To deploy a specific report, enter the name of the report. For
example, the following command is used to deploy the
CustTransList report: "Publish-AXReport -ReportName
CustTransList", and then press Enter.

2. To deploy two or more specific reports, enter the names of the
reports. For example, the following command is used to deploy the
CustTransList and CustTransOpenPerDate reports: "PublishAXReport -ReportName CustTransList, CustTransOpenPerDate", and then press Enter.

3. To deploy all reports, enter the following command: "PublishAXReport –ReportName *", and then press Enter.

Regards,
Hossein Karimi

Filter a List of Reports in PowerShell

In the previous procedure, you displayed a list of all the Microsoft Dynamics AX
default reports that you can deploy. This procedure will help you filter the list.

1. Modify the list so that only the Name and ChangedDate fields are
displayed by entering the following command: "$reports | SelectObject Name,ChangedDate" and then press Enter.

2. Modify the list so that only specific reports are listed. For example,
to filter the list so that only the reports that contain the wordCustTrans are listed, enter the following command: "$reports |
Select-Object Name,ChangedDate | Where { $_.Name -like
"CustTrans*" }", and then press Enter.

Regards,
Hossein Karimi