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
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
Buchan,
Thanks for the information.....please see my responses inserted below.
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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 ...
No problem. You were correct in stating that I posted to the wrong discussion and I therefore should have expected no further discussion.
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.
I'm not seeing that. If the number of permitted logins specified by pwdGraceAuthNLimit has not counted an equal number of attempted logins, the login is allowed with no warnings. When the number of attempts to login finally exceeds pwdGraceAuthNLimit, then and only then is the user prompted to change the password.
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' ?
I hadn't but having done so at your suggestion, and using -x since I am not using sasl, it yields the following:
$ ldapwhoami -x ppolicy anonymous Result: Success (0)
Pardon my ignorance, but I'm not sure of the significance of this test and what it would have shown with regard to the pwdGraceAuthNLimit warnings.
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.
I tried changing this entry to pam_deny.so and while it didn't force a warning to be printed, it also simply denied access to the user as it should have.
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'.
These are the uncommented lines from my /etcldap.conf file:
host 16.112.240.51 base dc=osn,dc=cxo,dc=cpqcorp,dc=net
binddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net rootpw {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG
rootbinddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net
nss_base_group dc=osn,dc=cxo,dc=cpqcorp,dc=net?one?&(objectCategory=group)(gidnumber=*)
ppolicy_hash_cleartext ppolicy_use_lockout
pam_lookup_policy yes ppolicy_default "cn=Standard,ou=Policies,dc=osn,dc=cxo,dc=cpqcorp,dc=net"
ssl no
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,ntp,smmsp,xfs
pam_password exop
bind_policy soft
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.
That's the key then......how do we specifically enable this feature ?
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 ...
Not sure why ?
Regards, Buchan
On Tuesday, 6 July 2010 13:24:51 Licause, Al wrote:
Buchan,
Thanks for the information.....please see my responses inserted below.
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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 ...
No problem. You were correct in stating that I posted to the wrong discussion and I therefore should have expected no further discussion.
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.
I'm not seeing that. If the number of permitted logins specified by pwdGraceAuthNLimit has not counted an equal number of attempted logins, the login is allowed with no warnings. When the number of attempts to login finally exceeds pwdGraceAuthNLimit, then and only then is the user prompted to change the password.
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' ?
I hadn't but having done so at your suggestion, and using -x since I am not using sasl, it yields the following:
$ ldapwhoami -x ppolicy anonymous Result: Success (0)
Please see the man page. You need to provide a DN and password (e.g. ldapwhoami -x -D uid=xxx..... -W .....), but if you aren't familiar enough with the tools, please read the man pages.
Pardon my ignorance, but I'm not sure of the significance of this test and what it would have shown with regard to the pwdGraceAuthNLimit warnings.
Well, you have to use the test correctly.
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.
I tried changing this entry to pam_deny.so and while it didn't force a warning to be printed, it also simply denied access to the user as it should have.
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'.
These are the uncommented lines from my /etcldap.conf file:
host 16.112.240.51 base dc=osn,dc=cxo,dc=cpqcorp,dc=net
binddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net rootpw {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG
This is invalid in ldap.conf
rootbinddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net
nss_base_group dc=osn,dc=cxo,dc=cpqcorp,dc=net?one?&(objectCategory=group)(gidnumber=*)
ppolicy_hash_cleartext
This is invalid in ldap.conf
ppolicy_use_lockout
This is invalid in ldap.conf
pam_lookup_policy yes ppolicy_default "cn=Standard,ou=Policies,dc=osn,dc=cxo,dc=cpqcorp,dc=net"
This is invalid in ldap.conf
ssl no
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,ntp ,smmsp,xfs
pam_password exop
bind_policy soft
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.
That's the key then......how do we specifically enable this feature ?
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 ...
Not sure why ?
You haven't determined what the problem is with your configuration, and the configuration supplied by 3rd-parties supplying binaries of pam_ldap is not really relevant here, but should be taken up with said 3rd-parties.
Regards, Buchan
This works from the test account:
$ ldapwhoami -x -D uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net -W Enter LDAP Password: dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net Result: Success (0)
It still doesn't tell me anything about the problems I have raised with pwdGraceAuthNLimit.
The following have been removed from the /etc/ldap.conf:
rootpw {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG
ppolicy_hash_cleartext
ppolicy_use_lockout
The ldap server has been restarted.
Still no notification when the users password expires and pwdGraceAuthNLimit is greater than zero.
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Tuesday, July 06, 2010 9:06 AM To: Licause, Al Cc: openldap-technical@openldap.org Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
On Tuesday, 6 July 2010 13:24:51 Licause, Al wrote:
Buchan,
Thanks for the information.....please see my responses inserted below.
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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 ...
No problem. You were correct in stating that I posted to the wrong discussion and I therefore should have expected no further discussion.
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.
I'm not seeing that. If the number of permitted logins specified by pwdGraceAuthNLimit has not counted an equal number of attempted logins, the login is allowed with no warnings. When the number of attempts to login finally exceeds pwdGraceAuthNLimit, then and only then is the user prompted to change the password.
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' ?
I hadn't but having done so at your suggestion, and using -x since I am not using sasl, it yields the following:
$ ldapwhoami -x ppolicy anonymous Result: Success (0)
Please see the man page. You need to provide a DN and password (e.g. ldapwhoami -x -D uid=xxx..... -W .....), but if you aren't familiar enough with the tools, please read the man pages.
Pardon my ignorance, but I'm not sure of the significance of this test and what it would have shown with regard to the pwdGraceAuthNLimit warnings.
Well, you have to use the test correctly.
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.
I tried changing this entry to pam_deny.so and while it didn't force a warning to be printed, it also simply denied access to the user as it should have.
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'.
These are the uncommented lines from my /etcldap.conf file:
host 16.112.240.51 base dc=osn,dc=cxo,dc=cpqcorp,dc=net
binddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net rootpw {SSHA}RHVddPmANdnsYDuMzFlM/D4D7aAH1yYG
This is invalid in ldap.conf
rootbinddn cn=Manager,dc=osn,dc=cxo,dc=cpqcorp,dc=net
nss_base_group dc=osn,dc=cxo,dc=cpqcorp,dc=net?one?&(objectCategory=group)(gidnumber=*)
ppolicy_hash_cleartext
This is invalid in ldap.conf
ppolicy_use_lockout
This is invalid in ldap.conf
pam_lookup_policy yes ppolicy_default "cn=Standard,ou=Policies,dc=osn,dc=cxo,dc=cpqcorp,dc=net"
This is invalid in ldap.conf
ssl no
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,ntp ,smmsp,xfs
pam_password exop
bind_policy soft
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.
That's the key then......how do we specifically enable this feature ?
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 ...
Not sure why ?
You haven't determined what the problem is with your configuration, and the configuration supplied by 3rd-parties supplying binaries of pam_ldap is not really relevant here, but should be taken up with said 3rd-parties.
Regards, Buchan
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:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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
From the previous post, we can see the expiration messages and grace period messages when using ldapwhoami with -e ppolicy.
If I look for those expiration messages, I see they are coming from the executable ldapwhoami.
I find some expiration messages in sshd, but nothing with grace period messages other than "Invalid login grace time" and nothing from telnetd which is not all that surprising given it's age.
Can I assume from this that we need a newer sshd component in order to see these grace period messages ?
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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
What I've done in my implementation is to enable password expiration warnings - with the warning age being set to just a few seconds less than the password expiration period.
For example, when I login I see: $ ssh <host> <user>@<host>'s password: Your LDAP password will expire in 182 days. Last login: Thu Jul 8 18:17:24 2010 from <ip> [<user>@<host> ~]$
Granted, I still won't see a warning on the last day... but that's been reported previously and a fairly small issue. Really, I think that and your issue are both PAM issues; not OpenLDAP.
- chris
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Licause, Al Sent: Thursday, July 08, 2010 11:55 AM To: Buchan Milne; openldap-technical@openldap.org Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
From the previous post, we can see the expiration messages and grace period messages when using ldapwhoami with -e ppolicy.
If I look for those expiration messages, I see they are coming from the executable ldapwhoami.
I find some expiration messages in sshd, but nothing with grace period messages other than "Invalid login grace time" and nothing from telnetd which is not all that surprising given it's age.
Can I assume from this that we need a newer sshd component in order to see these grace period messages ?
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
From the previous post, we can see the expiration messages and grace period messages when using ldapwhoami with -e ppolicy.
If I look for those expiration messages, I see they are coming from the executable ldapwhoami.
I find some expiration messages in sshd, but nothing with grace period messages other than "Invalid login grace time" and nothing from telnetd which is not all that surprising given it's age.
Can I assume from this that we need a newer sshd component in order to see these grace period messages ?
Al
I had a similar issue. Setting
pam_password exop
in ldap.conf on the Linux client resolved the issue (not sure why).
Thanks, Joe
_________________________________________________________________ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PI...
Chris,
Again thanks so much for the response.
What I don't understand is which component is responsible for requesting the password expiration information ? It must all of pwdGraceAuthNLimit, pwdMaxAge and pwdChangedTime in order to calculate the information needed to determine which warning to display and when to display it.
It had been suggested that we test with ldapwhoami -e ppolicy. This wasn't something that was obvious to me as the man page for ldapwhoami doesn't show a -e option.
Or perhaps this is an extension of the ldapsearch or similar commands to include extended parameters.....again something not obvious unless you are familiar with the code.
In any case, when used with -x (since I am not using sasl) and -D uid=ldapuser,dc=....-W, only then do I see the warnings down to the second that the password will expire and if it has expired and pwdGraceAuthNLimit is greater than 0, do I see the grace period warning, when testing with ssh.
A strings on ldapwhoami shows these warnings coming from ldapwhoami itself. I have seen no other such strings in ssh, sshd, telnet, telnetd or any other of the pam modules so that tells me if this can be done through a pam module, perhaps some qualifier needs to be included in the system-auth or other file in order to trigger this response or we simply need a later version of some utility or library modules ?
I should also note that I am using only that software is provided with the Red Hat distribution. I work for a support organization and can only use the Red Hat provided kits. So I'd like to get this working with these restrictions.
Any help greatly appreciated
Al
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Chris Jacobs Sent: Thursday, July 08, 2010 3:04 PM To: Licause, Al; Buchan Milne; openldap-technical@openldap.org Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
What I've done in my implementation is to enable password expiration warnings - with the warning age being set to just a few seconds less than the password expiration period.
For example, when I login I see: $ ssh <host> <user>@<host>'s password: Your LDAP password will expire in 182 days. Last login: Thu Jul 8 18:17:24 2010 from <ip> [<user>@<host> ~]$
Granted, I still won't see a warning on the last day... but that's been reported previously and a fairly small issue. Really, I think that and your issue are both PAM issues; not OpenLDAP.
- chris
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Licause, Al Sent: Thursday, July 08, 2010 11:55 AM To: Buchan Milne; openldap-technical@openldap.org Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
From the previous post, we can see the expiration messages and grace period messages when using ldapwhoami with -e ppolicy.
If I look for those expiration messages, I see they are coming from the executable ldapwhoami.
I find some expiration messages in sshd, but nothing with grace period messages other than "Invalid login grace time" and nothing from telnetd which is not all that surprising given it's age.
Can I assume from this that we need a newer sshd component in order to see these grace period messages ?
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Al,
I don't /know/ but I've gathered the OpenLDAP slapd sends the info, and it's up to the pam_ldap module to understand and act on it.
You asked in an email (direct, forgetting to hit reply-to-all I suspect - I've done it too) for my pam config. I'm leaving this morning for a camping trip on probably the first 'summer' weekend here in western Washington (state), and I won't be able to get that for you until Tuesday.
I'm using CentOS 5.2 thru .4 - so at least it'll be redhat related.
I'm fairly certain I've posted it before; try googling PAM LDAP chris-jacobs and some of the common pam modules. It's probably slightly out of date; again, I'll repost on Tuesday.
- chris
Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: Licause, Al licause@hp.com To: Chris Jacobs; Buchan Milne bgmilne@staff.telkomsa.net; openldap-technical@openldap.org openldap-technical@openldap.org Sent: Fri Jul 09 07:00:27 2010 Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
Chris,
Again thanks so much for the response.
What I don't understand is which component is responsible for requesting the password expiration information ? It must all of pwdGraceAuthNLimit, pwdMaxAge and pwdChangedTime in order to calculate the information needed to determine which warning to display and when to display it.
It had been suggested that we test with ldapwhoami -e ppolicy. This wasn't something that was obvious to me as the man page for ldapwhoami doesn't show a -e option.
Or perhaps this is an extension of the ldapsearch or similar commands to include extended parameters.....again something not obvious unless you are familiar with the code.
In any case, when used with -x (since I am not using sasl) and -D uid=ldapuser,dc=....-W, only then do I see the warnings down to the second that the password will expire and if it has expired and pwdGraceAuthNLimit is greater than 0, do I see the grace period warning, when testing with ssh.
A strings on ldapwhoami shows these warnings coming from ldapwhoami itself. I have seen no other such strings in ssh, sshd, telnet, telnetd or any other of the pam modules so that tells me if this can be done through a pam module, perhaps some qualifier needs to be included in the system-auth or other file in order to trigger this response or we simply need a later version of some utility or library modules ?
I should also note that I am using only that software is provided with the Red Hat distribution. I work for a support organization and can only use the Red Hat provided kits. So I'd like to get this working with these restrictions.
Any help greatly appreciated
Al
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Chris Jacobs Sent: Thursday, July 08, 2010 3:04 PM To: Licause, Al; Buchan Milne; openldap-technical@openldap.org Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
What I've done in my implementation is to enable password expiration warnings - with the warning age being set to just a few seconds less than the password expiration period.
For example, when I login I see: $ ssh <host> <user>@<host>'s password: Your LDAP password will expire in 182 days. Last login: Thu Jul 8 18:17:24 2010 from <ip> [<user>@<host> ~]$
Granted, I still won't see a warning on the last day... but that's been reported previously and a fairly small issue. Really, I think that and your issue are both PAM issues; not OpenLDAP.
- chris
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Licause, Al Sent: Thursday, July 08, 2010 11:55 AM To: Buchan Milne; openldap-technical@openldap.org Subject: RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
From the previous post, we can see the expiration messages and grace period
messages when using ldapwhoami with -e ppolicy.
If I look for those expiration messages, I see they are coming from the executable ldapwhoami.
I find some expiration messages in sshd, but nothing with grace period messages other than "Invalid login grace time" and nothing from telnetd which is not all that surprising given it's age.
Can I assume from this that we need a newer sshd component in order to see these grace period messages ?
Al
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Monday, July 05, 2010 4:56 AM To: openldap-technical@openldap.org 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
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
On Friday, 9 July 2010 15:00:27 Licause, Al wrote:
Chris,
Again thanks so much for the response.
What I don't understand is which component is responsible for requesting the password expiration information ?
In your specific case, pam_ldap.
It must all of pwdGraceAuthNLimit, pwdMaxAge and pwdChangedTime in order to calculate the information needed to determine which warning to display and when to display it.
This calculation is done on the server side, and passed back to the client in controls attached to the bind response, if the bind had the appropriate controls attached to it.
It had been suggested that we test with ldapwhoami -e ppolicy. This wasn't something that was obvious to me as the man page for ldapwhoami doesn't show a -e option.
See --help ...
(This may be a bug, but the version you have is quite outdated ... so if it is still not documented in the ldapwhoami man page in 2.4.23, you should consider filing an ITS).
Or perhaps this is an extension of the ldapsearch or similar commands to include extended parameters.....again something not obvious unless you are familiar with the code.
In any case, when used with -x (since I am not using sasl)
Password policy is (AFAIK) currently only applicable to simple binds. (It may be possible to support it for other methods, if the SASL mech supports it).
and -D uid=ldapuser,dc=....-W, only then do I see the warnings down to the second that the password will expire and if it has expired and pwdGraceAuthNLimit is greater than 0, do I see the grace period warning, when testing with ssh.
Please provide the exact message you see with ssh ...
A strings on ldapwhoami shows these warnings coming from ldapwhoami itself.
The interpretation from control values to actual string representations must be done by the application.
I have seen no other such strings in ssh, sshd, telnet, telnetd or any other of the pam modules so that tells me if this can be done through a pam module, perhaps some qualifier needs to be included in the system-auth or other file in order to trigger this response or we simply need a later version of some utility or library modules ?
$ strings /lib64/security/pam_ldap.so |grep -i 'will expire' Your LDAP password will expire in %ld day%s.
From the source of pam_ldap:
if (controls != NULL) { LDAPControl **ctlp; for (ctlp = controls; *ctlp != NULL; ctlp++) { if (!strcmp ((*ctlp)->ldctl_oid, LDAP_CONTROL_PWEXPIRING)) { char seconds[32]; snprintf (seconds, sizeof seconds, "%.*s", (int) (*ctlp)->ldctl_value.bv_len, (*ctlp)->ldctl_value.bv_val); session->info->password_expiration_time = atol (seconds); }
....
I should also note that I am using only that software is provided with the Red Hat distribution. I work for a support organization and can only use the Red Hat provided kits. So I'd like to get this working with these restrictions.
It works on CentOS 5.4 with exclusively distro-provided client software versions.
My password hasn't expired during this discussion, so I haven't been able to conveniently show this, and I don't have time to mess around with my test accounts at present ... but one of the members of my team was prompted to change his password on login today
This setup is for a Kerberos+LDAP environment, with Heimdal hdb_ldap, pam_ldap is used for both auth and account to have working password expiry, pam_krb5 is used in auth so users get tickets from pam_krb5 in session ... so, you may need some removal of the pam_krb5 lines ....
/etc/pam.d/system-auth:
auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth optional pam_krb5.so use_first_pass 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_ldap.so account required pam_deny.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow 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_krb5.so
grep policy /etc/ldap.conf bind_policy soft pam_lookup_policy yes
# grep -E "^(shadow|passwd|group)" /etc/nsswitch.conf passwd: files ldap shadow: files group: files ldap
(note, no ldap in shadow, so users can't be authenticated by pam_unix-
nss_ldap and bypass simple bind and password policy enforcement)
/etc/pam.d/sshd, as shipped by CentOS
Regards, Buchan
Ok....good progress...and thanks again for the data.
-----Original Message----- From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net] Sent: Friday, July 09, 2010 12:27 PM To: Licause, Al Cc: Chris Jacobs; openldap-technical@openldap.org Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
On Friday, 9 July 2010 15:00:27 Licause, Al wrote:
Chris,
Again thanks so much for the response.
What I don't understand is which component is responsible for requesting the password expiration information ?
In your specific case, pam_ldap.
Excellent !
It must all of pwdGraceAuthNLimit, pwdMaxAge and pwdChangedTime in order to calculate the information needed to determine which warning to display and when to display it.
This calculation is done on the server side, and passed back to the client in controls attached to the bind response, if the bind had the appropriate controls attached to it.
Good to know.....so only the final calculated data is sent to the client if requested. Not sure I'm seeing the correct request then when using tcpdump or looking at slapd logging. I suspect we have some old components which are going to require upgrades.
It had been suggested that we test with ldapwhoami -e ppolicy. This wasn't something that was obvious to me as the man page for ldapwhoami doesn't show a -e option.
See --help ...
Didn't think to use --help.....now I see it.
(This may be a bug, but the version you have is quite outdated ... so if it is still not documented in the ldapwhoami man page in 2.4.23, you should consider filing an ITS).
Yes...unfortunately. I'm hoping to try out RHES V6 soon to see if they have include later versions of all ldap components. RHES V5.5 still doesn't have what we need.
Or perhaps this is an extension of the ldapsearch or similar commands to include extended parameters.....again something not obvious unless you are familiar with the code.
In any case, when used with -x (since I am not using sasl)
Password policy is (AFAIK) currently only applicable to simple binds. (It may be possible to support it for other methods, if the SASL mech supports it).
No problem.....but good to know.
and -D uid=ldapuser,dc=....-W, only then do I see the warnings down to the second that the password will expire and if it has expired and pwdGraceAuthNLimit is greater than 0, do I see the grace period warning, when testing with ssh.
Please provide the exact message you see with ssh ...
# ssh -l ldap1 ldap1 ldap1@ldap1's password: Your LDAP password will expire in 1 day. Last login: Fri Jul 9 11:04:11 2010 from ldap1.osn.cxo.cpqcorp.net
This is displayed if the time to expiration is greater than a 24 hour period which is good....but not displayed if less than that.....which I believe someone said is a known issue in this version.
If the password has already expired, we get no messages and no warnings about grace periods:
# ssh -l ldap1 ldap1 ldap1@ldap1's password: Last login: Fri Jul 9 11:14:16 2010 from ldap1.osn.cxo.cpqcorp.net
[ldap1@ldap1 ~]$ ldapwhoami -x -D uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net -e ppolicy -W Enter LDAP Password: ldap_bind: Success (0) (Password expired, 4 grace logins remain) dn:uid=ldap1,dc=osn,dc=cxo,dc=cpqcorp,dc=net Result: Success (0)
I had expiration set down low for testing and then pwdGraceAuthNLimit set to 5 so that we could hopefully see the expired grace warnings.
A strings on ldapwhoami shows these warnings coming from ldapwhoami itself.
The interpretation from control values to actual string representations must be done by the application.
I have a feeling that the version of sshd may also be old enough that it is not doing this work....
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
If the grace period warning is also supposed to come from pam_ldap.so, then again, ours is probably old and needs to be upgraded:
# strings pam_ldap.so | grep -i grace
# strings pam_ldap.so | grep -i expire shadowExpire Password Expired Your LDAP password will expire in %ld day%s.
Thanks for including a good example of system-auth. I adding only one line that differed to ours and ignored any references to Kerberos libraries and still no warnings.
I also modified the nsswitch.conf to make sure that shadow accounts were only handled by the local facilities.
Again thanks for the help.
I think I'll investigate to see if newer versions of ldap components have been included in a later version of the OS distributions we support.
Al
openldap-technical@openldap.org
-
Buchan Milne -
Chris Jacobs -
Joe Friedeggs -
Licause, Al