[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Oh, this requires the pam_krb5 package :P

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Aaron Hicks <aaron.hi...@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



passwordrequisite pam_pwquality.so try_first_pass local_users_only 
retry=3 authtok_type=

passwordsufficientpam_unix.so sha512 shadow try_first_pass use_authtok

#passwordsufficientpam_sss.so use_authtok

passwordsufficientpam_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.hi...@nesi.org.nz]
Sent: Friday, 24 November 2017 4:57 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,

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.hi...@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' <sb...@redhat.com<mailto:sb...@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.hi...@nesi.org.nz<mailto:aaron.hi...@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.hi...@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' <sb...@redhat.com<mailto: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 O

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

We have a workaround, but it is not entirely satisfactory, we change
/etc/pam.d/password-auth-ac

 

passwordrequisite pam_pwquality.so try_first_pass local_users_only
retry=3 authtok_type=

passwordsufficientpam_unix.so sha512 shadow try_first_pass
use_authtok

#passwordsufficientpam_sss.so use_authtok

passwordsufficientpam_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.hi...@nesi.org.nz] 
Sent: Friday, 24 November 2017 4:57 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,

 

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.hi...@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' <sb...@redhat.com <mailto:sb...@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.hi...@nesi.org.nz <mailto:aaron.hi...@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.hi...@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' <sb...@redhat.com <mailto: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 p

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Alexander Bokovoy via FreeIPA-users]

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

--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Sumit Bose via FreeIPA-users]

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.hi...@nesi.org.nz] 
> Sent: Thursday, 23 November 2017 5: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
> 
>  
> 
> 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.hi...@nesi.org.nz <mailto:aaron.hi...@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.hi...@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' <sb...@redhat.com <mailto: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
&

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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.hi...@nesi.org.nz] 
Sent: Thursday, 23 November 2017 5: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

 

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.hi...@nesi.org.nz <mailto:aaron.hi...@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.hi...@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' <sb...@redhat.com <mailto: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 al

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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>
Cc: 'Sumit Bose' <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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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>
Cc: 'FreeIPA users list' <freeipa-users@lists.fedorahosted.org>; 'Sumit
Bose' <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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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>
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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Sumit Bose via FreeIPA-users]

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

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

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

[root@hpch2fa01 pam.d]# cat password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
authrequired  pam_env.so
authrequired  pam_faildelay.so delay=200
auth[default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 
quiet
auth[default=1 ignore=ignore success=ok] pam_localuser.so
authsufficientpam_unix.so nullok try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

account required  pam_unix.so
account sufficientpam_localuser.so
account sufficientpam_succeed_if.so uid < 1000 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required  pam_permit.so

passwordrequisite pam_pwquality.so try_first_pass local_users_only 
retry=3 authtok_type=
passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass 
use_authtok
passwordsufficientpam_sss.so use_authtok


passwordrequired  pam_deny.so

session optional  pam_keyinit.so revoke
session required  pam_limits.so
-session optional  pam_systemd.so
session optional  pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet 
use_uid
session required  pam_unix.so
session optional  pam_sss.so

-Original Message-
From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Wednesday, 22 November 2017 9:19 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

Hi Sumit,

The pam.d configuration is as configured by the CentOS 7.4 install and running 
ipa-client-install. 

Here's the content of /etc/pam.d/sshd

[root@hpch2fa01 ~]# cd /etc/pam.d
[root@hpch2fa01 pam.d]# cat sshd
#%PAM-1.0
auth   required pam_sepermit.so
auth   substack password-auth
auth   include  postlogin
# Used with polkit to reauthorize users in remote sessions
-auth  optional pam_reauthorize.so prepare
accountrequired pam_nologin.so
accountinclude  password-auth
password   include  password-auth
# pam_selinux.so close should be the first session rule
sessionrequired pam_selinux.so close
sessionrequired pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the 
user context
sessionrequired pam_selinux.so open env_params
sessionrequired pam_namespace.so
sessionoptional pam_keyinit.so force revoke
sessioninclude  password-auth
sessioninclude  postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional pam_reauthorize.so prepare

We also added one line to /etc/ssh/sshd, otherwise it's as configured by the 
CentOS 7.4 install and running ipa-client-install

AuthenticationMethods keyboard-interactive

It'd be nice if there's a simple config fix for this, and I recommend it's 
worked into the ipa-client-install helper script or authconfig.

Regards,

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users [mailto:freeipa-users@lists.fedorahosted.org]
Sent: Wednesday, 22 November 2017 8:11 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose <sb...@redhat.com>
Subject: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 05:16:05PM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the List,
> 
>  
> 
> This turned out to be a workflow issue, we still have a problem but 
> this first use case works.
> 
>  
> 
> In the case of a user with an invalid password (none or expired) with 
> no OTP token they can reset their password and ask IPA to create an 
> OTP token for them.
> 
>  
> 
> 1.Helpdesk agent uses FreeIPA API passwd method to issue a temporary
> password and pass it to the user
> 2.User uses ssh to login to 2FA host
> 3.SSH forces user through the reset password process and closes
> connection
> 4.User is not able to login without a OTP Token. A correct result.
> 5.User uses FreeIPA API otptoken-add method with new password to
> generate & receive OTP token
> 6.User is now able to SSH with password + OTP token.
> 
>  
> 
> What isn't working is the case where a user has an invalid token (non, 
> expired, or just reset) and a valid OTP token.
> 
>  
> 
> 1.(Optional, but puts user into required state) Helpdesk agent uses
> FreeIPA API passwd method to issue a temporary passwor

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi Sumit,

