[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel redhat com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]