Manage table and field access

Whereas security keys control access to functionality within the application, this security access is limited to menu items. To help protect the system at a more granular level, it is important to set up security for table and field access.

All tables and fields are available in the security system, and access can be set up individually for each user group working within a company or domain without affecting other user groups. Table and field access is configured when you set security keys (Administration > Setup > Security > User group permissions on the Permissions tab).

The following graphic shows how to access and configure table and field access from the User group permissions window.

Table access

---

User group access to a table is defined by several factors:

• The table rights defined for the user group within the domain or company.
• The table's security key and the user group's security key rights within the domain or company with regard to the table.
• The setting of the MaxAccessMode table property.

Note
The MaxAccessMode property affects only access through the user interface. Code can still access the table, even if the MaxAccessMode is set to No access.

These factors are used for the calculation of a user group's permissions to each table in the application.

The following chart shows how table rights are calculated during startup. Tables have two properties: Configuration key and Security key.

Field access

---

Like user group table access, user group access to a field is defined by several factors:

• The field rights defined for the user group within the domain.
• The field's security key and the user group's security key rights within the domain for the field.
• The setting of the Visible field property.
• The setting of the AllowEdit field property.

These factors are used for the calculation of a user group's permissions to each field in the application. The calculation is performed during startup.

The following chart shows how field rights are calculated during startup.

After the user group's access to a field has been calculated, this access is compared to the one defined for the table. A user group's access to a field can never exceed the group's access to the table that the field belongs to. The final field access becomes the lesser of the field and table rights.

Security considerations and best practices

The first step toward helping to secure Microsoft Dynamics AX is to make sure that it is deployed in a secure environment. For a network connected to any other network, including the Internet, extranets, and other internal networks, this means making sure that sufficient measures are taken to keep the network secure from external threats.

Additionally, whenever you make a change to the system, part of your planning should include attention to helping make the new system secure. For more information, see the Microsoft Dynamics AX Installation Guide.

For the latest information about security, see the TechNet Security Center. It provides security tools, security response information, such as security bulletins and virus alerts, and the most prescriptive security guidance Microsoft has to offer to help IT Professionals in securing their systems.

The foundation

---

Microsoft Dynamics AX requires Active Directory to support its user structure. The Active Directory should be configured correctly to make sure it complies with your company’s security policies regarding user access. The computers that are running Microsoft Dynamics AX must have access to computers in the same domain running Active Directory configured in native mode. It may be the case that not all network users need access to Microsoft Dynamics AX. Therefore, it is more secure to simply not grant them access in Active Directory. For more information about how Microsoft Dynamics AX integrates with Active Directory for security, see Working with users from Active Directory. For the latest recommendations for configuring Active Directory, see the Microsoft Windows Server 2003 Active Directory Technology Center.

For deployments that include the Enterprise Portal component, there are additional environmental security issues to address. The network should have a firewall. It should also have one or two domain controllers. When there are two domain controllers, one should be in the internal network and the other in the perimeter network.

This configuration is performed with Active Directory. For more information about how to set up security for Enterprise Portal, see Configuring Enterprise Portal security in the Enterprise Portal Administration Guide.

Run Application Object Server (AOS) service with least privileges

---

When the Application Object Server (AOS) is installed, the user for the AOS service is set to either the Network Service account or a domain account. If you decide to use a domain account for the AOS service, you should make sure that the new account has the lowest (most restrictive) possible privileges, to help reduce the risk of processes that could cause harm to the server. For more information, see the Microsoft Dynamics AX Installation Guide.

Secure database logs

---

Database logs can contain sensitive data. By default, any database log that is created can be queried by any user who has access to the database. Users can query the log by using Business Connector, X++, alerts, or by using direct access to the database. To protect data, restrict the permissions on the sysdatabaselog table. For detailed information, see Table Properties in the Microsoft Dynamics AX SDK.

Secure batch processing

---

Use the following security best practices to prevent users from submitting to batch groups that are processed with a higher permission level:

• Limit the number of user groups that have access to the Basic > Periodic > Batch journal execution menu item and the Basic > Periodic > Processing menu item. For more information, see Manage security permissions for user groups and domain combinations.
• Apply record level security restrictions on the BatchGroup table. For more information, see Manage record level security.

