[Date Prev][Date Next] [Chronological] [Thread] [Top]

Expired password allowed in via pwdGraceAuthNLimit w/o warning to user

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:















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.  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:



# 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


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#{SSHA}BIxGPXPqBY+


pwdHistory: 20100702154253Z#{SSHA}q4inOFGO+0N


pwdHistory: 20100702183229Z#{SSHA}3T0Cna8AGIg


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.


If the default system-auth file generated by the authconfig utility defeats a feature

of the ldap or other system modules, we need to report this to Red Hat and have the

problem corrected.


Any help greatly appreciated.


Al Licause