Extensible kadm5 policies

[Russ Allbery]

Nico Williams <nico at cryptonector.com> writes:

> No, I think we have significant evidence that policies should be more
> complicated than just the password quality policies.  Ticket lifetimes
> is the example that Greg brought up.  "Supported enctypes" is the one
> that's causing me to bring this up.  New authz-data and pre-auth will
> almost certainly create the need for more policies.

I would love to be able to set some principal flags via a policy as well.
Things like disallow-forwardable and disallow-proxiable, for example, for
root instance principals.

> And no, I don't think that LDAP is the answer.  Sure, LDAP is *an*
> answer, but there are operations that LDAP can't model as modifications
> to objects -- mainly the password/key set/change operations, and the
> retrieve keys operation (since the keys are encrypted in the master
> key).

I'm also still very dubious that putting the KDC database in an LDAP
server is a good idea for most people.  That's a huge increase in
complexity, and introduces a lot of additional things that can go wrong.

We spend about half of a full-time staff member maintaining our LDAP
environment, possibly more, including handling things like database and
performance tuning, upgrades to new versions of OpenLDAP, weird
interactions with underlying libraries, ACL management, changing to
cn=config, weird load spikes, and so forth.  The KDCs require maybe five
hours a month.  The load profile isn't the same, of course, but I think
that speaks to complexity issues.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>