ldap principal aliases

[Greg Hudson]

On Sat, 2009-08-29 at 11:01 -0400, Chris wrote:
> Are there any known scenarios where forcing canonicalization on the KDC
> would be bad?

I'm not aware of any--in fact, I couldn't tell you with confidence why
our KDC is checking that flag for TGS requests without consultation with
others.  However, if you have old MIT Kerberos software on server
machines (in the sense of a Kerberos application server), you may run
into another problem:

Let's say host/aliasname is an alias for host/realname.  The client
performs a TGS request for host/aliasname service tickets, and gets a
host/aliasname service ticket encrypted in the key for host/realname.
Now the client presents this ticket to the server in an AP request,
saying it wants to authenticate to host/aliasname.

* With krb5 1.7.x, krb5_rd_req will ignore the stated target of the AP
request and look for any key in the keytab which can decode the
presented ticket.  It will find the host/realname key and succeed.

* With krb5 1.6.x and prior, the krb5_rd_req will look specifically for
a host/aliasname key in the keytab, and will fail if the keytab contains
only a host/realname entry.

You can work around this problem by storing host/aliasname entries in
the server keytab, although I'm not sure how easy the logistics of that
would be.  At that point you almost might as well use separate
principals for host/realname and host/aliasname.