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-2255: On an AIX machine, users whose primary group is "staff" are not able to login after doing the adjoin

Authentication Service ,  

12 April,16 at 11:08 AM

Applies to: All versions of Centrify DirectControl on AIX platforms

Problem:
After joining the machine to the domain, users are not able to login to the AIX server. 

These users have an Active Directory (AD) account and  local account with same name, uid, gid etc. 
Their primary group is 'staff' (gid:1). The group 'staff' is not zone enabled i.e, there is no Unix group in Active Directory called 'staff'. 

When the local account is mapped to an AD account, it works fine. When clearing a handful of users out of the group "staff", the logins then work as expected. 

It appears that Centrify has a limitation on the number of users that can be part of a primary group. Is there a way to fix this limitation?

Symptom  #1:
When trying to login via SSH , the user in question get the error as :
Server unexpectedly closed network connection

Symptom #2:
When doing su - <username>, the user get the error as:
3004-503 Cannot set process credentials
 
Cause:
The problem is user's primary group is staff (gid:1). This group has to be visible from AD, but by default it is ignored. If it is not ignored, Centrify will get 2 entries of 'staff'; one from AD and one from local. The application may not be able to handle this. So, adclient can be told to merge the local users into the AD group (staff) so that all users (Active Directory and local) are now visible.

Workaround:
1. In Active Directory create a matching group 'staff' with gid=1.
2. Add the user having the issue to the AD 'staff' group .
3. In the /etc/centrifydc/group.ignore file, make sure the group 'staff' in NOT there.
 4. In the /etc/centrifydc/centrifydc.conf file, uncomment and set the value for the parameter adclient.local.group.merge as:
adclient.local.group.merge: true
5. Changes to /etc/centrifydc/centrifydc.conf  will require running the command adreload for the changes to take effect and clearing cache:
# adreload
# adflush

Now test the login for the user having the issue.

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-6041: How to show current license type in use by adclient articleKB-6040: How to change the license type in use after adclient successful joined to the AD? 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-6038: How to specify the license type to use when joining the server to AD using adjoin? articleKB-7555: Unable to login as root after upgrade to Centrify Suite 2016 (CDC 5.3.0) articleKB-6044: How to configure users for automatic Kerberos Credentials for infinite renewal even after users have logged out? articleKB-6050: How to configure a group for automatic Kerberos Credentials for infinite renewal?