The pam.d configuration is as configured by the CentOS 7.4 install and running 
ipa-client-install. 

Here's the content of /etc/pam.d/sshd

[root@hpch2fa01 ~]# cd /etc/pam.d
[root@hpch2fa01 pam.d]# cat sshd
#%PAM-1.0
auth   required pam_sepermit.so
auth   substack password-auth
auth   include  postlogin
# Used with polkit to reauthorize users in remote sessions
-auth  optional pam_reauthorize.so prepare
accountrequired pam_nologin.so
accountinclude  password-auth
password   include  password-auth
# pam_selinux.so close should be the first session rule
sessionrequired pam_selinux.so close
sessionrequired pam_loginuid.so
# pam_selinux.so open should only be followed by sessions to be executed in the 
user context
sessionrequired pam_selinux.so open env_params
sessionrequired pam_namespace.so
sessionoptional pam_keyinit.so force revoke
sessioninclude  password-auth
sessioninclude  postlogin
# Used with polkit to reauthorize users in remote sessions
-session   optional pam_reauthorize.so prepare

We also added one line to /etc/ssh/sshd, otherwise it's as configured by the 
CentOS 7.4 install and running ipa-client-install

AuthenticationMethods keyboard-interactive

It'd be nice if there's a simple config fix for this, and I recommend it's 
worked into the ipa-client-install helper script or authconfig.

Regards,

Aaron

-Original Message-
From: Sumit Bose via FreeIPA-users 
[mailto:freeipa-users@lists.fedorahosted.org] 
Sent: Wednesday, 22 November 2017 8:11 PM
To: freeipa-users@lists.fedorahosted.org
Cc: Sumit Bose <sb...@redhat.com>
Subject: [Freeipa-users] Re: Expired passwords and generating an OTP token

On Wed, Nov 22, 2017 at 05:16:05PM +1300, Aaron Hicks via FreeIPA-users wrote:
> Hello the List,
> 
>  
> 
> This turned out to be a workflow issue, we still have a problem but 
> this first use case works.
> 
>  
> 
> In the case of a user with an invalid password (none or expired) with 
> no OTP token they can reset their password and ask IPA to create an 
> OTP token for them.
> 
>  
> 
> 1.Helpdesk agent uses FreeIPA API passwd method to issue a temporary
> password and pass it to the user
> 2.User uses ssh to login to 2FA host
> 3.SSH forces user through the reset password process and closes
> connection
> 4.User is not able to login without a OTP Token. A correct result.
> 5.User uses FreeIPA API otptoken-add method with new password to
> generate & receive OTP token
> 6.User is now able to SSH with password + OTP token.
> 
>  
> 
> What isn't working is the case where a user has an invalid token (non, 
> expired, or just reset) and a valid OTP token.
> 
>  
> 
> 1.(Optional, but puts user into required state) Helpdesk agent uses
> FreeIPA API passwd method to issue a temporary password and pass it to 
> the user
> 2.User uses ssh to login to 2FA host, which asks for temporary
> password.
> 3.SSH forces user through reser password process and closes
> connection.
> 4.User is now able to SSH with password + OTP poken
> 
>  
> 
> In this case step 2 fails. The reset password process looks like this:

How does your sshd PAM configuration looks like, e.g. /etc/pam.d/sshd (and 
included files).

bye,
Sumit

