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.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 3:44 PM
To: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org>
Cc: 'Sumit Bose' <sb...@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.hi...@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' <sb...@redhat.com <mailto:sb...@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.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 6:31 AM
To: Sumit Bose <sb...@redhat.com <mailto:sb...@redhat.com> >
Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org> >; 'Sumit Bose'
<sb...@redhat.com <mailto:sb...@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 <sb...@redhat.com <mailto:sb...@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-le...@lists.fedorahosted.org

Reply via email to