Denial of service attacks

---

To help prevent denial of service attacks on your Enterprise Portal, you can adjust the values of the following configuration commands in the configuration file of the Application Object Server (AOS):

• MaxConcurrentGuestSessions – This value controls the maximum number of concurrent Guest (anonymous user) sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.
• MaxConcurrentWebSessions – This value controls the maximum number of concurrent Enterprise Portal sessions that includes Guest sessions. The default value is 65535. By decreasing this value, you can reduce the number of sessions that an attacker can hold. After you set this value, you must restart the AOS for the change to be applied.
• MaxMemLoad – This value controls the maximum amount of memory usage (the maximum percentage of physical memory that is used on the computer). The default value is 100. By decreasing this value, you can reduce the number of sessions that an attacker can start. After you set this value, you must restart the AOS for the change to be applied.

For detailed information about how to use MaxConcurrentGuestSessions, MaxConcurrentWebSessions, MaxMemLoad and other configuration commands, see Using the command line to manage the AOS.

Best practices

---

The following are best practices for administering security of your Microsoft Dynamics AX environment:

• All Microsoft Dynamics AX user accounts should reside in restricted, well-defined user groups. A domain user account should be created and used to run Microsoft Dynamics AX.
• We recommend restricting user group access to the Admin domain. To do this, in the User group permissions form, select a non-administrator user group and select the Admin domain. On the Permissionstab, click Set all to No access. Repeat this procedure for each non-administrator user group. Create separate domains containing just the companies that users should have access to.
  
  To prevent user groups from accessing information in domains that they do not belong to, set the permission level on the Open domain access security key to No access.
• Following the principle of least privilege, anyone using the Microsoft Dynamics AX system should have minimal rights. If you are uncertain about whether to allow permission to a certain item, leave the permissions level set to No access. It is better to deny permission to an item and force an individual to request permission for their group than to grant permission to an area that a group should be unable to access.
• Restrict the number of users who are members of the Administrators group, which has access to all fields, tables, reports, and modules in Microsoft Dynamics AX by default. If users are made members of theAdministrators group, they can potentially view reports or data that they should not be able to see, or change configurations and business logic in the system. Ideally, only those individuals who are configuring and administering Microsoft Dynamics AX should be members of the Administrators group. Access in the Administrators group cannot be altered.
• Work with managers who oversee the different groups in the business or organization to determine permission levels. For example, work with a manager in the Finance department to determine permission levels for the Finance group or groups. The manager knows which groups should have permissions to items like General ledger and Bank, including permissions on child nodes.
• Passwords should never be used across systems and domains. For example, an administrator responsible for two domains may create Domain Administrator accounts in each that use the same password, and even set local administrator passwords on domain computers that are the same across the domain. If this happens, a compromise of a single account or computer could lead to a compromise of the whole domain. Passwords should never be reused in this manner.
• Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible. Domain Administrator accounts are typically used as service accounts for common services such as backup systems. However, it is a security risk to use Domain Administrator accounts as service accounts, because the password must be stored, or cached, locally on every computer where the service resides. The password can easily be retrieved by anyone with administrative rights over the computer. If this happens, the compromise of a single computer could lead to a compromise of the whole domain. Service accounts should never be domain administrator accounts, and they should be limited in privilege as much as possible.
• If you change permissions for a user group, especially if you demote permissions, restart the server after you make the change. If you do not restart the server, members of the group might keep their former permissions until the next time that the server is restarted.
• As a best practice, ask members of a group to log off Microsoft Dynamics AX before changing permissions and inform all Microsoft Dynamics AX users of the impending server restart. If it is necessary, before changing user group permissions, select users in User group permissions (Administration > Common Forms > Online users) and then click End sessions.
  
  For more information, see Remove users.

Security keys

Dynamics AX 4.0

Security keys are the permissions that control access to functionality within the application, and are set to individual user groups and users.
Security keys are set up from Administration > Setup > Security > User group permissions on the Permissions tab.
Within a security profile, you can assign permissions that define access to Menu items, Form controls, Tables and Fields.
There are five available access levels:

