…and then you find yourself responsible for setting up a security and authorization policy in AX, or worse, you inherit somebody else’s twisted logic.
Up to version 6, Dynamics AX has always been lacking a solid authorization framework. In 2012 Redmond decided to make up for this, and boy did they make up. They didn’t just come up with a security system that actually works, they made it so that even the brightest minds will have a hard time coming up with a working solution that will satisfy all parties involved.
Badges? Badges? We don’t need no stinking badges!

No, you don’t need badges. Single sign on says all you need is an active directory account and a valid password. That will get you in AX, but it will get you nowhere without a role to play. So who requires authorization?
Users
First and foremost, a good authorization system will benefit your users. AX is big, bad and complicated. By shielding your users from stuff they don’t need, it becomes many times more user friendly. Your users may even become more friendly towards you.
Don’t look at it as restricting users. Although there are certain no-go areas in the system, I do believe that a good hiring policy and proper training are much more effective than restrictive ERP systems. However, limiting a user’s privileges to areas that are actually used in his role helps to lay out the boundaries of a user’s functional process.
Auditors
Auditors don’t just want authorization (for users), they demand it. Segregation of duties, eyes only, SarbOx, you name it. Users should have appropriate clearance for any area of your system and if not, they have no business there. Furthermore it is important to have some kind of traceability. Who did what when and why? And that includes you and your nerd friends on the fourth floor, Brother Technicolor.
The Law
In some cases, and in countries with a legislation that has evolved past the one from Transdniestria, you are actually required by law to restrict access to certain system areas. Think privacy sensitive data in HR or financial data in GL. Take a little time to investigate the requirements in your neck of the woods or in the woods that you control. Better yet, convince your CEO to have the company legal councilor spend some quality time on the subject.
Your boss
So bosses and/or customers come up with some crazy shit and it’s not always easy to disagree.
Example from the past: “Sales reps are only allowed to see customers form their own district. We don’t want them running off to the competition with our entire customer database!”
Sure, but, but..
So I built it.
You
No you don’t. Life is easier without having to worry about who is allowed to do what or people nagging about missing privileges. If you can get away with setting up a system without security, I say go for it. But if you don’t (or won’t), you do it right off the bat. The longer you postpone, the harder it will be.
You again
As long as you’re at it, ask yourself if you really need that administrator privilege for everything you do all the time.
Back in the days when ERP systems ran exclusively on UNIX systems and were administered from a console (the way the Lord intended it), I routinely logged myself out with the kill -a command (which kills any and all processes running under your account). Unfortunately I also got in the habit to routinely log in as root. Inevitably came the day when I killed all my processes as root and I slowly watched the system die while waiting for the phones to ring.
In other words, damage control. Limit yourself to what you really need on a daily basis. It only takes a minute to grant yourself sysadmin rights when needed.
Three Basic rules
1. Keep it in proportion.
Unless you are guarding the Coca Cola formula, the gold reserve of Pharrell Williams or the memoires of Dick Cheney, your security should be to scale.
2. Keep it simple.
Or at least as simple as possible. Remember, you are the one who has to maintain this crap and you are not going to want to do that for ever so the next guy should be able to understand it as well.
Keep it as simple as possible (but not simpler than that).
3. Don’t be a villain.
(gotta keep chillin’). The sense of absolute power can easily go to your head. Users will have to come beg and crawl for you to grant them access to sessions that they require to perform their daily tasks. Bribes have never smelt so sweet (I will do almost anything for home-made cookies) and who knows how far the new girl in Accounts Payable will go to see all vendor invoices? But perhaps it is better for your karma to not be too restrictive.
To be continued…
One thought on “Security roles and authorization in Dynamics AX (Part 1)”