[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user

To: openldap-technical@openldap.org
Subject: Re: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
From: Buchan Milne <bgmilne@staff.telkomsa.net>
Date: Mon, 5 Jul 2010 09:56:03 +0100
Cc: "Licause, Al" <licause@hp.com>
In-reply-to: <E0B7EFCB40BC35448D34DC0E7C5E526781DDB80C5C@GVW1119EXC.americas.hpqcorp.net>
References: <E0B7EFCB40BC35448D34DC0E7C5E526781DDB80C5C@GVW1119EXC.americas.hpqcorp.net>
User-agent: KMail/1.12.4 (Linux/2.6.31.13-desktop-1mnb; KDE/4.3.5; x86_64; ; )

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

Follow-Ups:
- RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
  - From: "Licause, Al" <licause@hp.com>
- RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
  - From: "Licause, Al" <licause@hp.com>
- RE: Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
  - From: "Licause, Al" <licause@hp.com>

References:
- Expired password allowed in via pwdGraceAuthNLimit w/o warning to user
  - From: "Licause, Al" <licause@hp.com>

Prev by Date: Re: ldap bind and password policy
Next by Date: Re: ldap bind and password policy
Index(es):
- Chronological
- Thread