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-0604: ypmatch returns "!" in the password field for user accounts instead of password hash

Centrify DirectControl ,  

12 April,16 at 10:57 AM

Applies to: All versions of Centrify DirectControl, adnisd on all Unix platforms 
 
Problem: 
 
When Centrify adnisd is being used for NIS password sync, user accounts have "!" in the password field instead of the password hash:
 
ypmatch sumana passwd 
sumana:!:24745:25:nis_sumana:/user/sumana:/bin/bash 
 
"!" in the password field in turn prevents unixUserPassword to be read from Active Directory.
 
Reason: 
 
Under Windows 2003 R2, the password hash of the user’s Active Directory password is stored in a new attribute, unixUserPassword
 
Microsoft’s Active Directory security permissions by default prevents anyone from reading this value. 
 
This can be verified by running the following ldapsearch command on the Unix server where adnisd is installed as root: 
 
/usr/share/centrifydc/bin/ldapsearch -H "ldap://" -m -LLL -b "dc=mydomain,dc=com" "(cn=sumana)" canonicalname altpasswordhash mssfu30password unixuserpassword 
 
Note: In the above command, replace the searchbase "dc=mydomain,dc=com" and username (cn=sumana) as appropriate. 
 
Solution: 
 
Allow the servers running adnisd to read this value. unixUserPassword is part of a set of attributes on the User Security ACL named "All Extended Rights".
 
This has to be applied to all containers and organizational units which contain Active Directory User objects:
  1. Create a new AD group object in an appropriate container or OU.
    (For example, an AD group named "NIS Servers" could be placed in "OU=Unix Computers,DC=mydomain,DC=com".)
     
  2. Add the servers running adnisd into this group
     
  3. For each organizational unit or container which contains AD User objects:
    • Right-click the object and select "Properties" > Security tab > "Advanced" > "Add"
    • Type the name of the new AD group and press "Check Names" > "OK"
    • On the "Apply onto" drop-down, select "User Objects", next to "All Extended Rights", check the "Allow" checkbox
    • Press OK several times 

      Note: This must be performed for each OU or container with User objects. 

      Note: If the user above is a privileged account (i.e. Domain Admin user which is set up to "inherit from parent"), the configuration may work only for few minutes/hours. The checkbox may become unchecked and all ACL's deleted. 
       
      From Microsoft: 
      1. This is a security feature in post Windows 2000 SP4 (mainly in Windows 2003) 
      2. Protected groups members will not inherit from parent's security permissions to prevent unauthorized modification of privilege accounts 
      3. This process happens once per hour 
      4. It is controlled by the adminSDHolder container 

        The fix for this is described in the Microsoft KB article 817433 : 
        http://support.microsoft.com/kb/817433 
  4. Restart adclient and adnisd

    As AD permissions have changed, adclient and adnisd needs to be restarted on all servers running adnisd:
    1. Flush the cache: adflush
    2. Stop adnisd: /etc/init.d/adnisd stop
    3. Start adclient: /etc/init.d/adclient restart 
    4. Start adnisd: /etc/init.d/adnisd start -f 
       
  5. Run the ldapsearch command again to see if unixUserPassword now comes back with the password hash.
    Once it returns the expected password hash, ypmatch for the user should also return the password hash. 
 
Additional notes: 
  • The "Password Synchronization" service must be enabled on ALL domain controllers in a domain. 
     
  • After installation, the Encryption/Decryption key must be reset from the default value in order to enable synchronization. This key is not used by DirectControl and need not be remembered. 
     
  • If "Identity Management for UNIX" or "Services for Unix (SFU)" are just installed then a password change must be forced on the users so that their passwords are written to the unixUserPassword attribute and thus become available to the Centrify NIS Gateway. This can be done with the “Reset Password” in ADUC. 
    Check in the Event Viewer for a record of the password changes, afterwards check with ADSI Edit that the unixUserPassword attributes now has a value for the users. 

     
  • If the Windows 2003 server running SFU has been upgraded to Windows 2003 R2 and values exist in both mssfu30password and unixUserPassword attributes then R2 attribute "unixUserPassword" takes precedence.
     
  • If running Windows 2008 R2 then the fix for this is described in the Microsoft KB Article 817433: http://support.microsoft.com/kb/817433

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