Ax 2012 has an interesting feature for user management. Instead of importing the users one by one and administering in the AX environment you can simply create a user for the Active Directory  group in the AX. The system will automatically create an AX user  for every member of the group when (s)he tries to access the system. This is a dynamic process, the user rights will be adjusted according to the current group membership at each logon. If a user is added to or removed from an AD group the changes will be applied the next logon.

If the user who is logged on once is removed from every AD group that has access to the system, we will get a little unintuitive result. The system will not delete the user from the database (good so far), but the user will not be in any role in the system, not even in the default System User role. So (s)he will be able to log on, but nothing will work:

This is the User screen of an auto imported user (watch the user ID)

And this is, what the user sees from the system once removed from every user group:

This process has quite a few advantages.

  • The main being, that this process takes the burden of user management form the administrators of the AX system. Instead of having to manage hundreds of users they will have to manage a relatively few groups, and management usually means only creating the group and assign the role membership  to the groups.
  • It will also increase the security of the system, as every functions that related to the authentication (who you are) are managed in their natural place the AD. Ax has only take care of the authorization (OK, given who you are, what are you allowed to do) related to the AX system.
  • In enterprises it is quite common to have a central user rights management system, usually connected to the HR system. The majority of these systems handle AD groups, but I have not heard one that has an agent handling AX.

 

The only disadvantage of this is, that the users automatically created by the system will have an id starting with $, see above. The other fields like user name and alias are created correctly. 

Because AX seems to be tracking the version of the AD object and modify the user effective roles only if it detects a change there is an interesting side effect you should be aware of (tested it on 2012 CU3). Suppose you have an existing user in the AX and the AD (i.e. the user already logged on to AX). You create a group in the AD and add the user to the group. If you create a user from the AD group in the AX and assigns the roles to it, the user will not get the permissions from the role. What you should do instead is:

  • Create the AD group empty
  • Add the group to the AX
  • Put the member to the group after the AX user is already created.

It will work fine.

Designing the structure of the groups and roles is very project dependent. What was working for us is:

  • Create a group that will contain all the users of the AX system. Create the AX user for the group, only the default System User role should be assigned to it.
  • Create an AD group and the corresponding AX user per role.
  • And let the AD admins administer your group membership.

 Illés