• No access - Completely restricts access to that item and any sub-items it controls. The Open command is disabled. Also, the node is not displayed in the Application Object Tree (AOT).
• View access - Members of the user group are allowed to view the item, but not use it. The Save, Compile, Lock and Unlock commands are disabled.
• Edit access - Members of the user group are allowed to view and use the item. The New, Duplicate and Rename commands are disabled.
• Create access - Members of the user group are allowed to view and use, as well as add new items. The Delete command is disabled.
• Full control - Members of the user group have full access and consequently no commands are disabled. Additionally, members can provide additional rights in special cases.

Security access for each user must be decided before they first log on. Access depends on which user groups the user is a member of, and which company or domain the user is a member of. Access to functionality of each security key can depend on its parent, so the calculation must be done hierarchically.
To configure security keys, the administrator first selects a User Group and a corresponding Domain (it is possible to select all domains at once). The security tree is then built, and the administrator is able to view the tree and make the necessary changes.

Note
When a security key property is changed for any AOT object, the client must be restarted for the changes to become visible.

For information about how to set security keys and for information about best practices, see Set up security keys¹.

Security key logic and organization

---

Security keys are used to restrict user group access in Microsoft Dynamics AX. Security keys have two main properties:

• Configuration Keys – The Configuration Key system allows an administrator to set the availability of functionality for the entire system. These modifications are to subsets of a module's functionality that are not currently necessary to have enabled within the system. From a security perspective, the removal of unused functionality reduces the surface that is open to attack. For more information, see Enable and disable configuration keys².
• Parent (only one parent can be specified) – Parent/child relationships control whether a key can be disabled. If you assign permission to a parent-node key (for example, if you select Absence approver and then select Full control) all child nodes inherit the same permission. If you do not want all child nodes to inherit the same permission, you can change permissions on individual child nodes.

The following graphic shows the path that is taken to validate security access.

Note
If you have set up domains within Microsoft Dynamics AX, security is applied to the individual domains. Otherwise, security is set up for all companies.

Each parent security key represents a broad umbrella of functionality within Microsoft Dynamics AX, and the underlying child security keys are divided into eight categories: Daily, Setup, Journals, Inquiries, Reports, Periodic, Miscellaneous and Tables. Each module in Microsoft Dynamics AX is broken down within these categories. The Security keys are laid out similar to the structure in the User Interface. Opening the main menu side-by-side with the security keys makes it easy to see how the categories relate to menu items.

• Daily — Contains the most accessed forms in the menu
• Setup — Corresponds with the Setup folder in the menu
• Journals — Corresponds with the Journals folder in the menu
• Inquiries — Corresponds with the Inquiries folder in the menu
• Reports — Corresponds with the Reports folder in the menu
• Periodic — Corresponds with the Periodic folder in the menu
• Miscellaneous — Controls access to all menu items used in the module that are not accessed from the menu. This is typically menu items accessed through buttons on forms. You do not have to change access in this category directly if you click Cascade.
  

  Note
  When you give access to a form, clicking Cascade updates all items with the same access related to that form.

• Tables — Lists all the tables used in that module. Clicking Cascade ensures that all tables are accessible for needed forms and reports.

See Best Practices for Configuration and Security Keys³ for more information about Security key and Menu relationships.

For each module, a set of nine security keys exists. They all have the same naming, and the prefixes denote the module. For the Accounts Receivable module, the security keys are:

• Cust
• CustDaily
• CustSetup
• CustJournals
• CustInquiries
• CustReports
• CustPeriodic
• CustMisc
• CustTables

Each menu item is present beneath one (and only one) security key. The access to the menu item ranges from No access to Full control.

 

Dynamics ax BI installation Trouble Shouting

(1) Installation of Enterprise portal component, gives the following
error:Error executing code: SysDevelopmentProxy (object) has no valid runable
code in method 'generate'.

a. Go to Ax Client ( on a machine where Business Connector is installed)

b. Open the AOT\Classes node

c. Right click on the SysDevelopmentProxy class node and select compile

and make sure it compiles correctly. Then run the EP deployment.

