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-2045: sudo hangs in autozone and adclient takes high CPU on RHEL/CentOS 6.4 servers

Centrify DirectControl ,  

12 April,16 at 11:08 AM

Applies to: All versions of Centrify DirectControl/DirectExpress on RHEL 6.4/CentOS 6.4 platforms

Question:
It is observed that on a bunch of RHEL 6.4 servers running DirectControl/DirectExpress and joined to Auto Zone, any AD user who tries to issue a sudo command experiences a lag of about 2+ minutes and Centrify's adclient takes up about 30-70% of CPU time. This is before the sudu password prompt. 

Is there any reason for this?

Answer:
On a RHEL 6.4 server, typing the command below will provide the version of sudoers. Run the same command on a RHEL 6.3 server (where this issue was not noticed) to see if the version has changed.

[root@rhel63 etc]# sudo -V |more
Sudo version 1.7.4p5

The issue is a delay in obtaining and enumerating all of the AD groups.  The reason why the delay is not seen a second time is because Centrify has cached the data locally, but after a couple of hours, the cache is invalidated and the client goes back to AD to retrieve the group membership information again, therefore causing the delay.

Based on logs provided, sudo is asking for a group with all members to decide if the user is allowed to do things. Unfortunately Centrify has no control over what sudo does and asks. When it calls getgrgid, the system is obliged to locate and return the group with all the members, thus causing the slowness.

On Centrify DirectExpress version 5.1 only, (adinfo -v will provide version information), there is a mechanism to limit the scope of users/groups, which should allow things to run significantly faster, but the users/groups that should be in the scope need to be identified.

Steps to be followed on the Centrify server experiencing the slowness issue (as root):

1) Backup /etc/centrifydc/centrifydc.conf as always by running:

cp /etc/centrifydc/centrifydc.conf /etc/centrifydc/centrifydc.conf.ori

2) Changes to /etc/centrifydc/centrifydc.conf will require the issuance of the adreload command or a restart of the Centrify agent.

Optionally, the adflush -f command can be run after enabling these parameters to verify if it works or not. This command flushes the cache and so everything has to be retrieved again from AD.

3) There are 3 parameters involved here. The first 2 parameters (auto.schema.allow.users and auto.schema.allow.groups determine the login criteria (either a user defined list or a group list) while the third parameter (auto.schema.groups) restricts the search criteria to the specific AD groups defined in the /etc/centrifydc/centrifydc.conf. Servers experiencing slowness issues with the sudo command (for example) should use this parameter. 

Note:
The pam.allow.group can still be used, which is really a subset of the above parameters.

a) auto.schema.allow.users: Users who are allowed in this Auto Zone.

This configuration parameter specifies which Active Directory users to include in the Auto Zone.

The command syntax is:

auto.schema.allow.users: name [, name, name, ...]

By default - all Active Directory users are included in the Auto zone.

When a user or users are specified in this parameter, only the users specified and members of the groups specified in auto.schema.allow.groups are able to LOG IN in using their Active Directory account.

Specify users by name or list the user names in a file. The user name can be specified in any of the following formats:

i) SAM account name: sAMAccountName@domain (Specify the domain if the account is not in the current domain)

ii) User Principal Name: name@domain

iii) NTLM: DOMAIN/sAMAccountName

Examples:
auto.schema.allow.users: jane
auto.schema.allow.users: joe@domain.com
auto.schema.allow.users: NTDOM\henry

Multiple names can be specified in a single command. Separate each name by a comma and use escape characters to include, for example, spaces, backslashes, or a comma in the name specification:

auto.schema.allow.users: joe, janedoe, \
user1, user2@domain.com, domain\\user3, domain+user4, \
domain/user5, CN=user6\,CN=Users\,DC=domain\,DC=com, \
domain/Users/user7

A file can also be used instead. The syntax is file:/path, for example:

auto.schema.allow.users: file:/etc/centrifydc/auto_user_users.allow


In the file, enter each name line by line. However, escape characters are not needed:

joe
janedoe
user1
user2@domain.com
domain\user3
domain+user4
domain/user5
CN=user6,CN=Users,DC=domain,DC=com
domain/Users/user7

b)  auto.schema.allow.groups: Users who are members of the groups specified in here are allowed in this Auto Zone.

This configuration parameter specifies which Active Directory users to include in the Auto Zone using group membership as the criteria.

The command syntax is:

auto.schema.allow.groups: groupname [, groupname, groupname, ...]

When specifying a group or groups in this parameter, only the users who are members of the groups specified, including members of nested groups and users whose primary group is set to one of the groups specified, and all users specified in auto.schema.allow.users are able to LOG IN  using their Active Directory account

Any groups listed under auto.schema.allow.groups can be domain local, global or universal groups. They must be security groups; distribution groups are not supported.

 

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

Related Articles

No related Articles