Help answer threads with 0 replies.
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 10-01-2012, 05:25 PM   #1
LQ Newbie
Registered: Oct 2012
Posts: 6

Rep: Reputation: Disabled
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):

cn: annie
sn: o
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=
Oct 1 16:16:21 web-1 sshd[3643]: pam_unix(sshd:account): expired password for user (password aged)
Oct 1 16:16:21 web-1 sshd[3643]: Accepted password for from port 24623 ssh2
Oct 1 16:16:21 web-1 sshd[3643]: pam_unix(sshd:session): session opened for user by (uid=0)
Oct 1 16:16:21 web-1 passwd: pam_unix(passwd:chauthtok): user "" does not exist in /etc/passwd

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

base ou=domain,o=org
uri ldap://
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!!!
Old 10-01-2012, 06:59 PM   #2
Registered: Aug 2003
Distribution: Dead Rat
Posts: 178

Rep: Reputation: 38
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 to change your password.

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

UPDATE: long standing problem-

Last edited by Medievalist; 10-01-2012 at 07:09 PM.
Old 10-01-2012, 07:52 PM   #3
LQ Newbie
Registered: Oct 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
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 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 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.

Old 10-02-2012, 04:12 PM   #4
LQ Newbie
Registered: Oct 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled

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.
Old 10-03-2012, 10:18 AM   #5
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 7,482

Rep: Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377Reputation: 2377
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.

Last edited by sundialsvcs; 10-03-2012 at 10:19 AM.
Old 10-03-2012, 12:24 PM   #6
LQ Newbie
Registered: Oct 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
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?

Old 10-03-2012, 02:34 PM   #7
LQ Newbie
Registered: Oct 2012
Posts: 6

Original Poster
Rep: Reputation: Disabled
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...


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] ldap user not able to change own password Karljoe2 Linux - Server 3 05-03-2012 10:58 PM
[SOLVED] LDAP server, user authentication password Failed sheelavantar Linux - Server 1 08-30-2011 01:35 AM
Help me ! unable to add user to LDAP ! locithcm Linux - Server 1 03-05-2009 11:46 AM
deleting LDAP user...password? blink_00 SUSE / openSUSE 3 02-21-2005 12:24 PM
Unable to logon on as non-root user after update as unable to set executable context pls198 Fedora 2 04-09-2004 12:41 PM

All times are GMT -5. The time now is 08:30 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration