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 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:
It will work fine.
Designing the structure of the groups and roles is very project dependent. What was working for us is: