regression due to referral realm
Natalie.Li at Sun.COM
Wed Feb 11 11:18:25 EST 2009
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. Do you
> recall this as well with "smbadm join", Natalie?
Yes, I recalled seeing a problem when transitioning from one realm to
another. The problem seems to be that a new set of keytab entries with
different kvno for the same principal names are appended. So the new
ones will be last, and the first ones will become invalid. Yet, I
recalled the *INVALID* ones will be selected when one needs it. It'd be
better if libkrb5 search to the end of the keytab, always, picking the
*latest* keytab entry matching whatever is required.
More information about the krbdev