Kerberized mount.cifs with SMB>1?

Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

Hi,

could anyone please tell me whether the combination
mount.cifs+Kerberos+SMB2/SMB3 is supposed to work?

>From what I see, Linux doesn't even consider Kerberos when speaking SMB2
or SMB3. After the Negotiate Protocol Response from the server, the
client sends an ACK and then follows up with an NTLMSSP_NEGOTIATE. There
is no Kerberos at all in the conversation. At least not that Wireshark
finds.

These are the commands that fail with mount error(13): Permission denied

mount.cifs  //ws.mydomain.com/ydrive  /mnt/y 
-omultiuser,sec=krb5,noexec,nosuid,vers=3.0
and
kinit n123456 mount -t cifs -overs=3.0,sec=krb5
//ws.mydomain.com/homedrive/staff/user3/N123456 /mnt/x -o
uid=10123456,gid=10123456


Particularities:
- Cifs.upcall is set to run with the option '-t' (because Kerberized
NFS4 breaks without it). Removing the option doesn't help.
- These are DFS shares (if that is a correct term) with several
referrals. (Simpler shares cannot be accessed either.)
- The Kerberos server is Microsoft Server 2012 AD. Msktutil (not
winbind) was used to join the host to the AD domain.
- /proc/fs/cifs/SecurityFlags is set to 0x8009. (The default 0x85
doesn't work either.)

Things that do help:
- Use vers=1.0.
- Leave out the sec=krb5. (Get asked for a password, NTLM* works.)

So this is the status:
           SMB1 SMB2    SMB3
ntlm*   work    work    work
krb5*   work    fail        fail

Versions:
Kernel  3.17.0
Mount.cifs  6.4

I'll happily provide wireshark captures or try other situations.

FWIW, this is what the kernel ringbuffer says (after the first mount
command above):
[   75.119448] /home/apw/COD/linux/fs/cifs/cifsfs.c: Devname:
//ws.mydomain.com/ydrive flags: 0
[   75.119465] /home/apw/COD/linux/fs/cifs/connect.c: Username: root
[   75.137511] /home/apw/COD/linux/fs/cifs/connect.c: file mode: 0x1ed 
dir mode: 0x1ed
[   75.137541] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: in
cifs_mount as Xid: 0 with uid: 0
[   75.137543] /home/apw/COD/linux/fs/cifs/connect.c: UNC:
\\ws.mydomain.com\ydrive
[   75.137548] /home/apw/COD/linux/fs/cifs/connect.c: Socket created
[   75.137549] /home/apw/COD/linux/fs/cifs/connect.c: sndbuf 16384
rcvbuf 87380 rcvtimeo 0x6d6
[   75.137964] /home/apw/COD/linux/fs/cifs/connect.c: Demultiplex PID: 1823
[   75.137966] /home/apw/COD/linux/fs/cifs/fscache.c:
cifs_fscache_get_client_cookie: (0xffff8800c3060000/0xffff8800c3f0f000)
[   75.137969] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: in
cifs_get_smb_ses as Xid: 1 with uid: 0
[   75.137970] /home/apw/COD/linux/fs/cifs/connect.c: Existing smb sess
not found
[   75.137972] /home/apw/COD/linux/fs/cifs/smb2pdu.c: Negotiate protocol
[   75.137977] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=102
[   75.138745] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header 0xf8
[   75.138748] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0xfc, smb_buf_length: 0xf8
[   75.138749] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
120 offset 128
[   75.138750] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 252
[   75.138780] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=0 mid=0 state=4
[   75.138782] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.138784] /home/apw/COD/linux/fs/cifs/smb2pdu.c: mode 0x3
[   75.138785] /home/apw/COD/linux/fs/cifs/smb2pdu.c: negotiated smb3.0
dialect
[   75.138786] /home/apw/COD/linux/fs/cifs/connect.c: Security Mode: 0x3
Capabilities: 0x300007 TimeAdjust: 0
[   75.138787] /home/apw/COD/linux/fs/cifs/smb2pdu.c: Session Setup
[   75.138789] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=120
[   75.139346] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header 0x142
[   75.139350] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0x146, smb_buf_length: 0x142
[   75.139351] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
250 offset 72
[   75.139352] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 326
[   75.139381] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=1 mid=1 state=4
[   75.139384] /home/apw/COD/linux/fs/cifs/smb2maperror.c: Mapping SMB2
status code -1073741802 to POSIX err -5
[   75.139385] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.156277] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=416
[   75.157777] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header 0x49
[   75.157781] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0x4d, smb_buf_length: 0x49
[   75.157782] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
0 offset 0
[   75.157783] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 77
[   75.157803] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=1 mid=2 state=4
[   75.157806] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[   75.157810] /home/apw/COD/linux/fs/cifs/smb2maperror.c: Mapping SMB2
status code -1073741715 to POSIX err -13
[   75.157811] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.157812] CIFS VFS: Send error in SessSetup = -13
[   75.157815] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: leaving
cifs_get_smb_ses (xid = 1) rc = -13
[   75.157817] /home/apw/COD/linux/fs/cifs/fscache.c:
cifs_fscache_release_client_cookie: (0xffff8800c3060000/0xffff8800c3f0f000)
[   75.157864] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: leaving
cifs_mount (xid = 0) rc = -13
[   75.157866] CIFS VFS: cifs_mount failed w/return code = -13

