Any way to propagate db

[Russ Allbery]

"Christopher D. Clausen" <cclausen at acm.org> writes:

> I advocate just using the Active Directory realm.  It is much, much
> simpler to troubleshoot when there is no cross-realm invovled,
> especially when different groups operate the different realms.

> Other than some solvable issues of generating keytabs on non-Windows
> platforms, I can't think of a reason why someone would want to make more
> work for themselves with multiple realms.

> What problem are you trying to solve by setting up a cross-realm trust?

Creating and managing keytabs on UNIX systems from Active Directory is way
harder than it is using a UNIX KDC.  It's going to interfere with much of
the management that you want to do at scale with a large site (and note
that I specifically limited my comment to large sites).  It's probably
possible to encapsulate some of that mess in, say, a wallet backend for
Active Directory, which would mostly eliminate this problem, but as yet no
one has written that and it's not high on my priority list.

It's somewhat easier to manage light-weight accounts in a UNIX KDC, since
they need not have any associated directory information.  It's just an
account.  I prefer the UNIX KDC model that separates directory information
from account existence, and think having that separation can make life
easier in some account management situations.

Other issues depend on what skill sets you have available, of course, but
certainly for people coming from a UNIX background the UNIX KDC admin
interface is more scriptable and easier to automate than using the LDAP
interface to Active Directory.  I've written and maintain production code
with both interfaces, and I know which one I'd rather do most work in.  A
lot of large sites also find reasons at one point or another to want to
customize the KDC or admin interface, and that's a lot harder to do with
Active Directory since Microsoft has to have anticipated your needs and
where hooks will be required, and you can't just look at the source code
to figure out what's going on.

There are also various other management advantages of a UNIX KDC over
Active Directory that are directly related to all the other things that AD
is doing other than being a KDC: replication between KDCs is an order of
magnitude faster, configuration is much simpler and more straightforward,
adding new KDCs is much faster and simpler, and there are far fewer moving
parts when you're trying to debug problems.  Comparing UNIX KDCs to AD is
somewhat an unfair comparison to AD; for a fair comparison, you'd have to
compare AD to a KDC plus an LDAP server plus a variety of other related
services.  If you don't need all of those other services, or if you have
to maintain the UNIX LDAP environment for other reasons regardless, the
UNIX KDC is comparatively very easy to maintain.

And the cost of running two realms just isn't very high.  A UNIX KDC is
about the simplest server I've ever run.  It's way simpler than running a
mail server or a file server.  You set them up and they just run, and you
can run them on any old hardware even with high production loads.  The
cross-realm trust setup is not particularly difficult, and once it's done,
it's done.  We spend practically no ongoing day-to-day effort on
maintaining our UNIX KDCs; the only work is upgrades, and most of that
work is on maintaining the custom code and management interfaces that we'd
have to maintain anyway if we were using AD exclusively.

There's also a significant political advantage to just telling people "we
support both and it doesn't matter."  This is political, not technical; AD
is a perfectly fine KDC and works fine with UNIX software.  But much of
the documentation assumes UNIX KDCs for UNIX servers, and UNIX people can
get irrationally twitchy about AD.  I think this is silly, but it's also
nice to avoid the problem entirely.  This isn't a compelling reason, but
it's a nice side bonus.

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