[22645] in Kerberos
Re: Kerberos behind load balancer?
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Oct 6 15:25:55 2004
Message-Id: <200410061923.i96JNqsi007583@ginger.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <1097089673.4249.16.camel@dionysus.uta.edu>
Date: Wed, 06 Oct 2004 15:23:52 -0400
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Errors-To: kerberos-bounces@mit.edu
>I guess the problem that everyone is having with our deployment is the
>term load-balancer. We don't actually want to easy the load off of our
>KDC's, we just want provide a seamless way of ensuring availability in
>the event that we lose one (or more) of them. I think it's true for
>everyone who's commented to this thread that their users are probably
>not aware of how Kerberos works. We're trying to make deployment as easy
>as possible for the end user (migrating a huge deployment from AD to MIT
>Kerberos). Having one host name to remember would certainly help.
Just as an aside ... are you actually expecting end-users to create MIT
krb5.conf files? We don't do that; we just give them a krb5.conf file
to download. If you're going that route, you could simply list all of
the KDCs individually in the krb5.conf file (and put a few extra names
in there as placeholders; names that don't resolve to anything won't
cause a problem there). Given the way database propagation works with
MIT Kerberos, if you plan on doing password changes having a load
balancer in the mix could very likely screw you hard when it comes to
users changing their password (the MIT Kerberos library has a bunch of
logic that will query the "master" KDC when it has talked to a backup
KDC and the password is incorrect, which happens when a password is
changed due to propagation lag; this wouldn't work if the client
library only thought there was one KDC).
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
