I've discovered an issue with the use of AD Security Groups within AX 2012 R2 (CU9).
Our customer is currently using active directory groups in AX to allow access to it's users.
Because we need a more refined way to define security, we no longer use the ad groups.
So I set the 'enabled' on all these groups to 'false'. Amazingly enough this has no effect at all.
Just to be sure I tried this in a vanilla environment.
Added an AD Group 'Domain Users' and assigned the role 'System Administrator".
Then disabled the AD Group in AX, so you would expect that nobody can access AX except me.
Well, this isn't the case. Any domain user that logs on to the vanilla box has 'System Admin' rights even with the AD group disabled.
So I'm wondering, is this a know issue or am I doing something wrong here?
Couldn't find anything on the net about this ...
I have not actually checked if there is a source code behind the import logic or if it is in the kernel, but just disabling it probably has no effect as you have observed, the logic in AX might be just checking if there are any AD groups created.
Did you try removing the AD group from AX? Already deployed users would remain, but there would be no newly associated users. Wouldn't that resolve your issue? Check this in Dev/Test first.
Deleting the active directory groups does solve the issue, but that is a bit besides the point no?
Why have the field 'enabled' visible on Active Directory Groups if you disabling it won't make any difference.
Occam's razor suggests that they did not bother implementing to disable the field on all the forms where users and groups could be edited in case of an AD group.
It's clearly mentioned in the help file (that's where a developer never looks), that the active/inactive field doesn't make any difference in an Active Directory Group record. They are always active. So that explains why ...
Business Applications communities