Many thanks!
Jurjen Bokma

Re: Kerberized mount.cifs with SMB>1?

[steve]

On Wed, 2014-08-20 at 16:08 +0200, Jurjen Bokma wrote:
> Hi,
> 

> 
> These are the commands that fail with mount error(13): Permission denied
> 
> mount.cifs  //ws.mydomain.com/ydrive  /mnt/y 
> -omultiuser,sec=krb5,noexec,nosuid,vers=3.0

Hi
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:

mount.cifs //your/share /mnt -ousername=cifsuser,sec=krb5

add any multiuser frills later.
HTH,
Steve

RE: Kerberized mount.cifs with SMB>1?

[McCall, Andy (IT.PFMS)]

I had a problem that might be similar and I believe there is another
user on the mailing list (steve?) with the same issue.

In my case, ws.mydomain.com was the domain and during the mount process
was being resolved as the IP address of the DNS/domains servers. The DFS
referral was not taking place despite DFS being configured for DNS
within Active Directory.  CIFS was trying to be mounting ydrive from the
DNS/domain servers not the back end server with the share on, thus was
getting a permission denied error.

I wasn't able to find a solution and reverted to plain nfs mounts for my
solution.


-----Original Message-----
From: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
[mailto:linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Jurjen Bokma
Sent: 20 August 2014 15:08
To: linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Kerberized mount.cifs with SMB>1?

Hi,

could anyone please tell me whether the combination
mount.cifs+Kerberos+SMB2/SMB3 is supposed to work?

>From what I see, Linux doesn't even consider Kerberos when speaking SMB2
or SMB3. After the Negotiate Protocol Response from the server, the
client sends an ACK and then follows up with an NTLMSSP_NEGOTIATE. There
is no Kerberos at all in the conversation. At least not that Wireshark
finds.

These are the commands that fail with mount error(13): Permission denied

mount.cifs  //ws.mydomain.com/ydrive  /mnt/y
-omultiuser,sec=krb5,noexec,nosuid,vers=3.0
and
kinit n123456 mount -t cifs -overs=3.0,sec=krb5
//ws.mydomain.com/homedrive/staff/user3/N123456 /mnt/x -o
uid=10123456,gid=10123456


Particularities:
- Cifs.upcall is set to run with the option '-t' (because Kerberized
NFS4 breaks without it). Removing the option doesn't help.
- These are DFS shares (if that is a correct term) with several
referrals. (Simpler shares cannot be accessed either.)
- The Kerberos server is Microsoft Server 2012 AD. Msktutil (not
winbind) was used to join the host to the AD domain.
- /proc/fs/cifs/SecurityFlags is set to 0x8009. (The default 0x85
doesn't work either.)

Things that do help:
- Use vers=1.0.
- Leave out the sec=krb5. (Get asked for a password, NTLM* works.)

So this is the status:
           SMB1 SMB2    SMB3
ntlm*   work    work    work
krb5*   work    fail        fail

Versions:
Kernel  3.17.0
Mount.cifs  6.4

I'll happily provide wireshark captures or try other situations.

FWIW, this is what the kernel ringbuffer says (after the first mount
command above):
[   75.119448] /home/apw/COD/linux/fs/cifs/cifsfs.c: Devname:
//ws.mydomain.com/ydrive flags: 0
[   75.119465] /home/apw/COD/linux/fs/cifs/connect.c: Username: root
[   75.137511] /home/apw/COD/linux/fs/cifs/connect.c: file mode: 0x1ed 
dir mode: 0x1ed
[   75.137541] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: in
cifs_mount as Xid: 0 with uid: 0
[   75.137543] /home/apw/COD/linux/fs/cifs/connect.c: UNC:
\\ws.mydomain.com\ydrive
[   75.137548] /home/apw/COD/linux/fs/cifs/connect.c: Socket created
[   75.137549] /home/apw/COD/linux/fs/cifs/connect.c: sndbuf 16384
rcvbuf 87380 rcvtimeo 0x6d6
[   75.137964] /home/apw/COD/linux/fs/cifs/connect.c: Demultiplex PID:
1823
[   75.137966] /home/apw/COD/linux/fs/cifs/fscache.c:
cifs_fscache_get_client_cookie: (0xffff8800c3060000/0xffff8800c3f0f000)
[   75.137969] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: in
cifs_get_smb_ses as Xid: 1 with uid: 0
[   75.137970] /home/apw/COD/linux/fs/cifs/connect.c: Existing smb sess
not found
[   75.137972] /home/apw/COD/linux/fs/cifs/smb2pdu.c: Negotiate protocol
[   75.137977] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=102
[   75.138745] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header
0xf8
[   75.138748] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0xfc, smb_buf_length: 0xf8
[   75.138749] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
120 offset 128
[   75.138750] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 252
[   75.138780] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=0 mid=0 state=4
[   75.138782] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.138784] /home/apw/COD/linux/fs/cifs/smb2pdu.c: mode 0x3
[   75.138785] /home/apw/COD/linux/fs/cifs/smb2pdu.c: negotiated smb3.0
dialect
[   75.138786] /home/apw/COD/linux/fs/cifs/connect.c: Security Mode: 0x3
Capabilities: 0x300007 TimeAdjust: 0
[   75.138787] /home/apw/COD/linux/fs/cifs/smb2pdu.c: Session Setup
[   75.138789] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=120
[   75.139346] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header
0x142
[   75.139350] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0x146, smb_buf_length: 0x142
[   75.139351] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
250 offset 72
[   75.139352] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 326
[   75.139381] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=1 mid=1 state=4
[   75.139384] /home/apw/COD/linux/fs/cifs/smb2maperror.c: Mapping SMB2
status code -1073741802 to POSIX err -5
[   75.139385] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.156277] /home/apw/COD/linux/fs/cifs/transport.c: Sending smb:
smb_len=416
[   75.157777] /home/apw/COD/linux/fs/cifs/connect.c: RFC1002 header
0x49
[   75.157781] /home/apw/COD/linux/fs/cifs/smb2misc.c:
smb2_check_message length: 0x4d, smb_buf_length: 0x49
[   75.157782] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 data length
0 offset 0
[   75.157783] /home/apw/COD/linux/fs/cifs/smb2misc.c: SMB2 len 77
[   75.157803] /home/apw/COD/linux/fs/cifs/transport.c:
cifs_sync_mid_result: cmd=1 mid=2 state=4
[   75.157806] Status code returned 0xc000006d STATUS_LOGON_FAILURE
[   75.157810] /home/apw/COD/linux/fs/cifs/smb2maperror.c: Mapping SMB2
status code -1073741715 to POSIX err -13
[   75.157811] /home/apw/COD/linux/fs/cifs/misc.c: Null buffer passed to
cifs_small_buf_release
[   75.157812] CIFS VFS: Send error in SessSetup = -13
[   75.157815] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: leaving
cifs_get_smb_ses (xid = 1) rc = -13
[   75.157817] /home/apw/COD/linux/fs/cifs/fscache.c:
cifs_fscache_release_client_cookie:
(0xffff8800c3060000/0xffff8800c3f0f000)
[   75.157864] /home/apw/COD/linux/fs/cifs/connect.c: CIFS VFS: leaving
cifs_mount (xid = 0) rc = -13
[   75.157866] CIFS VFS: cifs_mount failed w/return code = -13

