[RFC/PATCH] cifs.upcall: use kernel.provided principal name if available

[Jeff Layton]

On Thu, 08 Sep 2011 23:23:05 +1000
Andrew Bartlett <abartlet at samba.org> wrote:

> On Thu, 2011-09-08 at 15:13 +0200, Martin Wilck wrote:
> > On 09/08/2011 03:01 PM, Andrew Bartlett wrote:
> > 
> > > Try 
> > > [libdefaults]
> > >  rdns = false
> > > 
> > > in your krb5.conf
> > 
> > Doesn't work, sorry. Actually, it doesn't seem to make any difference in
> > my setup. In my scenario, cifs.upcall would be able to infer the correct
> > SPN with the following algorithm:
> > 
> >  - get the IP address using DNS
> >  - get the "real" server FQDN using RDNS
> >  - use "cifs/<hostname portion of the "real" FQDN>" as SPN
> > 
> > Thus RDNS might indeed be beneficial here (but "rdns = true" makes no
> > difference, either).
> > 
> > OTOH, from the security point of view, this algorithm might not be more
> > secure than the server-provided SPN, because the attack scenario assumes
> > that DNS and/or general network packet transmission is already hijacked.
> > 
> > The question remains: what are the windows clients doing to overcome
> > this situation?
> 
> They use only the name, as typed.  Windows never uses reverse DNS, as it
> is rare on Windows networks.
> 
> The AD KDC answers to short, long and alias names for a server, removing
> the need for the client to 'guess' what the right name it.  The SPN
> should simply be cifs/<name as originally specified>.
> 

That should be what cifs.ko does as well...

The hostname portion of the UNC is passed to the kernel, which in turn
passes it to the keys upcall. That's then prefixed with "cifs/" and we
attempt to get a service ticket for that principal. If that fails, we
try again with a prefix of "host/".

Perhaps there's a better way to construct the SPN from that info? I'm
open to suggestions here, but we'll need to take care not to break
existing setups.

-- 
Jeff Layton <jlayton at samba.org>