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