Re: Kerberos authentication and High availability

["Henry B. Hotz" <hotz@jpl.nasa.gov>]

On Apr 4, 2007, at 4:15 AM, Mustafa A. Hashmi wrote:

> On 4/3/07, Henry B. Hotz <hotz@jpl.nasa.gov> 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 < hotz@jpl.nasa.gov > 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  
> current.
>
> 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  
> work
> > 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
> mahashmi@gmail.com

------------------------------------------------------------------------
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 hbhotz@oxy.edu