Applies to: All versions of Centrify DirectContol 5.1.2 or below
Problem:
When auto.schema.allow.groups is enabled, running groups <ad_user> will not return the AD group membership for the user consistently.
Steps to reproduce:
[root@machine ~]# groups test_user : test_user group_one <---returns AD group, working normally
[root@machine ~]# adflush -f
DNS cache flushed successfully
GC and DC caches flushed successfully
[root@machine ~]# adreload
[root@machine ~]# groups test_user : test_user <---does not return AD group after the flush and reload without running adquery group
[root@machine ~]# adflush -f
DNS cache flushed successfully.
GC and DC caches flushed successfully.
[root@machine ~]# adreload
[root@machine ~]# adquery group group_three:x:123456789:group_four,group_five,backupgroup_two:x:222222222:group_six,group_seven,group_eight,group_one:x:33333333:group_nine,test_user
[root@machine ~]# groups test_user : test_user group_one <---returns AD group only after running another flush reload
These are the lines added to centrifydc.conf:
auto.schema.groups: group_one, group_two, group_three
auto.schema.allow.groups: group_one, group_two, group_three
pam.allow.groups: group_one, group_two, group_three
Cause:
When auto.schema.allow.groups is configured, adclient will:
1) Fetch the group member from AD without extending the group object, so the UNIX profile (GID/Group UNIX name) is not generated.
2) When a user runs groups <UNIX username>, this would trigger an optimized code path by calling IPCClient::getUserGroupsByUser(), which gets the group object based on the extension objects using AutoSchema::getExtensionObjects()
Since the object from the cache does not contain required UNIX attributes, the object is ignored, and is not considered a valid UNIX group.
Workaround:
Run the following in sequence:
adflush -f
adquery group
(adquery group must be run right after adflush -f)
This will force the group to be properly extended first.
Resolution:
This has been fixed in Centrify Suite 2013.3 (5.1.3).