Re: Kerberized mount.cifs with SMB>1?

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

On 10/19/2014 10:25 PM, steve wrote:
>  >
> On 19/10/14 21:58, Jurjen Bokma wrote:
>> 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
>
> Not sure why you would want smb2 with Linux boxes. Does it improve
> performance? Loading a big jpg to gimp to a lxde client still beats a w7
> client on the same hardware.
The local Windows admins are closing SMB1 because they consider it too 
insecure. On Windows Server 2012, SMB1 is allegedly deprecated already.
So I would very much like to use SMB3 to get to the Windows file 
servers. Kerberized SMB1 worked like a charm. Speed/bandwidth is not 
really the issue here.

Best'
Jurjen