Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma <j.bokma-39IHFo8E5E0@public.gmane.org>]

On 08/20/2014 07:16 PM, Jurjen Bokma wrote:
> On 08/20/2014 04:43 PM, steve wrote:
>> On Wed, 2014-08-20 at 16:08 +0200, Jurjen Bokma wrote:
<snip>
>> The upcall has nothing to go on. Get it working with cifs first:
>>
>> Who mounts the share? Add a domain user with a uid:gid key to the keytab
>> and:
<snip>
>> mount.cifs //your/share /mnt -ousername=cifsuser,sec=krb5
> This works, as it uses SMB1. SMB1 also works *with* all the frills. But
> it fails with 2.0, 2.1 or 3.0:
>
> mount.cifs //your/share /mnt -ousername=cifsuser,sec=krb5,vers=3.0
<snip>

No matter whether I use my own Samba server or a Windows (2012) server, 
vers=2.0 or vers=3.0 fails with "permission denied", while 'vers=1.0' 
works perfectly:

mount.cifs //server.mydom.com/cnc  /mnt/cnc 
-overs=1.0,sec=krb5,username=cifsuser,cruid=1234567,domain=MYDOM.COM

With SMB>1, no Kerberos traffic in Wireshark. If it is encapsulated, 
that would explain a part. But the ticket still would have to be granted 
by the Kerberos server, and I don't see that either. Also, request-key 
is not being called with SMB>1. So I must conclude that Steve is right: 
the upcall has nothing to go on. But how to tell it?

Any hints as to why this fails with SMB>1 would be much appreciated.

Best Regards
Jurjen