Extensible kadm5 policies

[Dmitri Pal]

On 11/01/2011 08:59 PM, Russ Allbery wrote:
> Dmitri Pal <dpal at 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.
>
As long as you have transparency and manageability via tools that you
can use but can also get under the hood as they are not sealing
everything but rather provide convenience you get the best of both
worlds. That IMO might be more attractive to the organizations you are
talking about above in a long run. We do not have enough statistics to
prove the argument. Let us see how things would unveil. My bet is that
LDAP based KDC deployments would start to get more and more ground in
the complex environments that you refer to. I am not suggesting
designing just for LDAP back end but we should treat LDAP and DB back
ends as main stream back ends in our policy related design decisions and
not focus on the DB approach only as it would become less and less
popular over the time.      

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/