Hi All,

When sshing into a machine with an expired password, the user is forced
to change the password immediately. When updating the expired password
the user is not advised if the proposed new password is in openldap's
ppolicy password history. The update is denied but the user is not advised
why, even though openldap generates a reason/message and pam_ldap passes that
message to sshd (observed via strace).

I will appreciate any advise on why the advisory messages are not getting to
the user. (In fact, why no stderr seems to get to the user during the password
update). I also posted to the pam_ldap list.

I only see this problem when using password authentication, not sshkeys. When
logging in via sshkeys, all works as expected.

thanks in advance for you time,
sam

Details:

Password is expired is governed by the shadowMax field stored in ldap
pam_ldap.so (180) attempts to update the password via the OpenLDAP password
change extended operation, as configured in /etc/ldap.conf.

Case 1)
Logging into a machine via ssh with an expired password, the interaction goes
like this:

[someuser@somemachine ~]$ ssh somemachine
Password:
You are required to change your LDAP password immediately.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
Password:

We don't see any of the three errors that pam_ldap reports:
LDAP password information update failed: Can't contact LDAP server
Password is in history of old passwords
passwd: Permission denied

Case 2)
Logging into a machine via ssh and sshkeys, the session looks like this for
a user whose password is expired:

The motd displays, then the user is entered into a password update dialogue.
The user _is_ warned if "Password is in history of old passwords".

[someuser@somemachine ~]$ passwd
Changing password for user someuser.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Can't contact LDAP server
Password is in history of old passwords
passwd: Permission denied

Case 3)
Using "passwd" during an existing session:
The user _is_ warned if "Password is in history of old passwords":

[someuser@somemachine ~]$ passwd
Changing password for user someuser.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Can't contact LDAP server
Password is in history of old passwords
passwd: Permission denied

Case 4)
logging into a machine via the terminal with an expired password produces a
similar result to case #2 (ssh via sshkeys), except that we don't display the
motd.

[someuser@somemachine ~]$ ssh somemachine
Password:
You are required to change your LDAP password immediately.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Can't contact LDAP server
Password is in history of old passwords
passwd: Permission denied

I believe that pam_ldap is doing what it should be doing, but I would love to
know why the advisory messages are not getting to the user.

Here's why I think pam_ldap is functioning correctly:
In all cases (passwd via command line, terminal login, sshd login), I see
pam_ldap.so writing identical info to the system log.

When I run strace on sshd -d, it shows the advisory lines in a "write"
statement. Somewhere between sshd and the end user, the advisory is lost.

sshd is configured to UsePAM, with the following PAM conf:
## system-auth is configured to use pam_ldap.so
auth sufficient /lib/security/pam_unix.so likeauth nullok shadow
auth sufficient /lib/security/pam_ldap.so use_first_pass
auth required /lib/security/pam_deny.so
account sufficient /lib/security/pam_unix.so
account sufficient /lib/security/pam_ldap.so use_first_pass
account required /lib/security/pam_deny.so
password required /lib/security/pam_cracklib.so retry=3
password sufficient /lib/security/pam_unix.so nullok use_authtok shadow
password sufficient /lib/security/pam_ldap.so use_authtok use_first_pass
password required /lib/security/pam_deny.so
session required /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0022
session required /lib/security/pam_limits.so
session sufficient /lib/security/pam_unix.so
session sufficient /lib/security/pam_ldap.so use_first_pass
## pam_mkhomedir.so likes to be before sufficient (go no further) pam_ldap.so


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com