Extensible kadm5 policies

[Nico Williams]

This too is getting far afield, but I'm willing to consider tighter
coupling of the KDC with other infrastructure services, or at least
protocols, and I think that some aspects of the Windows security
architecture are superior to the traditional Unix competition (for
example: SIDs).  But I really wish that a) we had a better schema, and
b) used a relational (or OO relational) DB.

Also, Roland convinces me that a model where the master LDAP/SQL DB is
dumped/synced to a faster and simpler DB like bdb is a better model
for those who want to marry LDAP (or SQL) to the KDC.

Beyond that, the option to stick to a simple DB is important to many
in the community.  And given a multiplicty of KDB backends, a decent,
generic admin API is highly desirable (and Heimdal shows that such a
thing is certainly feasible!).  A generic admin protocol is only
needed for some backends, but it's useful nonetheless (not least given
the lack of extended LDAP ops for Kerberos key/password changes, nor
key extraction, which, in any case, would be difficult to implement in
deployments where the KDC and the LDAP DS are not tightly coupled such
that the DS does nt have the KDB master keys).

The point: we need a decent, stable, generic kadmin API and protocol.
It's about time we had one.  Maybe we should settle on Russ' rem_ctl?
or Roland's krb5_admin?  But since those are layered above the core
KDC kadmin/kadm5 interfaces, even settling on those is risky as long
as the kadmin/kadm5 interfaces are unstable.

Nico
--