[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
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