[linux-cifs-client] Handling Kerberos principals that don't match hostnames

Doug Kelly dougk at dougk-ff7.net
Fri Jan 8 08:37:59 MST 2010


On Fri, Jan 08, 2010 at 07:11:06AM -0500, Jeff Layton wrote:
> By default the kernel and cifs.upcall just use the hostname portion of
> the UNC as the SPN. The preferred scheme is to add service principals
> for every possible hostname and put those in the server's keytab.
> I believe that Windows does this for unqualified hostnames, for
> instance.
> 
> Very recent versions of cifs.upcall support a --trust-dns flag that
> will do a reverse lookup to get a SPN. It's not really recommended to
> use that, but it may help in your case.

It'd help partially.  The other problem is that I'm having to deal with
what effectively amounts to two different (but identical) DFS roots,
being connected through a load balancer.  And, since Windows apparently
balks at having the same SPN on two different systems (and with good
reason), I've not been able to find a reasonable solution yet (and the
more I think on it, the more I think there may not be one).

The closest thing I can get is starting the NTLMSSP authentication, once
the FQDN is received through the server names blob, stop that and
reconnect, this time using the FQDN received from above as the SPN.
Seems like an epic kludge... and not even one Windows attempts. :)

Funny thing is, we switched to the two separate DFS roots originally
because CIFS VFS apparently wasn't handling multiple targets too well.
Shame I didn't realize that earlier, since that might actually be a bug.
Maybe I'll set up a test environment at home and see if that is an issue
(unless someone else is willing to test it).  If it is, well maybe I can
get that working AND get Kerberos auth.

--Doug Kelly


More information about the linux-cifs-client mailing list