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

Iain Morgan Iain.Morgan at nasa.gov
Thu Nov 29 20:35:32 UTC 2012


On Thu, Nov 29, 2012 at 13:44:17 -0600, Simo Sorce wrote:
> 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 at 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


More information about the sssd-users mailing list