krb5_sname_to_principal or LDAP/SASL/GSSAPI and reverse DNS

[Booker Bense]

On Thu, 10 Apr 2003, Nicolas Williams wrote:

> On Thu, Apr 10, 2003 at 03:52:35PM -0500, Steve Langasek wrote:
> > On Wed, Apr 09, 2003 at 11:29:23AM -0700, Nicolas Williams wrote:
> > > On Wed, Apr 09, 2003 at 01:55:58PM -0400, Sam Hartman wrote:
> > > > I don't want a global shared filesystem just because I have a shared
> > > > LDAP cluster.
> >
> > > > I understand the clusters you deal with tend to be physically located
> > > > in the same space and tend to share disks or at least filesystem.
> >
> > > > That is not the only type of cluster that exists.
> >
> > > Er, why do you cluster LDAP services?
> >
> > Because round-robin balancing at the application level is conspicuously
> > absent where LDAP is concerned, so clustering at the DNS level is often
> > the best option?
>
> One [quasi-]word: yuk.
>
> I don't believe that this sort of load balancing belongs in
> krb5_sname_to_principal().  Not remotely.

- It's already there, I believe the question is how to get rid
of it in a minimal way. You can believe this is evil all you
want, but unless kerberos supports this kind of load balancing
cleanly in some manner it's yet another reason to throw it on
the dustheap of nice ideas that just aren't practical...

>
> Especially if having such functionality conflicts with efforts to secure
> the principal name canonicalization (or, rather, with the efforts to get
> rid of princ canon without giving up on its utility).

- I don't see how this conflicts. Actually, if I remember
correctly LDAP uses GSSAPI in which there are undocumented
options to skip the krb5_sname_to_principal and just use
what I damn well tell you to use. Now all you need to do is
rewrite all your LDAP clients.

- Perhaps the short term way out of this dilemma is to document
those hidden GSSAPI options and provide handy switches to turn
them on/off in applications or even an evil runtime
configuration option in krb5.conf. Those applications not using
GSSAPI should just be dragged in the street and shot...

- Booker C. Bense

P.S. as you might infer I've spent the last few monthes dealing
with some software that desparately needs to be dragged into
the street and shot and it's made me even more cynical..