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.
Thanks,
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.
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,
On Tue, Nov 27, 2012 at 02:01:48PM -0800, 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.
If I understand your question correctly you would like to see a password change dialog (Old password: ... New password: ... Retype new password: ---) even when using ssh with public-key authentication? If this is the case I would to ask you to fila an enhancement ticket to the sssd trac instance at https://fedorahosted.org/sssd/ and describe your use-case.
Currently sssd returns the corresponding PAM error code PAM_NEW_AUTHTOK_REQD only if an expired password was found during password based authentication and the PAM_ACCT_MGMT phase is purely used for access control. But as long as sssd can detect an expired password during PAM_ACCT_MGMT it would be possible to return PAM_NEW_AUTHTOK_REQD as well. Please note that this in not possible in all cases, e.g. if Kerberos authentication is used you typically can only detect that a password is expired by trying to authenticate with the correct password and check the responses form the KDC.
HTH
bye, Sumit
Thanks,
-- Iain Morgan _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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?
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.
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@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,
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@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?
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Iain Morgan -
Simo Sorce -
Stephen Gallagher -
Sumit Bose