regression due to referral realm

[Mark Phalan]

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

-M