Unable to update LDAP user password
 

Centos 5.7, using LDAP as authentication.

The LDAP server is not local.

One of my admins continuously gets this message at login:

"You are required to change your password immediately (password aged)".

She attempts to change the password, which the system accepts... Then tries to log in with the new password, and again gets the "You are required to change your password immediately (password aged)" message. This will continue on in an endless loop...

Here is the LDIF of her account (scrubbed, of course):

dn: uid=annieo@domain.com,ou=domain,o=org
uid: annieo@domain.com
cn: annie
sn: o
mail: annieo@domain.com
uidNumber: 640
homeDirectory: /cust/org/users/annieo
gecos: Annie O,,
objectClass: inetorgperson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: mirapointmailuser
objectClass: sambaSAMAccount
loginShell: /bin/bash
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
sambaSID: S-1-5-21-...
sambaHomeDrive: F:
sambaHomePath: \\fs\cust\domain\users
gidNumber: 500
sambaPrimaryGroupSID: S-1-5-21-...
sambaLMPassword: B064...
sambaAcctFlags: [U]
sambaNTPassword: D0D5421...
sambaPwdLastSet: 1344533053
sambaPwdMustChange: 1348421053
shadowLastChange: 15561
shadowMax: 45
userPassword: {SSHA}KQnCbUN...
shadowExpire: -1

The pertinent entries from the /var/log/secure file:

Oct 1 16:16:21 web-1 sshd[3643]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mainoffice.domain.com user=annieo@domain.com
Oct 1 16:16:21 web-1 sshd[3643]: pam_unix(sshd:account): expired password for user annieo@domain.com (password aged)
Oct 1 16:16:21 web-1 sshd[3643]: Accepted password for annieo@domain.com from 192.168.1.5 port 24623 ssh2
Oct 1 16:16:21 web-1 sshd[3643]: pam_unix(sshd:session): session opened for user annieo@domain.com by (uid=0)
Oct 1 16:16:21 web-1 passwd: pam_unix(passwd:chauthtok): user "annieo@domain.com" does not exist in /etc/passwd

nsswitch.conf:
passwd: files ldap
shadow: files ldap
group: files ldap
hosts: files dns
bootparams: nisplus [NOTFOUND=return] files
ethers: files
netmasks: files
networks: files
protocols: files
rpc: files
services: files
netgroup: files ldap
publickey: nisplus
automount: files ldap
aliases: files nisplus

/etc/ldap.conf:
base ou=domain,o=org
uri ldap://10.1.1.1/
binddn cn=admin,o=org
bindpw 1tsAs∑cr∑t!
scope one
timelimit 120
bind_timelimit 120
idle_timelimit 3600
pam_password md5
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
ssl no
tls_cacertdir /etc/openldap/cacerts

What exactly am I missing here? I have compared this account to mine (where I don't have any issues), and I don't see any real difference.

TIA for any insight!!!

Centos 5 is derived from RHEL5. I don't think the password changing PAM modules are LDAP-capable in that version. You probably need to upgrade to something that supports LDAP password changing, like SuSe (or possibly RHEL/Centos6).

You can make an entry in /etc/ldap.conf like this:

# Redirect users to a URL or somesuch on password changes.
pam_password_prohibit_message Please visit https://www.example.com/passwd to change your password.

and set up a web-based password changer there. Be sure to use https though.

UPDATE: long standing problem- https://bugzilla.redhat.com/show_bug...iple&id=138208

Hi Medievalist, and thanks for the reply!

OK, a couple of questions:

1. What is the method to completely eliminate password ageing and checking in RH/Centos5? That would solve this issue as well... Normally it would involve modifying "/etc/pam.d/system-auth"'s "password requisite pam_cracklib.so try_first_pass retry=3" line, adding the testing requirement options, but for some reason in this case this is not true, as the testing is happening even without those changes...

2. Why would most admins have *no* problem logging in, but this one account does? That is neither logical nor consistent, and seems to point to a problem with the account settings rather than PAM itself (as other admins are indeed able to log in using PAM LDAP authentication).

3. I have a very hard time accepting the "PAM is not LDAP-capable in that OS" argument, since there are pam_ldap.so libs being referenced in /etc/pam.d/system-auth. Obviously, PAM is LDAP-capable if the libraries exist. There may be bugs, but those bugs should be widely confirmed and discussed on the web, and a quick grep on google shows this is not the case.

I could move to 6.3 (I have 20 other servers running 6.3 without a problem), even though this particular box is hosting over 100 websites and would require a flash cut, but I am also trying to learn what is happening here. I would like to understand the login/PAM/LDAP interaction at a deeper level, because it's in my nature to absolutely HATE mysteries like this, especially when it's Linux. I haven't seen many unsolved mysteries with Linux: it ain't Windows, where those problems occur daily and people just tend to shrug them off.

Thanks!!

https://www.centos.org/modules/newbb...topic_id=31357

Found the answer on the Centos forums. I had changed "shadowexpire" to -1 earlier, but that did not solve the problem. Changing "shadowmax" to -1 fixed it.

It isn't clear to me from this post so-far why the password change request did not work; hence, why changing the expiration-settings fixed it. I suspect that this post is going to be referred-to frequently in the future. Therefore, could you please elaborate on your findings? What was wrong .. what mechanism was causing it to be wrong .. what you changed .. why the change fixed the problem .. how you demonstrated that the problem was now gone.

I'll try to handle these one at a time...

What was wrong?
By this question, I assume you are asking what the symptoms were. An admin would log into the system via SSH, and be immediately given the message "You are required to change your password immediately (password aged)" and be taken through a password change process, then logged out automatically. When the admin reconnected, they were presented with the same process again. The password had indeed changed to the new password the admin had selected, as they needed to confirm their existing password before setting the new one, so the actual password change process had completed successfully. This process would repeat ad infinitum.

What mechanism was causing it to be wrong?
Whatever mechanism that the login process uses to determine password ageing. I don't understand enough about this process to give an informed answer to this question, but I would love to learn more about it.

What did you change?
I added a "shadowmax" field to the LDAP entry for this admin, and set the value to -1. This field did not exist in the user's LDAP entry prior to my change.

Why did the change fix the problem?
Since I don't fully understand the login processes, my answer here is only an assumption. However, what I believe has happened is that the login mechanism does not have the ability to *add* the "shadowmax" field to an LDAP entry, though it does have the ability to *read* the value of this entry, and therefore make the decision (based on the value of -1) that the user's password should never expire. The login process may be able to *change* the value also, to effectively reset the value to the whatever the system has configured to be a proper "reset" value, though I have not confirmed this. Again, I would love to learn more about this process.

How you demonstrated that the problem was now gone.
The admin was able to successfully log in to the CLI via SSH with no password change process being triggered.

Now here's a request that I have: is there a resource that fully explains, step-by-step, the low-level processes (like the login process) that we normally take for granted as admins?

Thanks!

Actually, looking at the title of this post, a better title would be "SSH login impaired based on percieved password expiry". If a mod would like to change the title of the post, it would probably make more sense for future searchers...