Many thanks!
Jurjen Bokma


--
To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
DISCLAIMER. The contents of this email and its attachments are intended solely for the original recipients and express the views of the authors and not necessarily the Company. If you are not the intended recipient please delete without copying or forwarding and inform the sender that you received it in error. 
Provident Financial Management Services Ltd, Registered in England, Company Number 328933. Interim Permissions Reference Number: 119219
Provident Personal Credit Ltd, Registered in England, Company Number 146091. Interim Permissions Reference Number: 002529
Both Provident Financial Management Services Ltd and Provident Personal Credit Ltd are authorised and regulated by the Financial Conduct Authority, see Interim Permissions numbers above. Registered Office: No.1 Godwin Street, Bradford, West Yorkshire BD1 2SU, United Kingdom.
 
Please save paper - don't print this email unless necessary

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

On 08/20/2014 04:43 PM, steve wrote:
> On Wed, 2014-08-20 at 16:08 +0200, Jurjen Bokma wrote:
>> Hi,
>>
>> These are the commands that fail with mount error(13): Permission denied
>>
>> mount.cifs  //ws.mydomain.com/ydrive  /mnt/y
>> -omultiuser,sec=krb5,noexec,nosuid,vers=3.0
> Hi
> 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:
Hi Steve,

thanks for the advice.
I added a key for a domain user to the keytab. User has UID, GID, can 
log in on both Windows and Linux, and do kinit and kgetcred. Then I did 
what you advise (with cifsuser its username):
> 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

