[17357] in Kerberos_V5_Development
Re: Extensible kadm5 policies
daemon@ATHENA.MIT.EDU (Russ Allbery)
Tue Nov 1 20:59:48 2011
From: Russ Allbery <rra@stanford.edu>
To: krbdev@mit.edu
In-Reply-To: <4EB08EED.20801@redhat.com> (Dmitri Pal's message of "Tue, 01 Nov
2011 20:29:33 -0400")
Date: Tue, 01 Nov 2011 17:59:44 -0700
Message-ID: <87hb2ne3un.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
Dmitri Pal <dpal@redhat.com> writes:
>> 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.
> If you count AD the KDC+LDAP is the most deployed configuration in the
> world.
I find this constant red herring very frustrating.
There is no option in AD to run the KDC database independent of LDAP, so
you have absolutely no idea what improvements in stability or managability
for the authentication might come from such a configuration. Microsoft
chose to present their authentication service as a merged identity
management service, of which the KDC is only a small component. The LDAP
component of Active Directory is, of course, central to the other
facilities and functionality that Active Directory provides. But Active
Directory as a whole is easily ten times more complex than a Kerberos KDC.
Copying Microsoft in distributed systems design without regard to whether
their choices are grounded in technical concerns or business competition
goals doesn't strike me as a good way to design systems.
> The the problem is not in the LDAP itself but rather in level of the
> manageability of the solution as a whole.
This is only true if you want to provide a unified identity management
infrastructure including all of those components. Some people may want to
do that. Other people clearly do not and have no need for much of the
complexity and additional functionality.
Furthermore, you are sweeping a core issue under the rug, namely whether
merging the backend infrastructure of all of those components (in essence
tightly coupling them) increases the manageability and reliability of the
system as a whole. Most research into large-scale distributed system
design says the exact opposite: tight coupling decreases reliability, and
separation of services into components with well-defined and limited APIs
between those components produces more stable and reliable systems.
If you want to present people with a turnkey system that performs many
separate functions, and do not expect those people to understand or debug
how it works below the level of the provided administrative interface, I
can certainly see the appeal of using LDAP as a shared backing store for
the entire system. However, please remember that this is not the typical
situation for large Kerberos sites with existing KDC deployments and
existing security infrastructures. Large sites are prone to widely
varying requirements and special needs, and the decrease in flexibility of
tightly coupled systems is frequently fatal to their usability in that
sort of environment.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
