[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kerberos authentication and High availability
On Apr 4, 2007, at 4:15 AM, Mustafa A. Hashmi wrote:
> On 4/3/07, Henry B. Hotz <firstname.lastname@example.org> wrote:
> On Apr 3, 2007, at 1:48 AM, Mustafa A. Hashmi wrote:
> > Thanks for your e-mail. Please see some comments in-line.
> > On 4/3/07, Henry B. Hotz < email@example.com > wrote:The client is
> > going to get a service ticket for the load balancer.
> > Probably no choice. That's a good argument for not using load
> > balancers, IMO. Instead clients should have a standard list of
> > CNAMEs to try.
> > Well it's not just load balancing, it's high availability which is
> > also very important. Ensuring transparent fail-overs is paramount.
> Define "transparent". ;-)
> With minimal user disruption. I am not sure how familiar you are
> with the linux-ha project, however, smtp / pop / imap / web (other)
> services are maintained in a HA pool where the monitors themselves
> are redundant. It's quite configurable, so depending on how much
> network noise you want to generate, these systems can check
> services in defined intervals to keep the active HA pool quite
> What I'm talking about requires that the client be programmed to do
> it (which they may not be). I'm thinking specifically of what
> Kerberos itself does: it has a list of KDCs. If the first one
> doesn't respond within a second, you try the second, etc. Most
> clients don't notice the difference.
> Sure, but the clients here range from web browsers to e-mail
> clients to xyz written by abc using saslauthd. Certainly coming up
> with client based solutions doesn't work at this point. It also
> takes HA out of the picture -- the client is going directly to
> defined service targets.
> Don't get me wrong, I think it's a very elegant and clean solution
> -- just not feasible given immediate needs and deployments.
We're in "violent agreement".
> It's certainly convenient if you can shuffle servers around for
> maintenance without having to play with DNS to do it. My grumpiness
> comes from the annoyance of dealing with all the naming issues you're
> asking about.
> Understandable -- am not happy with this either.
> > That means the service must be configured to accept tickets for the
> > load balancer's name. For SASL-based services there is probably a
> > hostname config parameter somewhere that you need to set to the load
> > balancer name instead of the real local hostname. This seems to
> > for LDAP servers.
> > Actually the kerberos FAQ greatly helped as it addresses problems
> > of this nature. I know this solution will probably be frowned upon,
> > however, I simply set ptr records for multiple mail server IPs to
> > resolve to mail.domain.com.
> There's a move afoot to have Kerberos just take the server name at
> face value and not do any DNS translation. When you start getting
> clients that work this way this solution may break. They also want
> to do name canonicalization in the KDC, so that may solve the problem
> for you, depending on what gets deployed in what order.
> Interesting. Why would the former solution break when we get
> clients that have a list of service targets to try?
The "list of targets" scenario was my ideal. This piece is: how do
you deal with the non-ideal clients that are dependent on an Edge/
load balancer/HA front end.
I think your PTR record solution is nice. I wish my own situation
was that simply resolved. I'm just trying to point out some areas
where it might break in the future (with non-ideal clients).
> Canonicalization may indeed work best in our case -- but I wonder
> how different needs get in such scenarios. Don't we all face
> similar issues?
> Mustafa A. Hashmi
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or firstname.lastname@example.org