(2) I have successfully created the EP Site and I can view the site.
But other users are not able to view it.

a. Make sure the user is added to Ax and to the right AX user groups.

b. Make sure the user is configured as Employee or Customer or Vendor in User
Relations form in Ax k

c. Make sure the user is added in EP site using Site Settings

   i. Click on the “Site Actions” tab, and select “Site Settings”
from the drop down list

   ii. Click the “People and groups” link

   iii. Click the “New” button, in the “Add Users” page click the
“Add all authenticated users” and check all the permissions boxes to give all
configured users full rights

   iv. Click “OK”

(3) Role Centers are working fine in EP , but are not coming up in
Ax Client

a. Make Sure the "Web site used to dispaly Role Center in the Ax
Client " setting in Administration -> Setup -> Internet -> Web
Sites form at the bottom right is set to the right EP site

b. Navigate to the EP site mentioned in the above setting and verify none of
the web parts are throwing any error. If any web part is not rendering
correctly , either fix the source of the problem for that web part or remove
that web part

(4) After I added “Business Overview WebPart”, I tried to add some
indicators. It gave the error message “An error has occurred while
processing the business overview indicator. Check the web server application
event log for more information.” From Event Viewer:“An unexpected
error has occurred.The period is not valid......"

Did you initialize the profiles? You need to "Initialize Role
Center Profiles" from Basic->Setup->Role Center or Import Time Periods
from Administration -> Setup -> Business Analysis -> OlAP -> Time
Periods

(5) In Enterprise Portal setup BC Proxy
Account cannot be set if the FQDN is not a superset of the short domain name

In Enterprise Portal setup BC Proxy Account cannot be set if the
FQDN is not a superset of the short domain name

if the FQDN is different from the short domain name , for example

If the FQDN = XYZ.microsoft.com

and the short dominname = XYZCORP

then setting the BCProxy user during EP setup fails.

To workaround,

(1) change the app pool in IIS used by the EP Site to  to be run by the bc
proxy account with the FQDN specified.

(2) Also blank out the business connector proxy account in Ax.

(3) Then run EP setup and n the BC proxy user dialog , use the FQDN of the bc proxy.

(6)Manage Deployments dialog in Ax Client for Enterprise Portal may
not function correctly on 64 bit machine

Manage Deployments dialog in Ax Client for Enterprise Portal may not
function correctly on 64 bit machine

Administration->Setup -> Internet -> Enterprise Portal -> Manage
deployments on 64 bit machine may give

"Manage Deployment can not run because Enterprise Portal is not deployed
on this computer" even though Enterprise Portal is deployed and working
fine. Manage Deployment is used to update the Enterprise Portal web server with
the changed made in AOT web files and resources. To workaround this probelm,
use the alternate way of publishing these changes to the web server, which is
running Ax Setup and deploy EP without recreating the site.

(7) KPIs and Business Overviw keeps loading all the time and never
ends.

if all the Role Center content in enterprise portal are coming up except the
Business Overview webpart and it keeps displaying loading progress image
for long time with no error msg in the event log, it may be because IE
security setting is preventing the webpart from asynchronously getting the
data. To resolve this issue add the EP site to the intranet site zone in
IE or disable IE Enhanced Security Configuration from Add / Remove programs
-> Add / Remove Widnows Components.

 (8)
Report Deployment is giving below error

"The following components have not been installed or are not configured
correctly.

AL.exe

Microsoft Domain-specific Langugage Tools..."



You need to install VS 2008 or the VS 2008 Shell.

If you install VS 2008 that should be good enough. If you want to install the
minimal component required, then You can get VS Shell at

VS Shell - http://www.microsoft.com/downloads/d...displaylang=en

Windows SDK (contains AL.exe) - http://www.microsoft.com/downloads/d...displaylang=en





(9) Report Deployment gives CLRBridge Loader error.



The workaround for this problem is to copy the AxReports.exe from C:\Program
Files\Microsoft Dynamics AX\50\Reporting Services to C:\Program Files\Microsoft
Dynamics AX\50\Client\Bin

And run it from C:\Program Files\Microsoft Dynamics AX\50\Client\Bin





