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

[Jeff Layton]

On Wed, 6 Jan 2010 23:56:01 -0600
Doug Kelly <dougk at dougk-ff7.net> wrote:

> In trying to troubleshoot why Kerberos authentication is not working
> with our particular setup, I came across some interesting things.  CIFS
> currently assumes the principal is either cifs/hostname or host/hostname
> (a feature of cifs.upcall).  Not a problem there, per-se, but this
> doesn't seem to be a 100% reliable method for determining the principal,
> either.  In our case, two circumstances seem to foul up everything:
> 
> 1) Load balancing, where the client connects to a virtual IP and gets
> handed off to a real server.
> 2) CNAMEs.
> 
> smbclient got around these issues by using some data returned by Windows
> 2003 servers that revealed the SPN clients should use, it seems.
> However, 2008 Server has removed this, and the CIFS kernel module
> doesn't even try.  So, I started digging for the way Windows does it to
> see if the SPN can be determined in a somewhat reasonable fashion.
> 
> I've found that the servers return a bevy of information, including the
> NetBIOS domain, NetBIOS hostname, DNS domain, and DNS hostname as a part
> of the NTLMSSP response... specifically, the NTLMSSP_CHALLENGE packet.
> This reveals the real hostname of the machine that you are connecting
> to.
> 
> So, getting to the point, is it feasible to use the NTLMSSP
> process--just so far as to get the challenge packet back--and parse for
> the real information?  Granted, it's not the cleanest option, but I've
> been trying to think of any way to determine the hostname to connect to
> cleanly, and this is the best I can think of.  If the actual hostname is
> determined, the upcall program shouldn't even need to be changed.
> 

The CIFS client doesn't currently do mutual krb5 authentication but
eventually it would be nice if it did.

The problem with any scheme that relies on getting the SPN in this way
is that it leaves you open to DNS spoofing attacks even if you can
support mutual authentication.

-- 
Jeff Layton <jlayton at samba.org>