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

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Friday, 9 July 2010 15:00:27 Licause, Al wrote:
> Chris,
> 
> Again thanks so much for the response.
> 
> What I don't understand is which component is responsible for requesting
>  the password expiration information ?

In your specific case, pam_ldap.

>  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.

This calculation is done on the server side, and passed back to the client in 
controls attached to the bind response, if the bind had the appropriate 
controls attached to 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.

See --help ...

(This may be a bug, but the version you have is quite outdated ... so if it is 
still not documented in the ldapwhoami man page in 2.4.23, you should consider 
filing an ITS).

> 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)

Password policy is (AFAIK) currently only applicable to simple binds. (It may 
be possible to support it for other methods, if the SASL mech supports it).

> 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.

Please provide the exact message you see with ssh ...

> A strings on ldapwhoami shows these warnings coming from ldapwhoami itself.

The interpretation from control values to actual string representations must 
be done by the application.

>    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 ?

$ strings /lib64/security/pam_ldap.so |grep -i 'will expire'
Your LDAP password will expire in %ld day%s.

From the source of pam_ldap:

if (controls != NULL)
    {
      LDAPControl **ctlp;
      for (ctlp = controls; *ctlp != NULL; ctlp++)
        {
          if (!strcmp ((*ctlp)->ldctl_oid, LDAP_CONTROL_PWEXPIRING))
            {
              char seconds[32];
              snprintf (seconds, sizeof seconds, "%.*s",
                        (int) (*ctlp)->ldctl_value.bv_len,
                        (*ctlp)->ldctl_value.bv_val);
              session->info->password_expiration_time = atol (seconds);
            }

....

> 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.

It works on CentOS 5.4 with exclusively distro-provided client software 
versions.

My password hasn't expired during this discussion, so I haven't been able to 
conveniently show this, and I don't have time to mess around with my test 
accounts at present ... but one of the members of my team was prompted to 
change his password on login today

This setup is for a Kerberos+LDAP environment, with Heimdal hdb_ldap, pam_ldap 
is used for both auth and account to have working password expiry, pam_krb5 is 
used in auth so users get tickets from pam_krb5 in session ... so, you may 
need some removal of the pam_krb5 lines ....

/etc/pam.d/system-auth:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        optional    pam_krb5.so use_first_pass
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_ldap.so
account     required      pam_deny.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow 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_krb5.so


grep policy /etc/ldap.conf
bind_policy soft
pam_lookup_policy yes


# grep -E "^(shadow|passwd|group)" /etc/nsswitch.conf
passwd:     files ldap
shadow:     files
group:      files ldap

(note, no ldap in shadow, so users can't be authenticated by pam_unix-
>nss_ldap and bypass simple bind and password policy enforcement)


/etc/pam.d/sshd, as shipped by CentOS


Regards,
Buchan