(10) "Home" button (Role Center) in Ax Client gives "An error
has occurred. Contact your administrator for further assistance."

·   
Check if Role Center site is set correctly at Administration ->
Setup -> Internet -> Enterprise Portal -> Web Sites at the bottom
dropdown.

·   
Check if the Role Center page comes up correctly in Enterprise
Portal in browser. If any of the webparts are throwing error, the page will
still come up in Enterprise Portal , but in AxClient it will give error for the
entire page. If there are any errors in the webpart, then either fix it or
remove it so that the page will render without any error. Once the page appears
without any error, then check it in AxClient.

(11) "Home" button (Role Center) in Ax Client is not appearing

·   
Check if Enterprise Portal is installed .

·   
Check if Role Center site is set correctly at Administration ->
Setup -> Internet -> Enterprise Portal -> Web Sites at the bottom
dropdown.

·   
Chekc if default Role Center page is set corectly at
Adminsitration -> Setup -> User Profiels at the bottom dropdown

(12) EP installation fails with below error msg



"Entering function Remove40WPPackage

Entering function Is40WPPackageInstalled

Microsoft Dynamics AX 4.0 Web Part package axwebparts.cab installation status
False

Leaving function Is40WPPackageInstalled

Leaving function Remove40WPPackage

Leaving function RemoveOldWebPartPackage

Could not load file or assembly 'Microsoft.Dynamics.AX.Fim.PaymentService,
Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of
its dependencies. The system cannot find the file specified."



The aboce error msg is misleading. If you go further down in the setup log file
you will see the SysDevelopmentProxy error . So to resolve this issue, you just
to recompile this class in a machine with .NET BC like issue (1)



(13) Update in Manage
Deployments or Generate Proxy gives No .NET Business Connector Session found error.



Some times , users open AxClient by click on a configuration file ( for example
, Test.axc). The Ax Client opens with configuration file, but when you generate
proxy or Update in Manage deployment , it uses the configuration defined for
Local Client in Configuration Utility. It does not take the configuration file
which is used to open the Ax Client. This is a bug. So to resolve, make sure
the Local Client confoguiration is set correctly in Ax Configuration Utility



(14)
EP Deployment is successful but when I try to navigate the site, I get 404
error



When EP Site is created,
it activates number of EP features and one of them registers the site with Ax (
adds an entry in WebSite table) and sets the master page. If the user that is
set as the Primary administrator account for the site during Site Creation does
not have access to Ax, this fails but site creation does not return error.
After the site is created, it gives 404 error.



So if you get 404 error, make sure EP is deployed correctly and then when
creating EP site , specify a valid AX user account as the administrator of the
site.



(15)When I create EP
site , it creates immediately and when I navigate it displays a team site



At the time of EP Site creation, if AOS is down or if .NET BC
Configuration specified in Configuration Utility is incorrect, EP Site creation
does not report error but creates the site. Since it's not able to connect to
AOS, it appears as a team site. To resolve this problem, make sure the .NET BC
configuration in Ax Configuration Utility is correct and is pointing to a valid
running AOS.



(16) After I installed
EP, the IIS Web site on which I installed EP appears to be in stop mode.



When an
IIS Web site is not yet extended with SharePoint and when you run EP setup on
this site, EP Setup extends the IIS Web site using SharePoint object model.
SharePoint actually creates a new IIS Website using the same port and extends
it and installs EP on it. The old site is stopped because it uses the same
port. SharePoint does it this way, later you have some other system installed
on the old site, you could just change the port and restart it.



So this is not an error. This is the behavior of SharePoint installation. When
you install SharePoint on existing IIS Web site, it creates a new IIS web site.

(17) SQL Server reporting services sp2 is not installed, I have
SQL Server 2005 Reporting Services installed and  Service Pack 2 was  installed also and still getting the error message

The same problem with SQL
Server 2005 SP3, this fix our problem:

