Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

updating expired passwords following ssh login, user advisory

Subject: updating expired passwords following ssh login, user advisory
Date: Wed, 15 Mar 2006 13:46:02 -0800 (PST)
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 

<Prev in Thread] Current Thread [Next in Thread>