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

[Chris Jacobs <Chris.Jacobs@apollogrp.edu>]

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.