Setup does not recognize that
SQL Server 2005 Service Pack 2 is installed When
installing the reporting extensions, you may receive an error message that
states that you must install SQL Server 2005 Service Pack 2. If you have
installed SQL Server 2005 Service Pack 2 and receive this error message,
complete the following steps. 1. Open the registry  (regedit command )and find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server key. 2. Right-click the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft
SQL Server key and choose New > Key. 3. Name the key Reporting Services. 4.
Right-click the Reporting Services key and choose New > String Value. 5. Name the string value Version. The Version string value will have a type of REG_SZ. 6. Double-click the Version string value and enter 9.00.3042.00 as the
value data. Click OK.

(18)Deployment failed unexpectedly with the message:Client found
response content type of 'text/html; charset=utf-8', but expected 'text/xml'.

Check if proxy account was
added to ax db users, and have access right on db. If it is not so add proxy
account to db users

(19) Deployment failedand when check Event viewer found the
following error

 Dynamics Adapter Logon failed.

Connection with the Application
Object Server could not be established.

Microsoft.Dynamics.BusinessConnectorNet.LogonFailedException

  
at Microsoft.Dynamics.BusinessConnectorNet.Axapta.Logon(BC_PROXY_ACCOUNT_INFO*
pBCProxyAccountInfo, String company, String language, String objectServer,
String configuration)

Solution:

1-   
Check
business connector configuration using client configuration utility

2-   
Change
the active client configuration utility to connect to the AOS as the
configuration of  business Connector

(20)“Deployment failed with the following exception:

System.Runtime.InteropServices.COMException (0x80040208)

  
at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32
errorCode, IntPtr errorInfo)

   at System.Management.ManagementObject.Initialize(Boolean
getObject)

   at System.Management.ManagementBaseObject.get_Properties()

   at System.Management.ManagementBaseObject.GetPropertyValue(String
propertyName)

   at
Microsoft.Dynamics.Framework.Deployment.Reports.SrsWmi.get_ConfigPath()

   at
Microsoft.Dynamics.Framework.Deployment.Reports.ReportLibraryDeployer.DeployBusinessLogicAssemblies(IEnumerable`1
businessLogicAssemblies, DeploymentLogger logger)

   at
Microsoft.Dynamics.Framework.Deployment.Reports.ReportLibraryDeployer.Deploy(IEnumerable`1
reportLibrariesToDeploy, IEnumerable`1 transitiveReferenceClosure,
IEnumerable`1 cultures, DeploymentLogger logger, Func`2
connectionStringModifier)”

Solution:

·        
You just need to
disable the UAC (User Account Control), or to run the Deployment tool with
right-click “Run as administrator”. As it says in the Dynamics
AX installation guide.

(21) Error during
processing of ‘AX_CompanyName’ report parameter.
(rsReportParameterProcessingError)





and furthermore in the Windows Application Event
log on the SQL Reporting server we get the following error logged: 



Dynamics Adapter LogonAs
failed. 



Microsoft.Dynamics.BusinessConnectorNet.NoIISRightsException 

at
Microsoft.Dynamics.BusinessConnectorNet.Axapta.Logon(BC_PROXY_ACCOUNT_INFO*
pBCProxyAccountInfo, String company, String language, String objectServer,
String configuration) 

at
Microsoft.Dynamics.BusinessConnectorNet.Axapta.LogonUsingBCProxyAccount(_SEC_WINNT_AUTH_IDENTITY_W*
pImpersonatedUserAccount, NetworkCredential bcProxyCredentials, String company,
String language, String objectServer, String configuration) 

at
Microsoft.Dynamics.BusinessConnectorNet.Axapta.LogonAs(String user, String
domain, NetworkCredential bcProxyCredentials, String company, String language,
String objectServer, String configuration) 

at Microsoft.Dynamics.Framework.BusinessConnector.Session.DynamicsAdapter.LogonAs(String
user, String domain, NetworkCredential bcProxyCredentials, String company,
String language, String objectServer, String configuration) 







Solution :

After further troubleshooting we identified that the user was not
licensed for the "Enterprise Portal Framework" module. SQL Reporting
extensions and integration uses the .NET Business Connector (BC.NET) and BC.NET
requires Enterprise Portal Framework license, even if you are not using Role
Centers and Enterpise Portal. When the business connector connects to the AOS
server if it does not find the license key, it throws the NoIISRightsException error
message as seen in the event log.