[17353] in Kerberos_V5_Development
Re: Extensible kadm5 policies
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Nov 1 13:03:23 2011
From: Russ Allbery <rra@stanford.edu>
To: krbdev@mit.edu
In-Reply-To: <CAK3OfOis1KpCzxBRiGTJosfOnjA5-stY2ge4w5Gyg6-SKr8EDA@mail.gmail.com>
(Nico Williams's message of "Tue, 1 Nov 2011 10:11:58 -0500")
Date: Tue, 01 Nov 2011 10:03:19 -0700
Message-ID: <877h3jixm0.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Nico Williams <nico@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@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
