[Freeipa-devel] [PATCH] 877 prompt for current password

[Simo Sorce]

On Tue, 2011-09-27 at 14:59 -0400, Dmitri Pal wrote:
> On 09/27/2011 05:08 AM, Jakub Hrozek wrote:
> > On Mon, Sep 26, 2011 at 07:35:53PM -0400, Dmitri Pal wrote:
> >> On 09/23/2011 05:38 PM, Simo Sorce wrote:
> >>> On Fri, 2011-09-23 at 16:00 +0200, Martin Kosek wrote:
> >>>> On Mon, 2011-09-19 at 09:03 -0400, Rob Crittenden wrote:
> >>>>> Jan Cholasta wrote:
> >>>>>> On 16.9.2011 21:16, Rob Crittenden wrote:
> >>>>>>> Prompt for the current password when changing your own password using
> >>>>>>> ipa passwd.
> >>>>>>>
> >>>>>>> I had to jump through several hoops with this:
> >>>>>>>
> >>>>>>> - Added a new sortorder option so the Current password is prompted first
> >>>>>> IMO something like "before='password'" would be more readable and
> >>>>>> probably less error-prone than "sortorder=-1".
> >>>>> The params are sorted numerically based on whether they are required, 
> >>>>> have a default, etc. A negative value means it will appear first. This 
> >>>>> is intended to be generic enough without having to worry about nested 
> >>>>> resolution (A before B, B before C, C before A).
> >>>>>
> >>>>>>> - Pass a magic value for current_password if changing someone else's
> >>>>>>> password
> >>>>>>>
> >>>>>>> NOTE: This breaks the API for passwd. There is no way around it. I have
> >>>>>>> this as a minor update as it won't cause older clients to blow up too
> >>>>>>> badly, but their passwd command won't work.
> >>>>>>>
> >>>>>>> rob
> >>>>>>>
> >>>>>> Honza
> >>>>>>
> >>>> Generally, it works fine except for the case when user passes its own
> >>>> user name. Do we want to support the following way?
> >>>>
> >>>> # klist
> >>>> Ticket cache: FILE:/tmp/krb5cc_0
> >>>> Default principal: fbar at IDM.LAB.BOS.REDHAT.COM
> >>>>
> >>>> Valid starting     Expires            Service principal
> >>>> 09/23/11 09:48:05  09/24/11 09:48:05  krbtgt/IDM.LAB.BOS.REDHAT.COM at IDM.LAB.BOS.REDHAT.COM
> >>>>
> >>>> # ipa passwd fbar
> >>>> New Password: 
> >>>> Enter New Password again to verify: 
> >>>> ipa: ERROR: Insufficient access: Invalid credentials
> >>>>
> >>>> Maybe we could throw an error when user passes its own principal to ipa
> >>>> passwd command. After all, this argument is for changing _other_ user
> >>>> passwords.
> >>> Would it make sense to invoke kpasswd fbar in that case ?
> >>>
> >>> Simo.
> >>>
> >> That would bypass SSSD on the remote machine. Though we support other
> >> kerberos clients eventually we would prefer that all the authentications
> >> and ticket renewals are performed via SSSD. Is there any other way to do
> >> this or we do it as you suggest for now but in future expose the
> >> password change interface as a part of the SSSD DBUS interface? If so
> >> Stephen please add this use case to the interface design.
> >>
> >>  
> >>
> > I think kpasswd is OK in this particular case as you're invoking it on
> > the server anyway, so bypassing sssd's failover should be fine.
> >
> 
> I was not talking about failover. I was talking about the renewal and
> general tracking of the tickets and authentications. I was under the
> impression that SSSD would overtime become the recommended central
> kerberos auth gateway that would be tracking who authenticated, when,
> using what creadential and so on. Encoraging other methods deviates from
> this vision. The ipa cli can be installed on the remote system so it is
> not on server but SSSD will most likely be there and configured to use
> with IPA. Unless we want later on to switch ipa cli to talk to SSSD over
> DBUS for this use case.
> I am fine with kpasswd, I am just saying that when the SSSD DBUS
> interface is availble it should also expose password change interface
> and the ipa cli should take advantage of it. That is all.

We can also use the passwd program instead of kpasswd, the passwd
program will channel through PAM into SSSD.
But that relies on the machine you run it on to be configured to allow
logins locally I think, which may not be the case.

I think kpasswd is a perfectly fine fallback in this case and has less
chances to "break" as it uses less layers to get the job done.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York