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-2581: Adclient crashes/login slow for a migrated cross-domain user

Centrify Identity Service, Mac Edition ,  

12 April,16 at 11:07 AM

Applies to: All versions of Centrify DirectControl. 
 
Question:
 
Centrify adclient goes into "down" mode/status when user attempts to login. 
A crash happens and a core file is generated as well. The logon can also be extremely slow too. 

Is there any reason for this?

A given Centrify server is joined to "classic zone" and not in hierarchical zone. 
The parameter below was set in /etc/centrifydc/centrifydc.conf and then "adreload" ran but had no difference to the outcome. 

dz.enabled: false
(This parameter bypasses all the unnecessary processing for DZ)
 
An example of the slowness:
 
user@machineA:$ date -u;time ssh cclnx65.yourcompany.com date -u
Mon Jul 2 13:53:56 UTC 2012
 
Mon Jul 2 14:04:02 UTC 2012
 
real 10m5.806s
user 0m0.012s
sys 0m0.006s

Answer:
 
Under normal circumstances, Centrify's adclient will never go into down mode/status. 

In the example above, the slow down is related to the crash. A thread went into an infinite loop leading to a system crash when that thread stack overflowed. This is not a simple software problem as the code will not crash under most situations. 

What happened was the user's attributes somehow became corrupted - When the system tries to find the groups that the user is a member of (a group with a specific SID), the associated SID is not found. Looking this up in sidHistory points back at itself and results in the infinite loop - This should not have happened. The group is likely a foreign security principal and later when the user is migrated from one domain to another, the foreign security is left as member of that foreign group and that SID does not exist any more, but the value remains in the sidHistory of the migrated user.
 
This is an AD problem and at the time of writing this KB, Centrify has opened a case with Microsoft. Since this is a deeply rooted issue, a workaround is being developed for the next major release of Centrify (CDC 5.1).
 
The AD problem is this:
 
After a user is migrated from one domain to another, the attributes related to tokenGroups returns a list of SID's which are groups (of different favors) that the user is a member of. These lists now contain the old SID of the user (which is also in the user's sidHistory). This property is unexpected and creates the loop in our group processing code.
 
Please contact Centrify Support for a special build which works around Microsoft's bug.

Update: This problem exists in 5.0.4. The 5.0.2 one-off (build 409) came out after 5.0.4 which is 5.0.2 GA + RedHat smartcard support. Unless customers requires RedHat smartcard support, they can back it off and install the 5.0.2 one-off, or get 5.1.0 (which is a feature release with more changes).

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