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

Dmitri Pal dpal at redhat.com
Thu Nov 29 22:48:45 UTC 2012


On 11/29/2012 03:35 PM, Iain Morgan wrote:
> 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,
>
And why is it needed?
If you authenticate with one credential - ssh key, but have another -
password and password is expired why you care about it? Is it ever used?
If it is never used then you are probably looking for the method to
expire and rotate your SSH keys. That should be some kind of central
policy and we can thing about what can be done in this field. If it is
used then when it is used (and only when it is used) the software should
prompt for the change.
What is wrong with such logic?


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/





More information about the sssd-users mailing list