Current ideas on kerberos requirements for Samba4
rra at stanford.edu
Mon May 23 23:08:41 EDT 2005
I can only echo what everyone else has said, and also mention that not
everyone who does Kerberos does cross-realm. There have been security
vulerabilities in the past, fixed now of course, that *only* affected
cross-realm, so sites that never needed it had good reasons not to run it.
And frankly, still do, since after all the best way to avoid potential
vulerabilities in code is to not run it in the first place when it's not
That being said, I do understand where you're coming from and why you
would need to tie into a KDC pretty intimately to accomplish what you're
trying to do. However, the more independent you can keep that from the
rest of your application, I think the happier you will be in the long run.
The ideal case is if the minimum necessary KDC hooks could somehow be
determined and modularized and then integrated into an existing KDC
(Heimdal if that's the easiest) with the possibility that other KDC
implementations could pick them up. That way, the KDCs could continue to
do the KDC thing and you could just use the results.
Jeffrey Hutzelman <jhutz at cmu.edu> writes:
> We recently decided to remove nearly all of these independent
> packages from the OpenAFS tree, and concentrate more fully on our
> core purpose. Of the components I mentioned above, the only ones we
> haven't thrown away are package (which probably should be) and the
> kaserver, which we've kept around only because there are a few sites
> out there who still depend on it. Note that anytime someone comes
> to us with a question of the form "we're running the kaserver
> and...", the answer is "don't do that; go get a real KDC".
> We want people to run a real KDC. We've been in the business of
> supporting a KDC unique to our filesystem application, and we didn't
> like it one bit. Just a friendly word of advice...
And just think what the world would look like today if AFS had never
contained a KDC and had always asked people to run an external one. The
linkages wouldn't be as tight as they ended up being, I expect the
migration to K5 would have been easier because of that, the AFS KDC
wouldn't have ended up being a unique implementation with quirks that
differed from any other KDC, and the whole system would likely be more
modular and more robust at this point.
(On the other hand, we might not have had Ubik for the KDC, which would
have been a shame... but on the gripping hand, maybe that would have
sparked more work on separating Ubik from AFS so that other protocols
could have been using it.)
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the krbdev