No significant changes: still no trace of Kerberos in Wireshark.
Is there a way to see what keys upcall is being asked for?

I would very much like to get it working with protocol version 2.0 or later.

Best Regards
Jurjen

>
> add any multiuser frills later.
> HTH,
> Steve
>
>

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

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

Re: Kerberized mount.cifs with SMB>1?

[steve]

 >
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.
Cheers,

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

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

Re: Kerberized mount.cifs with SMB>1?

[steve]

On 19/10/14 22:30, Jurjen Bokma wrote:

> 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.
>
Yeah, of course. Never knew there was any security involved. Worrying.

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

On 10/19/2014 10:42 PM, steve wrote:
> On 19/10/14 22:30, Jurjen Bokma wrote:
>
>> 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.
>>
> Yeah, of course. Never knew there was any security involved. Worrying.
Did you ever have SMB3 working Kerberized? If I know it's supposed to 
work, I'll give up less easily.

Re: Kerberized mount.cifs with SMB>1?

[steve]

On 19/10/14 22:48, Jurjen Bokma wrote:
> On 10/19/2014 10:42 PM, steve wrote:
>> On 19/10/14 22:30, Jurjen Bokma wrote:
>>
>>> 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.
>>>
>> Yeah, of course. Never knew there was any security involved. Worrying.
> Did you ever have SMB3 working Kerberized? If I know it's supposed to
> work, I'll give up less easily.
>
Hi
We have everything default. We'd no idea that smb3 existed until this 
thread. Anyway, it doesn't work here either:
CIFS VFS: cifs_mount failed w/return code = -128
I think the Kerberos has worked because that codes means that the ticket 
has expired, except it hasn't because removing vers=3.0 mounts fine.
But we don't know if our Samba4 file servers are capable of it anyway. I 
think we'd have to change something in smb.conf.

Maybe the devs will look if you bugzilla it?
Good luck,
Steve

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

