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