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