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: f...@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....@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. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
