[36949] in Kerberos

home help back first fref pref prev next nref lref last post

Re: kadm5_hook rename

daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon May 4 13:22:38 2015

Message-ID: <5547AAC7.1060303@mit.edu>
Date: Mon, 04 May 2015 13:22:15 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: John Hascall <john@iastate.edu>, kerberos@mit.edu
In-Reply-To: <CADCx5Mqrm0vtZnsTuE6kFO=HHfNM=f0JcXZaQe0Cxq-G50Z4AA@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

This thread might be better suited for krbdev@mit.edu, but I'll leave it
here.

On 05/02/2015 10:57 AM, John Hascall wrote:
> Is there a reason why the kadm5_hook interface does not seem to have any
> support for a principal "rename" operation?

An oversight, I think.  The rename operation was added a few months
after the kadm5_hook interface, based on patches which predated that
interface.  It looks like I did the integration work and didn't notice
the missing piece.

I will file a ticket, and will create a pull request from your patch.
(Almost all MIT krb5 changes go through github.com/krb5/krb5 pull
requests, but we can create pull requests for patches submitted in other
ways.)

> Because we do bi-directional password sync (MIT KDC <--> WinAD KDC),
> we need a way to prevent an endless loop of the same password change going
> around and around forever.

I don't have a ready answer for this, so I will file a ticket.  A a
parameter for the invoking principal wouldn't be unreasonable, but
adding one for all kadm5_hook interfaces would require a lot of churn at
this point.  Adding it just for the chpass operation might not be so bad.
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post