[SSSD-users] Password expiration with public-key authentication

Simo Sorce simo at redhat.com
Thu Nov 29 19:44:17 UTC 2012


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



More information about the sssd-users mailing list