KDB and referrals/aliases

[Nicolas Williams]

On Wed, Sep 02, 2009 at 02:44:19PM -0400, Greg Hudson wrote:
> Okay.  To re-summarize Luke's message:
> 
> 1. Currently we are not returning aliases in server lookups unless the
> client understands referrals (i.e. it set the canonicalize protocol
> flag).  This is unnecessarily limiting.

Yes, it is limiting.  Aliases should not require any protocol extensions
beyond RFC4120 to use.

> 2. The easiest way to change this is to abuse the
> KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY flag as an indication that the
> lookup is for a client principal.
> 
> 3. The above change would have the side effect of making kadmin's
> "getprinc" see aliases.  I'm not sure if this is a real concern.  If it

I think it's a legitimate concern that kadmin clients be able to
distinguish aliases from non-aliases.  Not that getprinc(alias) should
fail, but that it should tell you its canonical name; listprincs should
probably list only canonical names.

I think it'd be OK if old clients can't distinguish aliases, as long as
new ones can.  Preferably old clients should be able to distinguish
aliases.

> is, it could be addressed by adding new DAL interfaces for
> administrative operations.

Yes.

> 4. We could restructure the flags to make things clearer, but at a
> penalty to Novell (and theoretically to anyone else who has made a
> custom 1.7 back end).

Are there other solutions?  Can the KDC and kadmind remain compatible
with existing DBs (and not distinguish aliases in that case)?  What is
the interface stability of the DAL?  Would an incompatible change
justify a 1.8 release?

> I am okay with using comments to address the lack of clarity of (2),
> although it's disappointing.  I am okay with leaving (3) unsolved since
> I'm not sure it's any better for getprinc to fail on an alias name.

I don't think getprinc(alias) should fail in any case.  See above.

Nico
--