> 
>  
> 
> login as: username
> 
> Using keyboard-interactive authentication.
> 
> Password:
> 
> Access denied
> 
> Using keyboard-interactive authentication.
> 
> Password:
> 
> Using keyboard-interactive authentication.
> 
> Password expired. Change your password now. 
> 
> Current Password:
> 
> Access denied
> 
>  
> 
> The change password process fails.
> 
>  
> 
> However, if we disable or delete their OTP token (which requires 
> FreeIPA admin, not helpdesk role) they're able to reset their 
> password. We don't want to have to give admin rights to the helpdesk agent 
> for this.
> 
>  
> 
> This is also complicated by that the FreeIPA API changes behaviour:
> 
> * With an expired/password user can not connect to the API, even to do
> passwd to reset password
> * With an OTP token, users have to use passwordOTPCODE to access the
> API, which means they can't manage their otptoken if they've lost it 
> or want to disable it so they can reset their password because they 
> forgot it,  or delete it.
> 
>  
> 
> Is there a way of allowing users in the helpdesk group/role to be able 
> to disable/enable or delete OTP tokens? They don't need to see the 
> content, just allow users to restart the password and token request process.
> 
>  
> 
> Is there a fix for the above workflow to allow a user with an OTP 
> 

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hi the list.

 

.I'd consider createing a permission with permission-add, but there is no
token object type.

 

[hicksaw@hpch2fa02 ~]$ ipa permission-add mangage-otptoken --right=all
--bindtype=permission --type=token

ipa: ERROR: invalid 'type': "token" is not an object type

 

Even though ipatoken is a valid objectclass

 

Regards,

 

Aaron

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Wednesday, 22 November 2017 5:16 PM
To: 'freeipa-users@lists.fedorahosted.org'

Subject: RE: Expired passwords and generating an OTP token

 

Hello the List,

 

This turned out to be a workflow issue, we still have a problem but this
first use case works.

 

In the case of a user with an invalid password (none or expired) with no OTP
token they can reset their password and ask IPA to create an OTP token for
them.

 

1.  Helpdesk agent uses FreeIPA API passwd method to issue a temporary
password and pass it to the user
2.  User uses ssh to login to 2FA host
3.  SSH forces user through the reset password process and closes
connection
4.  User is not able to login without a OTP Token. A correct result.
5.  User uses FreeIPA API otptoken-add method with new password to
generate & receive OTP token
6.  User is now able to SSH with password + OTP token.

 

What isn't working is the case where a user has an invalid token (non,
expired, or just reset) and a valid OTP token.

 

1.  (Optional, but puts user into required state) Helpdesk agent uses
FreeIPA API passwd method to issue a temporary password and pass it to the
user
2.  User uses ssh to login to 2FA host, which asks for temporary
password.
3.  SSH forces user through reser password process and closes
connection.
4.  User is now able to SSH with password + OTP poken

 

In this case step 2 fails. The reset password process looks like this:

 

login as: username

Using keyboard-interactive authentication.

Password:

Access denied 

Using keyboard-interactive authentication.

Password:

Using keyboard-interactive authentication.

Password expired. Change your password now. 

Current Password:

Access denied 

 

The change password process fails.

 

However, if we disable or delete their OTP token (which requires FreeIPA
admin, not helpdesk role) they're able to reset their password. We don't
want to have to give admin rights to the helpdesk agent for this.

 

This is also complicated by that the FreeIPA API changes behaviour:

*   With an expired/password user can not connect to the API, even to do
passwd to reset password
*   With an OTP token, users have to use passwordOTPCODE to access the
API, which means they can't manage their otptoken if they've lost it or want
to disable it so they can reset their password because they forgot it,  or
delete it.

 

Is there a way of allowing users in the helpdesk group/role to be able to
disable/enable or delete OTP tokens? They don't need to see the content,
just allow users to restart the password and token request process.

 

Is there a fix for the above workflow to allow a user with an OTP token to
reset their password?

 

Regards,

 

Aaron Hicks

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 6:22 PM
To: freeipa-users@lists.fedorahosted.org
 
Subject: Expired passwords and generating an OTP token

 

Hello the list,

 

I think this is the last thing to make our terrible user management model
work.

 

With a helpdesk role via the REST API we can reset a users password, which
is expired, because this is the right thing to do.

 

These users are expected to log into a node with 2FA using an OTP token
generated by FreeIPA. This works if a user has a valid password and a token.
This is the only machine they have access to, as it's they lander node. They
can not reach the FreeIPA web interface. They can use the FreeIPA API via
our customer management system (CMS) either as them self or as a helpdek
agent on their behalf. The CMS auth is SAML via federated shibboleth, so
does not use our FreeIPA credentials.

 