On 10/20/2014 06:24 PM, steve wrote:
> On 19/10/14 22:48, Jurjen Bokma wrote:
>> On 10/19/2014 10:42 PM, steve wrote:
>>> On 19/10/14 22:30, Jurjen Bokma wrote:
>>>
>>>> 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.
>>>>
>>> Yeah, of course. Never knew there was any security involved. Worrying.
>> Did you ever have SMB3 working Kerberized? If I know it's supposed to
>> work, I'll give up less easily.
>>
> Hi
> We have everything default. We'd no idea that smb3 existed until this
> thread. Anyway, it doesn't work here either:
> CIFS VFS: cifs_mount failed w/return code = -128
> I think the Kerberos has worked because that codes means that the ticket
> has expired, except it hasn't because removing vers=3.0 mounts fine.
> But we don't know if our Samba4 file servers are capable of it anyway. I
> think we'd have to change something in smb.conf.
Maybe to serve SMB3. Max protocol comes to mind. But editing smb.conf is
not likely necessary to merely mount a share I presume? IME mount.cifs +
Kerberos will work once krb5.conf and request-key are properly
configured, regardless of the smb.conf on the client.
I did fiddle a bit with /proc/fs/cifs/* though.

> Maybe the devs will look if you bugzilla it?
Will try. But first I'll take a look myself, lest I don't know what to ask.

Thx so far!
Jurjen

Re: Kerberized mount.cifs with SMB>1?

[Steve French]

On Mon, Oct 20, 2014 at 11:37 AM, Jurjen Bokma <j.bokma-39IHFo8E5E0@public.gmane.org> wrote:
> On 10/20/2014 06:24 PM, steve wrote:
>> On 19/10/14 22:48, Jurjen Bokma wrote:
>>> On 10/19/2014 10:42 PM, steve wrote:
>>>> On 19/10/14 22:30, Jurjen Bokma wrote:
>>>>
>>>>> 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.
>>>>>
>>>> Yeah, of course. Never knew there was any security involved. Worrying.
>>> Did you ever have SMB3 working Kerberized? If I know it's supposed to
>>> work, I'll give up less easily.
>>>
>> Hi
>> We have everything default. We'd no idea that smb3 existed until this
>> thread. Anyway, it doesn't work here either:
>> CIFS VFS: cifs_mount failed w/return code = -128
>> I think the Kerberos has worked because that codes means that the ticket
>> has expired, except it hasn't because removing vers=3.0 mounts fine.
>> But we don't know if our Samba4 file servers are capable of it anyway. I
>> think we'd have to change something in smb.conf.
> Maybe to serve SMB3. Max protocol comes to mind. But editing smb.conf is
> not likely necessary to merely mount a share I presume? IME mount.cifs +
> Kerberos will work once krb5.conf and request-key are properly
> configured, regardless of the smb.conf on the client.
> I did fiddle a bit with /proc/fs/cifs/* though.
>
>> Maybe the devs will look if you bugzilla it?
> Will try. But first I'll take a look myself, lest I don't know what to ask.

It is doable, and probably easier since the cleanup/rewrite a year or so ago
of some of the auth code.

Note that for cifs dialect (in fs/cifs/cifssmb.c) the negotiate response calls
decode_negTokenInit to parse the asn1 to figure out if kerberos is
allowed (see around line 595 and following of fs/cifs/asn1.c) then compare
with the smb2/smb3 case in which we call decode_neg_token_init
in line 434 of fs/cifs/smb2pdu.c during the processing of the SMB2/SMB3
negotiate protocol response.  Note that this is ifdef out (CONFIG_SMB2_ASN1)
since this function has to be changed to match the new format

Perhaps simply changing

decode_neg_token_init(security_blob, blob_length, &server->sec_type)
to
decode_negTokenInit(security_blob, length, server);

would get you through negotiate protocol then the only change needed
would be to SMB2_sess_setup (see lines 526 and following of fs/cifs/smb2pdu.c)
to parse the asn1 in a similar way to what we do for cifs dialect
in fs/cifs/sess.c routine sess_auth_kerberos (see liones 543 and later).

It shouldn't be too bad to finish up.

Then once negprot and session setup are working with Kerberos then
the simple use cases (SMB2 and SMB2.1 with signing disabled) should work
and then for the other use cases will also have to check if SMB2.1/SMB3 signing
needs changing for krb5 (don't know, probably not) and if
smb3_validate_negotiate
needs any minor changes for the krb5 case.

-- 
Thanks,

Steve

Re: Kerberized mount.cifs with SMB>1?

[Jurjen Bokma]

On 10/20/2014 07:09 PM, Steve French wrote:
> On Mon, Oct 20, 2014 at 11:37 AM, Jurjen Bokma <j.bokma-39IHFo8E5E0@public.gmane.org> wrote:
>> On 10/20/2014 06:24 PM, steve wrote:
>>> On 19/10/14 22:48, Jurjen Bokma wrote:
>>>> On 10/19/2014 10:42 PM, steve wrote:
>>>>> On 19/10/14 22:30, Jurjen Bokma wrote:
>>>>>
>>>>>> 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.
>>>>>>
>>>>> Yeah, of course. Never knew there was any security involved. Worrying.
>>>> Did you ever have SMB3 working Kerberized? If I know it's supposed to
>>>> work, I'll give up less easily.
>>>>
>>> Hi
>>> We have everything default. We'd no idea that smb3 existed until this
>>> thread. Anyway, it doesn't work here either:
>>> CIFS VFS: cifs_mount failed w/return code = -128
>>> I think the Kerberos has worked because that codes means that the ticket
>>> has expired, except it hasn't because removing vers=3.0 mounts fine.
>>> But we don't know if our Samba4 file servers are capable of it anyway. I
>>> think we'd have to change something in smb.conf.
>> Maybe to serve SMB3. Max protocol comes to mind. But editing smb.conf is
>> not likely necessary to merely mount a share I presume? IME mount.cifs +
>> Kerberos will work once krb5.conf and request-key are properly
>> configured, regardless of the smb.conf on the client.
>> I did fiddle a bit with /proc/fs/cifs/* though.
>>
>>> Maybe the devs will look if you bugzilla it?
>> Will try. But first I'll take a look myself, lest I don't know what to ask.
> 
> It is doable, and probably easier since the cleanup/rewrite a year or so ago
> of some of the auth code.
> 
> Note that for cifs dialect (in fs/cifs/cifssmb.c) the negotiate response calls
> decode_negTokenInit to parse the asn1 to figure out if kerberos is
> allowed (see around line 595 and following of fs/cifs/asn1.c) then compare
> with the smb2/smb3 case in which we call decode_neg_token_init
> in line 434 of fs/cifs/smb2pdu.c during the processing of the SMB2/SMB3
> negotiate protocol response.  Note that this is ifdef out (CONFIG_SMB2_ASN1)
> since this function has to be changed to match the new format
> 
> Perhaps simply changing
> 
> decode_neg_token_init(security_blob, blob_length, &server->sec_type)
> to
> decode_negTokenInit(security_blob, length, server);
> 
> would get you through negotiate protocol then the only change needed
> would be to SMB2_sess_setup (see lines 526 and following of fs/cifs/smb2pdu.c)
> to parse the asn1 in a similar way to what we do for cifs dialect
> in fs/cifs/sess.c routine sess_auth_kerberos (see liones 543 and later).
> 
> It shouldn't be too bad to finish up.
> 
> Then once negprot and session setup are working with Kerberos then
> the simple use cases (SMB2 and SMB2.1 with signing disabled) should work
> and then for the other use cases will also have to check if SMB2.1/SMB3 signing
> needs changing for krb5 (don't know, probably not) and if
> smb3_validate_negotiate
> needs any minor changes for the krb5 case.
> 
That was just the sort of intro I needed right now. Don't expect
immediate results from me though. I must cram this in between other tasks.

Thanks!
Jurjen

Re: Kerberized mount.cifs with SMB>1?

[Noel Power]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

Hi Steve, *

I came across this thread
http://thread.gmane.org/gmane.linux.kernel.cifs/10081/focus=10305 when
investigating why mount.cifs wasn't working with smb2. I have tried to
follow the information there and have created a patch. I have tested
this successfully against SMB2.0, SMB2.1, SMB3.0, SMB3.02.
Regarding the patch I followed as much as I could sess_auth_kerberos
method in cifs.c[1]. Some things I didn't quite see how to handle as
they don't seem relevant in SMB2 e.g. the unicode_oslm_strings,
unicode_domain_string, ascii_ssetup_strings handling, also I only just
noticed I missed the "bad security blob length" check (but not sure if
it is needed for smb1+) Anyway be interested in a review of the patch :-)

thanks,
Noel

[1] actually I followed CIFS_SessSetup of an older cifs version but then
when rebasing glanced at the new 'sess_auth_kerberos'

[-- Attachment #2: 0001-kerberos-mount-for-SMB2-SMB3.patch --]
[-- Type: application/mbox, Size: 8187 bytes --]