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-5717: Padlock of system preference can be unlocked with any random password when CN of AD user matches with local admin account

Centrify Identity Service, Mac Edition ,  

12 April,16 at 10:59 AM

Applies to: Centrify DirectControl 5.2.3 on Mac OS X

Problem:

When Common Name (CN) of an Active Directory (AD) user matches with local admin account's name, padlock of system preference can be unlocked by just entering the local admin account's name as the username and <
ANYTHING> as the password.


Cause:

 
Given that an AD user with CN that equals "A" and sAMAccountName that equals "B" is logged into a Mac that has a local admin user whose name is also "B":

a) User "A" tries to unlock a System Preference padlock

b) OS X first sees that there is no local user "A" and so passes the authentication to Centrify agent

 
c) Agent does a lookup for any user with username "A", however, local user "B" is returned:

 
(This is because although the agent does do user lookups by CN, it will always use the sAMAccountName as the unixname. So in this instance where the sAMAccountName of the AD user matches a local account; the local account record will picked up first.)

 
d) The agent at this point will check to see if there is a local account conflict before moving onto authentication

 
e) It sees that user "B" is a local account (which has priority), and so thinks there is a conflict and skips the authentication and passes back to local system to handle the authentication. 

 
f) However, local system only saw user "A", which it had already skipped over and so thinks the Centrify agent has completed the authentication and proceeds with the padlock unlock.


NOTE: This issue affects unlocking of the padlock in System Preferences. Terminal logins (like SSH) or user login at the GUI login screen are not affected by this issue.

 
Workaround:

1) 

Add local admin account into
/etc/centrifydc/user.ignore file, then run command "adreload".

 
The group policy for this setting is located at:
Computer Configuration / Centrify Settings / DirectControl Settings / Login
Settings / "Specify user names to ignore (lookup)"

OR

2)

Edit the
/etc/centrifydc/centrifydc.conf file and configure the following lines:

adclient.user.lookup.cn: false
adclient.user.lookup.display: false


Run commands "adreload" followed by "adflush -f".

 
The group policy settings for the above parameters are located at:
Computer Configuration / Centrify Settings / DirectControl Settings / Network and Cache Settings / "Enable user lookup and login by CN"

 
Computer Configuration / Centrify Settings / DirectControl Settings / Network and Cache Settings / "Enable user lookup and login by displayName"


(Note that this workaround will disable login by CN/DisplayName all around. The normal login by unixName and samAccountName are not affected.)


Resolution:

This issue has been fixed in Suite 2016 (Centrify DirectControl 5.3.0).

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