However, we have few use cases we need to work: 

 

Can a user generate an OTP token when their password is expired?

 

Can a a user reset their password when they do not have an OTP token?

 

Can a user reset their password when they can't log in to get the secret
from thier OTP token?

 

I think the shortest routes would be:

 

- if a user could reset an expired password via the FreeIPA API, then use
the otptoken_add method to create one all via our CMS.

 

- if a user could reset thier password at the ssh login prompt if they have
no token or don't have thier token. Then add a token via our CMS.

 

 

Regards,

 

Aaron

 

Get Outlook for iOS  

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 

[Freeipa-users] Re: Expired passwords and generating an OTP token

[Aaron Hicks via FreeIPA-users]

Hello the List,

 

This turned out to be a workflow issue, we still have a problem but this
first use case works.

 

In the case of a user with an invalid password (none or expired) with no OTP
token they can reset their password and ask IPA to create an OTP token for
them.

 

1.  Helpdesk agent uses FreeIPA API passwd method to issue a temporary
password and pass it to the user
2.  User uses ssh to login to 2FA host
3.  SSH forces user through the reset password process and closes
connection
4.  User is not able to login without a OTP Token. A correct result.
5.  User uses FreeIPA API otptoken-add method with new password to
generate & receive OTP token
6.  User is now able to SSH with password + OTP token.

 

What isn't working is the case where a user has an invalid token (non,
expired, or just reset) and a valid OTP token.

 

1.  (Optional, but puts user into required state) Helpdesk agent uses
FreeIPA API passwd method to issue a temporary password and pass it to the
user
2.  User uses ssh to login to 2FA host, which asks for temporary
password.
3.  SSH forces user through reser password process and closes
connection.
4.  User is now able to SSH with password + OTP poken

 

In this case step 2 fails. The reset password process looks like this:

 

login as: username

Using keyboard-interactive authentication.

Password:

Access denied 

Using keyboard-interactive authentication.

Password:

Using keyboard-interactive authentication.

Password expired. Change your password now. 

Current Password:

Access denied 

 

The change password process fails.

 

However, if we disable or delete their OTP token (which requires FreeIPA
admin, not helpdesk role) they're able to reset their password. We don't
want to have to give admin rights to the helpdesk agent for this.

 

This is also complicated by that the FreeIPA API changes behaviour:

*   With an expired/password user can not connect to the API, even to do
passwd to reset password
*   With an OTP token, users have to use passwordOTPCODE to access the
API, which means they can't manage their otptoken if they've lost it or want
to disable it so they can reset their password because they forgot it,  or
delete it.

 

Is there a way of allowing users in the helpdesk group/role to be able to
disable/enable or delete OTP tokens? They don't need to see the content,
just allow users to restart the password and token request process.

 

Is there a fix for the above workflow to allow a user with an OTP token to
reset their password?

 

Regards,

 

Aaron Hicks

 

From: Aaron Hicks [mailto:aaron.hi...@nesi.org.nz] 
Sent: Tuesday, 21 November 2017 6:22 PM
To: freeipa-users@lists.fedorahosted.org
Subject: Expired passwords and generating an OTP token

 

Hello the list,

 

I think this is the last thing to make our terrible user management model
work.

 

With a helpdesk role via the REST API we can reset a users password, which
is expired, because this is the right thing to do.

 

These users are expected to log into a node with 2FA using an OTP token
generated by FreeIPA. This works if a user has a valid password and a token.
This is the only machine they have access to, as it's they lander node. They
can not reach the FreeIPA web interface. They can use the FreeIPA API via
our customer management system (CMS) either as them self or as a helpdek
agent on their behalf. The CMS auth is SAML via federated shibboleth, so
does not use our FreeIPA credentials.

 

However, we have few use cases we need to work: 

 

Can a user generate an OTP token when their password is expired?

 

Can a a user reset their password when they do not have an OTP token?

 

Can a user reset their password when they can't log in to get the secret
from thier OTP token?

 

I think the shortest routes would be:

 

- if a user could reset an expired password via the FreeIPA API, then use
the otptoken_add method to create one all via our CMS.

 

- if a user could reset thier password at the ssh login prompt if they have
no token or don't have thier token. Then add a token via our CMS.

 

 

Regards,

 

Aaron

 

Get Outlook for iOS  

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org