[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
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