"Christopher D. Clausen" <[email protected]> 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 ([email protected]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
