On Thu, 2012-11-29 at 09:52 -0800, Iain Morgan wrote:
> On Tue, Nov 27, 2012 at 16:01:48 -0600, Iain Morgan wrote:
> > On Tue, Nov 27, 2012 at 15:00:42 -0600, Stephen Gallagher wrote:
> > > On Tue 27 Nov 2012 03:51:55 PM EST, Iain Morgan wrote:
> > > > Hello,
> > > >
> > > > I recently began experimenting with sssd (1.8.0) and have run into
an
> > > > issue with its support for password expiration. Specifically, the
case
> > > > where sssd is configured to use LDAP and the user authenticates via
SSH
> > > > public-key.
> > > >
> > > > If a user connects via ssh to a host which is using sssd and
> > > > authenticates via a public-key, the only way to enforce password
> > > > expiration appears to be to set ldap_pwd_policy=shadow. However,
sssd
> > > > will not attempt to change the password when the policy is thus set.
> > > >
> > > > I know that there are those who would argue that password expiration
> > > > should not be enforced when public-key authentication is used, but
that
> > > > is an organizational policy decision. The expectation for the
environment
> > > > which I deal with is that password expiration should be enforced,
and
> > > > work, regardless of the method used for authentication.
> > > >
> > > > Is there some trick that I have overlooked or is this simply a
design
> > > > limitation? If the shadow map were exposed, pam_unix.so could be used
to
> > > > detect password expiration and pam_sss.so (with
ldap_pwd_policy=none)
> > > > could be used to change the password, but that is not currently the
> > > > case.
> > > >
> > >
> > > Try setting:
> > >
> > > access_provider = ldap
> > > ldap_access_order = expire
> > > ldap_account_expire_policy = shadow
> > >
> > > That should do what you're looking for. It tells the SSSD to honor
> > > shadow expiration/locking policy during the PAM_ACCT_MGMT phase. This
> > > phase will occur regardless of what authentication mechanism you use.
> >
> > Hmm, I had overlooked ldap_account_expire_policy. Unfortunately, the
> > settings recommended above do not appear to have altered the situation.
> > I guess I need to spend some time looking at the debug output.
> >
> > Thanks,
> >
>
> Lookinf through the debug output, I see that sssd checks the
> shadowExpire attribute:
>
> (Wed Nov 28 11:06:10 2012) [sssd[be[LDAP]]] [sdap_account_expired_shadow]
> (0x0400): Performing access shadow check for user [testacct]
> (Wed Nov 28 11:06:10 2012) [sssd[be[LDAP]]] [sdap_account_expired_shadow]
> (0x0080): Shadow expire attribute not found. Access will be granted.
>
> But, there's no indication that shadowLastChange was checked.
>
> Looking at the source code (v1.8.2), I see that shadowExpire will be
> checked for the purpose of granting or denying access, but expiration of
> the password does not seem to be checked.
>
> Perhaps this has been addressed in a later version?
The reason why you see only checks for account expiration is that that's
what the ldap_account_expire_policy option is about.
I think Stephen misunderstood you and didn't realize you were looking
for enforcement of *password* expire policies when you are using ssh
keys to log in.
We currently do not have any checks in the code that would prevent
access if the password is expired and you use an authentication method
that is *not* password based.
I do understand why you may want that, so maybe you want to open a
Request For Enhancement ticket so we can track and prioritize
implementing this special check.
Of course we cannot provide this kind of check with every authentication
method, but if you have shadow attributes in your ldap server that
express this information we should be able to make it available in that
case.
However because the 'authentication' step is skipped with ssh-key auth
the only outcome you can expect is that access is denied if the password
is expired. We will not be able to present a password change prompt via
SSH, is this the outcome you would expect ?
Simo.
--
Simo Sorce * Red Hat, Inc * New York
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
The preferred behaviour would be to respond to sshd indicating that the
password has expired. Then, sshd could prompt the user and invoke
/bin/passwd. If that is not possible, giving the ability to deny access
would be an improvement over the current state.
Thanks,
--
Iain Morgan