>There are a number of reasons why either can be more useful to a specific
>site. We switched from the MIT kerberos server to the AFS kaserver several
>years ago because we found it more reliable for our larger site. The AFS
>kaserver uses "ubik" to keep the replicated security servers in sinc. This
>is much more robust then what the MIT kerberos server does.
This was pretty bad with the V4 database code, but _if_ you use V5 and
you use the btree database backend, then this is a lot better. And one
of these days I'm going to get incremental database updating done ....
and if you want, you could buy the Veritas product and get incremental
updating :-)
>read-write database gets seperated from other parts of the net. Also you do
>not have to dump the entire database and edit out old accounts and then
>reload that database when doing trivial account cleanup activities.
Again, that's much better under V5.
>Ubik
>keeps all the kaservers in sinc and when the "master" server is disconnected
>from the rest of the network, voting for a "new master" happens with out
>intervention be humans. Though it is not perfect, it has greatly improved
>the overall reliability of our site.
I _do_ wish Kerberos used Ubik, or something similar .... but that would
require a pretty nasty set of changes to the admin protocol.
>As you know it does a good job of
>handling the MIT kerberos calls, and you can even have the added benefit of
>forwarded tickets and tokens which also keeps users happier with less
>password retyping.
How do you do ticket forwarding with Kerberos 4?
--Ken
