Thanks much for the ldapwhoami tip. I lowered the policy values to allow the password to expire quickly then reset the pwdGraceAuthNLimit to 2.
I then logged in as an ldap user and ran the following: ldapwhoami -x -D uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net -e ppolicy -W I ran it three times as the password was expiring or about to and received warning messages each time: Enter LDAP Password: ldap_bind: Success (0) (Password expires in 85 seconds) dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net Result: Success (0) Enter LDAP Password: ldap_bind: Success (0) (Password expires in 54 seconds) dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net Result: Success (0) Enter LDAP Password: ldap_bind: Success (0) (Password expired, 1 grace logins remain) dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net Result: Success (0) So what does that tell you if anything about the pam module system-auth or any other pam module ? Am I missing a module ? Do I need a later version of nss_ldap or some other component ? Al -----Original Message----- From: Buchan Milne [mailto:[email protected]] Sent: Monday, July 05, 2010 4:56 AM To: [email protected] Cc: Licause, Al Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user I did not reply to your off-list mails, primarily because I was out of the office (at a data centre) all of Friday, and without internet access over the weekend. You could have sent those replies to your original thread to the list ... On Friday, 2 July 2010 20:09:15 Licause, Al wrote: > I have installed and configured the ppolicy overlay software on a Red Hat > V5.4 server along with the openldap server software and the following > components: > > openldap-servers-2.3.43-3.el5 > python-ldap-2.2.0-2.1 > openldap-devel-2.3.43-3.el5 > checkpassword-ldap-0.01-1.2.el5.rf > mozldap-6.0.5-1.el5 > openldap-2.3.43-3.el5 > openldap-debuginfo-2.3.43-3.el5 > openldap-servers-overlays-2.3.43-3.el5 > nss_ldap-253-22.el5_4 > openldap-clients-2.3.43-3.el5 > > PROBLEM: > > I have notice that when an ldap users' password expires, and > pwdGraceAuthNLimit is set to a non-zero value...in my case it is set to 1 > for testing purposes, the user is allowed to login one time. The next > login forces a password change. > > On the first login, allowed via pwdGraceAuthNLimit, there is no > announcement sent to the user telling them that the password has expired. You should actually get a prompt to change your password immediately. BTW, if your PAM setup was correct, you should have seen warnings about expiry before this. Did you bother testing with a guaranteed-to-work tool, such as (with appropriate values to -D option) 'ldapwhoami -e ppolicy' ? > Nor that they will have to change their password on the next login. I > have to wonder if there is also a missing announcement that might tell the > user how many more logins they are permitted given the value of > pwdGraceAuthNLimit > > It was suggested that the problem may be in the pam configuration. > > I am using the following /etc/pam.d/system-auth file that is autogenerated > by authconfig: > > #%PAM-1.0 > # This file is auto-generated. > # User changes will be destroyed the next time authconfig is run. > auth required pam_env.so > auth sufficient pam_unix.so nullok try_first_pass > auth requisite pam_succeed_if.so uid >= 500 quiet > auth sufficient pam_ldap.so use_first_pass > auth required pam_deny.so > > account required pam_unix.so broken_shadow > account sufficient pam_localuser.so > account sufficient pam_succeed_if.so uid < 500 quiet > account [default=bad success=ok user_unknown=ignore] pam_ldap.so > account required pam_permit.so This should be pam_deny.so, but is likely not the cause of your problems. > password requisite pam_cracklib.so try_first_pass retry=3 > password sufficient pam_unix.so md5 shadow nis nullok try_first_pass > use_authtok password sufficient pam_ldap.so use_authtok > password required pam_deny.so > > session optional pam_keyinit.so revoke > session required pam_limits.so > session optional pam_mkhomedir.so > session [success=1 default=ignore] pam_succeed_if.so service in crond > quiet use_uid session required pam_unix.so > session optional pam_ldap.so > > > I am testing by logging into the client with ssh. I also have many of the > pwd* values set fairly low for quick testing. This is the default policy > in use: > > dn: cn=Standard,ou=Policies,dc=mydomain,dc=com > objectClass: top > objectClass: device > objectClass: pwdPolicy > cn: Standard > pwdAttribute: userPassword > pwdLockoutDuration: 15 > pwdInHistory: 6 > pwdCheckQuality: 0 > pwdMinLength: 5 > pwdAllowUserChange: TRUE > pwdMustChange: TRUE > pwdMaxFailure: 3 > pwdFailureCountInterval: 120 > pwdSafeModify: FALSE > pwdLockout: TRUE > pwdReset: TRUE > structuralObjectClass: device > entryUUID: 421d8558-1a33-102f-8b9e-a5541f2aaf30 > creatorsName: cn=Manager,dc=mydomain,dc=com > createTimestamp: 20100702143843Z > pwdMinAge: 0 > pwdMaxAge: 300 > pwdGraceAuthNLimit: 1 > pwdExpireWarning: 86400 > entryCSN: 20100702154010Z#000000#00#000000 > modifiersName: cn=Manager,dc=mydomain,dc=com > modifyTimestamp: 20100702154010Z > > This is the test users profile: > > dn: uid=ldap1,dc=mydomain,dc=com > uid: ldap1 > cn: ldap1 > objectClass: account > objectClass: posixAccount > objectClass: top > uidNumber: 10001 > gidNumber: 150 > homeDirectory: /home/ldap1 > loginShell: /bin/csh > gecos: ldap test user > pwdPolicySubentry: cn=Standard,ou=Policies,dc=mydomain,dc=com > structuralObjectClass: account > entryUUID: 334312be-1a33-102f-8a83-a5541f2aaf30 > creatorsName: cn=Manager,dc=mydomain,dc=com > createTimestamp: 20100702143818Z > pwdHistory: > 20100702151010Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}BIxGPXPqBY+ > 2yK6pY2i+6l7UbE/gaVhY > pwdHistory: > 20100702154253Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}q4inOFGO+0N > c6T0q6FYiiMrPCTTUqQdr > pwdHistory: > 20100702183229Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}3T0Cna8AGIg > X69V7zsDxGiTx/q0ceBnc > userPassword:: e1NTSEF9WkZ0ekJrUWVOQVJrMDhFbDJXd0VNaU1maWlGVURaT28= > pwdChangedTime: 20100702183229Z > pwdGraceUseTime: 20100702184519Z > entryCSN: 20100702184519Z#000000#00#000000 > modifiersName: cn=Manager,dc=mydomain,dc=com > modifyTimestamp: 20100702184519Z > > > I have examined various log files and enabled debugging in system-auth (now > removed to show the standard autogenerated content) for any clues. I have > examined various pam modules and library files with strings to see if I > could get an idea as to which module may be at fault. > > I have to admit I am no pam expert and given the number of combinations and > variations possible in the system-auth file alone, I don't feel > comfortable modifying this file to any great extent. > > I have omitted the slapd.conf and client ldap.conf files assuming that they > are not at fault and don't have any obvious omissions which could cause a > warning messages to be suppressed during login, but can supply them if > required. You need to supply the pam_ldap ldap.conf (/etc/ldap.conf on RH), specifically verify whether 'pam_lookup_policy' is set to 'yes'. Please see 'man pam_ldap'. > If the default system-auth file generated by the authconfig utility defeats > a feature of the ldap or other system modules, It doesn't "defeat" a feature, but the feature does need to be specifically enabled. > we need to report this to > Red Hat and have the problem corrected. Of course, then this entire discussion is more or less off-topic here ... Regards, Buchan
