regression due to referral realm
Mark.Phalan at Sun.COM
Wed Feb 11 06:00:51 EST 2009
On Wed, 2009-02-11 at 01:25 -0700, Shawn M Emery wrote:
> Nicolas Williams wrote:
> > On Tue, Feb 10, 2009 at 05:35:29PM -0500, Sam Hartman wrote:
> >>>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> >> Nicolas> On Tue, Feb 10, 2009 at 03:16:30PM -0500, Sam Hartman
> >> Nicolas> wrote:
> >> >> I have to agree with Tom here.
> >> Nicolas> Meaning what, specifically? That you think MIT should
> >> Nicolas> not accept a patch that does anything other than replace
> >> Nicolas> the null realm name with the default realm name?
> >> That MIT should assume that if you have a keytab you have a default
> >> realm name.
> >> I think that the proposed patch may be fine. I certainly am not objecting to it.
> > OK. I'll forward this comment to the maintainers of the smbadm join and
> > kclient commands.
> kclient populates the default realm so it would not be affected by
> this. In regards to the solution, I would prefer to search the keytab
> last to first. When transitioning realms (keeping old service keys),
> the new keys were appended to the keytab from what I remember.
This should be done consistently though throughout MIT Kerberos when
searching a keytab. My understanding is that currently MIT Kerberos
searches first-to-last. Either way my proposed patch just uses
krb5_kt_start_seq_get/krb5_kt_next_entry. Presumably the implementation
of those keytab funcs could be modified to return entries in the reverse
More information about the krbdev