Hello the list,
It's here: https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395
SSSD is not doing its job properly when a user has an expired password and an OTP token, and they should reset their password at the ssh prompt.
When a user has an expired password it should ignore the OTP token during password reset process, and then disconnect.
The condition where an expired or compromised temporary password is obtained by an unauthorised entity means that as long as the unauthorised entity does not have the OTP token secret, the worst they can do is reset your password. This condition is escaped when someone, either the user, a helpdesk agent, or an admin, resets the password to something the unauthorised entity doesn't know.
The case of the unauthorised entity having both the password and OTP token is already recognised as a compromised state, so the code doesn't need to protect us from that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 5:44 PM To: 'FreeIPA users list' freeipa-users@lists.fedorahosted.org Cc: 'Sumit Bose' sbose@redhat.com Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Progress,
We made Pam use kinit username when a user had an expired password, and this allowed users to reset passwords at the ssh prompt.
However passwd remains broken on all the hosts, regardless of their auth indicator.
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
_____
From: Aaron Hicks <aaron.hicks@nesi.org.nz mailto:aaron.hicks@nesi.org.nz
Sent: Thursday, November 23, 2017 4:25:12 PM To: 'FreeIPA users list' Cc: 'Sumit Bose' Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
The next bit of information is that the passwd command itself is broken when a user has a OTP token set.
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
These were with the user's valid-not-expired password, and with passwordOTPCODE
The Current Password: prompt fails.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 3:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
We've kept at this today and this is what we think we are seeing:
* Preauth is detecting that a user has an expired password and a token, so discards the token and just asks for password * Password check succeeds and hands to the password change process (maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth) * BUT the Current Password: check fails because it doesn't preauth to check if the password is expired * AND because the password is expired passwordOTPCODE is not valid either
Similarly, accounts with expired passwords can't authenticate against the API because their password is expired. Which would at least allow our customer management system to disable or delete their OTP token so they can reset their passwords.
In addition to this, users are not able to reset passwords at the ssh login on hosts where 2FA is not enabled either! So this seems to be narrowing down on the bits of pam and sssd uset to authenticate the password change process.
An interesting note is, kinit does not require OTPCODE.
Finally, no users do not have access to the FreeIPA web interface or a host without 2FA. The 2FA secured host is to be their lander node into our network.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 10:33 AM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the List,
A couple of new things to this problem, when a user has an expired password and a valid OTP token, the password reset process is broken on all machines at the ssh prompt. Even the ones that do not require 2FA.
Feedback so far form Sumit indicates this is incorrect behaviour.
As an attempt to get around this, I've tried adding a permission to the helpdesk role that would allow them to manage OTP tokens. I'll submit another thread on that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 6:31 AM To: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org >; 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hi Sumit,
I sent those to you directly as I wasn't comfortable posting them to the list.
Regards,
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
_____
From: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Sent: Wednesday, November 22, 2017 10:19:34 PM To: Aaron Hicks Cc: 'FreeIPA users list'; 'Sumit Bose' Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
Hi Sumit,
Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
ok, the PAM configuration looks good. Can you send me the PAM related messages form /var/log/secure or the journal which cover the failed attempt? And additionally the SSSD logs with debug_level=9 from the same time. Most important would be sssd_pam.log, sssd_domain.name.log and krb5_child-log.
bye, Sumit
On Fri, Nov 24, 2017 at 04:57:01PM +1300, Aaron Hicks via FreeIPA-users wrote:
Hello the list,
It's here: https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395
SSSD is not doing its job properly when a user has an expired password and an OTP token, and they should reset their password at the ssh prompt.
Yes, SSSD does no behave well with OTP and an expired password and I agree with you analysis below. The area of code you mentioned above is not related because it is a special path only used during password migration (user was migrated from LDAP with the LDAP password hash but no Kerberos keys).
Would you mind to open a ticket on https://pagure.io/SSSD/sssd/issues for this?
bye, Sumit
When a user has an expired password it should ignore the OTP token during password reset process, and then disconnect.
The condition where an expired or compromised temporary password is obtained by an unauthorised entity means that as long as the unauthorised entity does not have the OTP token secret, the worst they can do is reset your password. This condition is escaped when someone, either the user, a helpdesk agent, or an admin, resets the password to something the unauthorised entity doesn't know.
The case of the unauthorised entity having both the password and OTP token is already recognised as a compromised state, so the code doesn't need to protect us from that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 5:44 PM To: 'FreeIPA users list' freeipa-users@lists.fedorahosted.org Cc: 'Sumit Bose' sbose@redhat.com Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Progress,
We made Pam use kinit username when a user had an expired password, and this allowed users to reset passwords at the ssh prompt.
However passwd remains broken on all the hosts, regardless of their auth indicator.
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
From: Aaron Hicks <aaron.hicks@nesi.org.nz mailto:aaron.hicks@nesi.org.nz
Sent: Thursday, November 23, 2017 4:25:12 PM To: 'FreeIPA users list' Cc: 'Sumit Bose' Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
The next bit of information is that the passwd command itself is broken when a user has a OTP token set.
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
These were with the user's valid-not-expired password, and with passwordOTPCODE
The Current Password: prompt fails.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 3:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
We've kept at this today and this is what we think we are seeing:
- Preauth is detecting that a user has an expired password and a
token, so discards the token and just asks for password
- Password check succeeds and hands to the password change process
(maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth)
- BUT the Current Password: check fails because it doesn't preauth to
check if the password is expired
- AND because the password is expired passwordOTPCODE is not valid
either
Similarly, accounts with expired passwords can't authenticate against the API because their password is expired. Which would at least allow our customer management system to disable or delete their OTP token so they can reset their passwords.
In addition to this, users are not able to reset passwords at the ssh login on hosts where 2FA is not enabled either! So this seems to be narrowing down on the bits of pam and sssd uset to authenticate the password change process.
An interesting note is, kinit does not require OTPCODE.
Finally, no users do not have access to the FreeIPA web interface or a host without 2FA. The 2FA secured host is to be their lander node into our network.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 10:33 AM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the List,
A couple of new things to this problem, when a user has an expired password and a valid OTP token, the password reset process is broken on all machines at the ssh prompt. Even the ones that do not require 2FA.
Feedback so far form Sumit indicates this is incorrect behaviour.
As an attempt to get around this, I've tried adding a permission to the helpdesk role that would allow them to manage OTP tokens. I'll submit another thread on that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 6:31 AM To: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org >; 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hi Sumit,
I sent those to you directly as I wasn't comfortable posting them to the list.
Regards,
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
From: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Sent: Wednesday, November 22, 2017 10:19:34 PM To: Aaron Hicks Cc: 'FreeIPA users list'; 'Sumit Bose' Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
Hi Sumit,
Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
ok, the PAM configuration looks good. Can you send me the PAM related messages form /var/log/secure or the journal which cover the failed attempt? And additionally the SSSD logs with debug_level=9 from the same time. Most important would be sssd_pam.log, sssd_domain.name.log and krb5_child-log.
bye, Sumit
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On pe, 24 marras 2017, Sumit Bose via FreeIPA-users wrote:
On Fri, Nov 24, 2017 at 04:57:01PM +1300, Aaron Hicks via FreeIPA-users wrote:
Hello the list,
It's here: https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395
SSSD is not doing its job properly when a user has an expired password and an OTP token, and they should reset their password at the ssh prompt.
Yes, SSSD does no behave well with OTP and an expired password and I agree with you analysis below. The area of code you mentioned above is not related because it is a special path only used during password migration (user was migrated from LDAP with the LDAP password hash but no Kerberos keys).
Would you mind to open a ticket on https://pagure.io/SSSD/sssd/issues for this?
https://pagure.io/SSSD/sssd/issue/3585
Hello the List,
We have a workaround, but it is not entirely satisfactory, we change /etc/pam.d/password-auth-ac
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok
#password sufficient pam_sss.so use_authtok
password sufficient pam_krb5.so chpw_prompt=true use_authok # fix for password reset
This allows a user to reset a password if expired, but gives them shell rather than disconnecting. New ssh connections now require 2FA.
We're now quite certain it's a bug in sssd & pam_sss
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Friday, 24 November 2017 4:57 PM To: 'FreeIPA users list' freeipa-users@lists.fedorahosted.org Cc: 'Sumit Bose' sbose@redhat.com Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
It's here: https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395
SSSD is not doing its job properly when a user has an expired password and an OTP token, and they should reset their password at the ssh prompt.
When a user has an expired password it should ignore the OTP token during password reset process, and then disconnect.
The condition where an expired or compromised temporary password is obtained by an unauthorised entity means that as long as the unauthorised entity does not have the OTP token secret, the worst they can do is reset your password. This condition is escaped when someone, either the user, a helpdesk agent, or an admin, resets the password to something the unauthorised entity doesn't know.
The case of the unauthorised entity having both the password and OTP token is already recognised as a compromised state, so the code doesn't need to protect us from that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 5:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Progress,
We made Pam use kinit username when a user had an expired password, and this allowed users to reset passwords at the ssh prompt.
However passwd remains broken on all the hosts, regardless of their auth indicator.
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
_____
From: Aaron Hicks <aaron.hicks@nesi.org.nz mailto:aaron.hicks@nesi.org.nz
Sent: Thursday, November 23, 2017 4:25:12 PM To: 'FreeIPA users list' Cc: 'Sumit Bose' Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
The next bit of information is that the passwd command itself is broken when a user has a OTP token set.
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
$ passwd
Changing password for user otpuser1.
Current Password:
passwd: Authentication token manipulation error
These were with the user's valid-not-expired password, and with passwordOTPCODE
The Current Password: prompt fails.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 3:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
We've kept at this today and this is what we think we are seeing:
* Preauth is detecting that a user has an expired password and a token, so discards the token and just asks for password * Password check succeeds and hands to the password change process (maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth) * BUT the Current Password: check fails because it doesn't preauth to check if the password is expired * AND because the password is expired passwordOTPCODE is not valid either
Similarly, accounts with expired passwords can't authenticate against the API because their password is expired. Which would at least allow our customer management system to disable or delete their OTP token so they can reset their passwords.
In addition to this, users are not able to reset passwords at the ssh login on hosts where 2FA is not enabled either! So this seems to be narrowing down on the bits of pam and sssd uset to authenticate the password change process.
An interesting note is, kinit does not require OTPCODE.
Finally, no users do not have access to the FreeIPA web interface or a host without 2FA. The 2FA secured host is to be their lander node into our network.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 10:33 AM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org > Cc: 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the List,
A couple of new things to this problem, when a user has an expired password and a valid OTP token, the password reset process is broken on all machines at the ssh prompt. Even the ones that do not require 2FA.
Feedback so far form Sumit indicates this is incorrect behaviour.
As an attempt to get around this, I've tried adding a permission to the helpdesk role that would allow them to manage OTP tokens. I'll submit another thread on that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 6:31 AM To: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org mailto:freeipa-users@lists.fedorahosted.org >; 'Sumit Bose' <sbose@redhat.com mailto:sbose@redhat.com > Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hi Sumit,
I sent those to you directly as I wasn't comfortable posting them to the list.
Regards,
Aaron
Get Outlook for iOS https://aka.ms/o0ukef
_____
From: Sumit Bose <sbose@redhat.com mailto:sbose@redhat.com > Sent: Wednesday, November 22, 2017 10:19:34 PM To: Aaron Hicks Cc: 'FreeIPA users list'; 'Sumit Bose' Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
Hi Sumit,
Here is /etc/pam.d/password-auth I missed that it was an include, an that
you wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
ok, the PAM configuration looks good. Can you send me the PAM related messages form /var/log/secure or the journal which cover the failed attempt? And additionally the SSSD logs with debug_level=9 from the same time. Most important would be sssd_pam.log, sssd_domain.name.log and krb5_child-log.
bye, Sumit
Oh, this requires the pam_krb5 package :P
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Aaron Hicks aaron.hicks@nesi.org.nz Sent: Tuesday, November 28, 2017 2:28:15 PM To: 'FreeIPA users list' Cc: 'Sumit Bose' Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the List,
We have a workaround, but it is not entirely satisfactory, we change /etc/pam.d/password-auth-ac
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow try_first_pass use_authtok
#password sufficient pam_sss.so use_authtok
password sufficient pam_krb5.so chpw_prompt=true use_authok # fix for password reset
This allows a user to reset a password if expired, but gives them shell rather than disconnecting. New ssh connections now require 2FA.
We’re now quite certain it’s a bug in sssd & pam_sss
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Friday, 24 November 2017 4:57 PM To: 'FreeIPA users list' freeipa-users@lists.fedorahosted.org Cc: 'Sumit Bose' sbose@redhat.com Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
It’s here: https://pagure.io/SSSD/sssd/blob/master/f/src/providers/ipa/ipa_auth.c#_395
SSSD is not doing its job properly when a user has an expired password and an OTP token, and they should reset their password at the ssh prompt.
When a user has an expired password it should ignore the OTP token during password reset process, and then disconnect.
The condition where an expired or compromised temporary password is obtained by an unauthorised entity means that as long as the unauthorised entity does not have the OTP token secret, the worst they can do is reset your password. This condition is escaped when someone, either the user, a helpdesk agent, or an admin, resets the password to something the unauthorised entity doesn’t know.
The case of the unauthorised entity having both the password and OTP token is already recognised as a compromised state, so the code doesn’t need to protect us from that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 5:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> Cc: 'Sumit Bose' <sbose@redhat.commailto:sbose@redhat.com> Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Progress,
We made Pam use kinit username when a user had an expired password, and this allowed users to reset passwords at the ssh prompt.
However passwd remains broken on all the hosts, regardless of their auth indicator.
Aaron
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Aaron Hicks <aaron.hicks@nesi.org.nzmailto:aaron.hicks@nesi.org.nz> Sent: Thursday, November 23, 2017 4:25:12 PM To: 'FreeIPA users list' Cc: 'Sumit Bose' Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
The next bit of information is that the passwd command itself is broken when a user has a OTP token set.
$ passwd Changing password for user otpuser1. Current Password: passwd: Authentication token manipulation error $ passwd Changing password for user otpuser1. Current Password: passwd: Authentication token manipulation error $ passwd Changing password for user otpuser1. Current Password: passwd: Authentication token manipulation error $ passwd Changing password for user otpuser1. Current Password: passwd: Authentication token manipulation error
These were with the user’s valid-not-expired password, and with passwordOTPCODE
The Current Password: prompt fails.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 3:44 PM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> Cc: 'Sumit Bose' <sbose@redhat.commailto:sbose@redhat.com> Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the list,
We’ve kept at this today and this is what we think we are seeing:
* Preauth is detecting that a user has an expired password and a token, so discards the token and just asks for password * Password check succeeds and hands to the password change process (maybe using /etc/pam.d/passwd and /etc/pam.d/system-auth) * BUT the Current Password: check fails because it doesn’t preauth to check if the password is expired * AND because the password is expired passwordOTPCODE is not valid either
Similarly, accounts with expired passwords can’t authenticate against the API because their password is expired. Which would at least allow our customer management system to disable or delete their OTP token so they can reset their passwords.
In addition to this, users are not able to reset passwords at the ssh login on hosts where 2FA is not enabled either! So this seems to be narrowing down on the bits of pam and sssd uset to authenticate the password change process.
An interesting note is, kinit does not require OTPCODE.
Finally, no users do not have access to the FreeIPA web interface or a host without 2FA. The 2FA secured host is to be their lander node into our network.
Regards,
Aaron From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 10:33 AM To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org> Cc: 'Sumit Bose' <sbose@redhat.commailto:sbose@redhat.com> Subject: RE: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hello the List,
A couple of new things to this problem, when a user has an expired password and a valid OTP token, the password reset process is broken on all machines at the ssh prompt. Even the ones that do not require 2FA.
Feedback so far form Sumit indicates this is incorrect behaviour.
As an attempt to get around this, I’ve tried adding a permission to the helpdesk role that would allow them to manage OTP tokens. I’ll submit another thread on that.
Regards,
Aaron
From: Aaron Hicks [mailto:aaron.hicks@nesi.org.nz] Sent: Thursday, 23 November 2017 6:31 AM To: Sumit Bose <sbose@redhat.commailto:sbose@redhat.com> Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.orgmailto:freeipa-users@lists.fedorahosted.org>; 'Sumit Bose' <sbose@redhat.commailto:sbose@redhat.com> Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
Hi Sumit,
I sent those to you directly as I wasn’t comfortable posting them to the list.
Regards,
Aaron
Get Outlook for iOShttps://aka.ms/o0ukef ________________________________ From: Sumit Bose <sbose@redhat.commailto:sbose@redhat.com> Sent: Wednesday, November 22, 2017 10:19:34 PM To: Aaron Hicks Cc: 'FreeIPA users list'; 'Sumit Bose' Subject: Re: [Freeipa-users] Re: Expired passwords and generating an OTP token
On Wed, Nov 22, 2017 at 09:21:52PM +1300, Aaron Hicks wrote:
Hi Sumit,
Here is /etc/pam.d/password-auth I missed that it was an include, an that you wanted it too, again it's as installed bt CentOS 7.4 and ipa-client-install
ok, the PAM configuration looks good. Can you send me the PAM related messages form /var/log/secure or the journal which cover the failed attempt? And additionally the SSSD logs with debug_level=9 from the same time. Most important would be sssd_pam.log, sssd_domain.name.log and krb5_child-log.
bye, Sumit
freeipa-users@lists.fedorahosted.org
-
Aaron Hicks -
Alexander Bokovoy -
Sumit Bose