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

Iain Morgan Iain.Morgan at nasa.gov
Thu Nov 29 17:52:55 UTC 2012


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?

-- 
Iain Morgan


More information about the sssd-users mailing list