Kerberos and hostnames in a HA environment

[Henry B. Hotz]

Thanks for posting that patch.  Is there any chance of getting it rolled into cyrus sasl upstream?

I would strongly advocate it, at least as an option.  I really think it ought to be the default, since I believe every kerberized service ought to be set up with its own independent keytab file.  Then the service's behavior can be controlled by the content of the keytab file.  I don't even believe it's necessary to be able to turn it off, but I expect that people will be afraid to go that far.

On Mar 6, 2011, at 1:05 PM, Russ Allbery wrote:

> Gémes Géza <geza at kzsdabas.hu> writes:
> 
>> My problem is, that We've started moving the services offered to our
>> network to a redhat-cluster based HA failover solution (each node is
>> identified by its hostname). E.g. instead of one machine named www now
>> we have two: www-0 and www-1 and www is associated (in the DNS) with an
>> IP address which is given to one of the two nodes providing the
>> associated service (+ the required storage from a SAN). The problem is
>> that to my (humble) knowledge kerberos also uses the hostname for
>> identifying the sevice tickets it needs to obtain, and that hostname is
>> different from what the client requesting access to the service is
>> trying to connect to. I was thinking about using SPN aliases, but our
>> database is LDAP based, and SPN aliases aren't supported there.
> 
>> The software versions used are:
>> debian squeeze
>> redhat-cluster 3.0.12
>> heimdal 1.4 (both client, server and kdc)
>> libapache2-mod-auth-kerb 5.4
>> and more as more kerberized services will get migrated (the KDC,
>> OpenLDAP, OpenAFS and OpenSSH being the most important)
> 
> Generally, the easiest way to deal with this is to generate keytabs for
> each hostname that a system can be addressed as (so, in your case, both
> www.example.com and www-0.example.com, for www-0) for each service.  Then,
> configure all of your Kerberos applications to support authentication to
> any key in the keytab.
> 
> For libapache2-mod-auth-kerb, this is a standard option (KrbServiceName
> any).  For OpenSSH, you'll need a relatively new OpenSSH with Simon's
> GSSAPI patch for GSSAPIStrictAcceptorCheck no.  OpenAFS won't care, since
> it uses a separate principal for the whole cell that doesn't depend on
> hostname.
> 
> OpenLDAP is the hardest problem, since it uses Cyrus SASL and Cyrus SASL
> doesn't support checking every key in the keytab by default.  There's a
> one-line patch you can apply to Cyrus SASL that fixes this:
> 
> index d19a6c2..fcfa2ea 100644
> --- a/plugins/gssapi.c
> +++ b/plugins/gssapi.c
> @@ -693,7 +693,7 @@ gssapi_server_mech_step(void *conn_context,
> 
>            GSS_LOCK_MUTEX(params->utils);
>            maj_stat = gss_acquire_cred(&min_stat, 
> -                                       text->server_name,
> +                                       GSS_C_NO_NAME,
>                                        GSS_C_INDEFINITE, 
>                                        GSS_C_NO_OID_SET,
>                                        GSS_C_ACCEPT,
> 
> -- 
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu