AD users can not log in to unix server neither via ssh nor from console. Some sample errors seen in log file are:
Oct 29 15:28:28 msp0tctap2 adclient: [ID 702911 auth.debug] DEBUG <fd:24 PAMVerifyPassword> base.aduser Error: get creds: Preauthentication failed for user joe.user@ACME.COM (enctype: AES-256 CTS mode with 96-bit SHA-1 HMAC)
Oct 29 15:28:28 msp0tctap2 adclient: [ID 702911 auth.debug] DEBUG <fd:24 PAMVerifyPassword> base.osutil Module=Base : bad password (reference base/aduser.cpp:789 rc: 1030)
Oct 29 15:28:28 msp0tctap2 adclient: [ID 702911 auth.debug] DEBUG <fd:24 PAMVerifyPassword> daemon.ipcclient validate password caught exception: bad password
Couple of factors could lead to login problems when domain/forest is raised to 2008. Below is detailed information on both, please follow the necessary steps based on your environment. In a few scenarios, you need apply steps from both sections.
1) AD 2008 introduces AES encryption type. The kerberos encryption type handshake happens between adclient and Active Directory during adclient startup. If adclient was earlier talking to AD 2003 which does not know about AES, it establishes and uses ARCFOUR encryption type. Now in the middle of adclient running, if DC's are raised to the function level 2008 which start sending AES encryption type, adclient will not be able to recognize the enc type unless adclient is recycled. When you recycle the Centrify agents, encryption type is renegotiated with 2008 DC which understand AES, Centrify agents put AES in its accepted encryption type.
2) Some encryption technologies such as DES and AES require salt as part of their crypto functions. For users in Windows AD, by convention this salt is derived from the user principal name. For example, if a user is known as joe.user@ACME.COM, the salt will be ACME.COMjoe.user
Some encryption technologies, in particular RC4 HMAC - the default encryption technology for Windows 2003 domain do not use salt, so in these environments salt is a non-issue.
However Windows 2008 domains want to use AES encryption by default.
There is a known bug in DirectControl 4.4.2 and earlier version where the salt is miscalculated, because adclient tries to use the DirectControl zone-assigned Unix Name to calculate salt. In some environments this would not be noticed because the UnixName = sAMAccountName = the first part of the user Principal Name.
But in some cases where the convention is that only the first name is used for the Unix name, i.e. "joe.user" becomes joe. Then we miscalculate the salt as ACME.COMjoe instead of the correct ACME.COMjoe.user.
Apply these steps:
- Log in as root
- Open /etc/centrifydc/centrifydc.conf
- Insert "adclient.force.salt.lookup: true" and save the change
- Run adreload to force the Centrify DirectControl Agent (adclient) to reload new configuration changes
Setting the centrifydc.conf parameter adclient.force.salt.lookup: true forces Direct Control to stop trying to guess the salt and ask the Windows DC what it is. This incurs an extra packet exchange as part of the original user authentication. The extra exchange is generally pretty fast and will not be noticeable by a normal user interactive logon. It only becomes an issue for performance critical, heavily loaded programmatic logon situations.
Note: If the above steps do not work, please restart CentrifyDC from /etc/init.d.
Starting DirectControl 4.4.2 the configuration parameter adclient.force.salt.lookup is set to true by default.
Note: This KB holds good for Centrify 5.0.x as well. We fixed salt parameter but restart is needed.