Unable to have KDC use different enctype for session/service key

[Ken Hornstein]

>    Ken> - Changing something on the KDC, which is fairly reasonable.
>
>No, it's not; you are encoding client configuration information into the KDC.

I realize that, and I'm willing to live with that in the short term.  It
comes down to a simple management issue; it's easier to have one knob in one
place rather than one knob in 5000 places.

>    Ken> - Changing something on 5000+ krb5.conf files scattered all
>    Ken> over creation, which is a screaming nightmare.  
>
>But you already have this issue.  You need to upgrade those clients to
>support 3des in the first place.  I suggest that you add to whatever
>process is allowing you to get new kinits out to clients the ability
>to get new krb5.confs out to clients.

If only it was that simple.

Old clients are easy; they simply don't request 3DES enctypes.  They get
a 3DES-encrypted service ticket, but they get a single-DES session key.
This works fine.

When we have _all_ new clients, again, everything is fine, because they
understand new enctypes.

Where I'm running into problems now is workstations that have been upgraded
to new client code, but they're using centrally-stored applications that
use older libraries.  Updating those applications is going to take a long
time.  And it's sort of a weird situation ... if it was on a per-machine
basis, yes, absolutely, I would agree 100% with you; make those changes
when you change the client code.  But this is a sort of site-wide thing,
which to me begs for a site-wide knob.

The situation I'm trying to avoid is having to do two upgrades; one when
I distribute new client code (which will happen in the near term, and
is unavoidable) and one when I get around to updating all of our central
applications (who knows when that is going to happen).  Upgrading clients
ends up being fairly painful for us, partially because we have a bunch
of machines not under our administrative control.

Another bit of practicality comes to mind; if for some reason I screw
up and I end up missing an application that needs to be updated, it's
easy to temporarily change the knob on the KDC, as opposed to having
to go back and modify all of the config files on the clients.

>    Ken> I'm missing something here; is there a reason why the session
>    Ken> key enctype should _NOT_ be adjustable on the KDC?  I mean,
>    Ken> it seems like the best solution (really, the only practical
>    Ken> solution).
>
>Yes.  Configuring enctypes on Kerberos is overly complex as is; we
>want to decrease that complexity not increase it.  Long term we are
>looking at removing some of the configuration options not adding more.

I do understand that ... but, dang it all, it still seems like this
is a necessary knob.  Maybe not necessary for everyone, but for some
people in our situation.

--Ken