On Mon, Oct 20, 2014 at 11:37 AM, Jurjen Bokma <j.bokma@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
