[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