AxUtil and the application log

hi there,

During the set up some 2012 environments lately, we got warnings like

An error occured in writing to the event log on machine <DBServer>: cannot open log for source 'Microsoft Dynamics AX - AXUtil. You may not have write access.

when we're using the axUtil or perform actions where the axUtil tool is used behind the scenes.

It seems the problem occurs when the account running the AOS instance does not have sufficient privileges on the database server hosting the AX database.

You can go all wild add the AOS service account to the administrators group on the DB server. Or you can handle it more suble by just granting that AOS service account write access to the application log.

Windows comes with a nifty tools (called 'wevtutil') to regulate this. You can read all about it here.
What we did to solve the issue is:
- open an elevated command prompt on the DB server
- run 'wevtutil gl appication > c:\temp\out.txt', which will give you a textfile containing the security settings for the application log
- from that texfile, you copy the (seemingly uncomprehensable, but all part of MS's security descriptor definition language (SDDL)) expression that's after the 'channelAccess: ' keyword. This is the string that actually defines who has (or hasn't) access to the application log
- now you need to make sure the AOS service account is added to that string. I took the easy way and gave all 'authenticated users' the 'file write' permission by adding '(A;;FW;;;AU)'.
- the last step is to send that modification back into the system using the 'sl /ca' option on the wevtutil command: 'wevtutil sl Application /ca:<the modified channelAccess string>'

I got my inspiration on 'The Raven Report' blog, so it's only fair to mention that.

bye

DAXCONF - Role-based security (RBS) and eXtensible Data Security (XDS)

I just attended 3 sessions on the new security framework in Ax. The content is just too much for one post. I'll give the highlights:

RBS (role based security)
- The new security framework is based on:
  - Roles: a group of duties specific to a function (accountant, mechanic, clerck, manager, …)
  -  Duties: a group of related privileges needed for a specific task (sales order entry, approve expenses, order picking, …)
  -  Privileges: a group of entry points (mostly menu items) needed for a specific action (create sales order lines, set up HRM parameters, start a pickingroute, …)
  -  Permissions: a group of base objects  each with the required level of access (update salesTable, update HRMParameters, …)

- Developers are responsible to provide the appropriate privileges and permissions
- An administrator can define roles and duties based on the privileges and permissions -and link uto roles

- Standard out-of-the box all roles, duties, privileges and permissions are available to secure all functionallity in Ax2012! Impressive: previous versions had … no out-of-the-box security configured.

Some other facts:
- SecurityKeys are no longer used
- Companies are replaced by legal entities
- Domains are replaced by organisations
- Users groups not longer used in a security context
- External users (without an AD-account!) now can log on to the EP (using # ways of user authentication  in SharePoint 2010)

XDS (eXtended Data Security)
- In previous versions there was RLS (record level security), where you couldn't do much more than restricting the selected data by adding a where clause to tables
- Ax2012 takes RLS to the next level: it's called the XDS framework
  - the combination of an application context (form, menu item, ...) and a role context (user, role, ...)
  - is applied to a policy (based on queries, so more flexible compared to RLS, also the meta data is used to apply data security on linked tables)
  -  this policy filters the data as configured

In an example this would be: if you define a query on the salesTable, but a policy defines you can only see customers from a specific group ('x'), you will only see the salesTable records for customers of group 'x' … even if your select looked like 'select from salesTable', it would become something like 'select from salesTable where exits (select from custTable where custTable.PK = salesTable.FK and custTable.group = 'x')'. Applying multiple policies, would add extra 'exists' clauses to the query.

- Ax2012 comes predefined with 11 policies (3 enabled by default)

- This sounds like a performance killer ... well there's a solution (as with most potential performance issues in ax2012). Policies that result in complex queries including multiple joins can be cached in temp tables that will be populated the first time the complex policy-query is executed. The next time this complex query is executed ... it is not ... the results from the temp table are used in the query rather than executing the complex query over and over again. This is called a 'myConstruct' and the refreshrate is customizable (on each execution, per session, ...). Ax2012 comes with 7 myConstruct tables out-of-the-box.

- A super-duper feature for developers is the possibility to get the actual SQL statemets (policies applied) from within X++.

The goal of this new security framework is
- Faster implementation
- Role-tailored user experience
- Comprehensive data security

I'm impressed!

datawarehousing tips

hi,

If you're implementing Ax and need to assist the guys in charge of the datawarehouse/BI, here are some tips:

- do insist on setting up a separate datawarehouse/BI database. "But the data needed for the DW is not that much, the queries are simple and not blocking, they will not obstruct the live Ax DB in any way." Uhu, and then on an unpleasant day it is blocking and obstructing. Don't give in to this temptation. Keep it clean and simple: the Ax and any other DB need to be separated DB's.

- since Ax 5.0 and the UTCDateTime datatype, the date/time you see in Ax is not necessarily the date/time stored in the DB. The Ax kernel handles the timezone offset on forms and reports (not in code!). If the datawarehouse is to produce reports, do take the timezones into consideration (for instance if totals are calculated per day: end of day may very well be 10PM in the DB, depending on the timezone)

- if tables are shared in virtual companies, the Ax kernel handles this automatically. In the DB on the other hand it's a hell of a job to link the correct dataAreaId's. This job gives an overview of which table is included in which table collection as a result the translation dataAreaId to virtual dataAreaId.

- security: Ax handles a lot of security (RLS, AOS aothorisation, user group permission, ...). This is (if you don't anticipate) not the case if the data from the Ax DB is transferred (on DB level) to a reporting/DB/BI database. Make sure sensitive/confidential information is not made public in that way.