Centrify

Tips for finding Knowledge Articles

  • - Enter just a few key words related to your question or problem
  • - Add Key words to refine your search as necessary
  • - Do not use punctuation
  • - Search is not case sensitive
  • - Avoid non-descriptive filler words like "how", "the", "what", etc.
  • - If you do not find what you are looking for the first time,reduce the number of key words you enter and try searching again.
  • - Minimum supported Internet Explorer version is IE9
Home  >
article

KB-3210: Improper group memberships with auto.schema.allow.groups enabled

Centrify Identity Service, Mac Edition ,  

12 April,16 at 11:11 AM

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).

Still have questions? Click here to log a technical support case, or collaborate with your peers in Centrify's Online Community.

Related Articles

 articleKB-3925: How to add Centrify parameter to a group policy articleKB-2045: sudo hangs in autozone and adclient takes high CPU on RHEL/CentOS 6.4 servers articleKB-5533: Samba intermittently not recognizing all AD group memberships articleKB-2119: The impact of winbindd on Centrify Enabled Samba articleKB-6056: How to report the group policy settings that are in effect for the local computer? articleKB-6073: How to join the Linux/Unix Centrify Server to Active Directory with specific Computer Role? articleKB-1797: Secondary Group membership not resolving across Forest in 1-way trust. articleKB-6041: How to show current license type in use by adclient? articleKB-2090: "adquery group" command does not return primary group members