When samba runs as standalone it doesn't support kerberos, only ntlm or guest access (the ntlm would authenticates against a local db, but if the password matches the one in AD then it works automatically). If the linux machine has an SPN registered and you try to access it from a domain joined windows client using fqdn, the windows client would get a krb5 ticket and would try spnego-krb5 even though the server only advertised ntlmssp in the last negotiate packet. In this case, instead of falling back to ntlmssp the server sends NT_STATUS_INVALID_PARAMETER, which breaks both guest and ntlm access. [2019/08/30 01:55:25.791151, 2] ../../auth/ntlmssp/ntlmssp.c:119(gensec_ntlmssp_update_find) Failed to parse NTLMSSP packet: zero length [2019/08/30 01:55:25.791207, 1] ../../auth/gensec/spnego.c:1216(gensec_spnego_server_negTokenInit_step) gensec_spnego_server_negTokenInit_step: ntlmssp: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_INVALID_PARAMETER [2019/08/30 01:55:25.791266, 3] ../../source3/smbd/smb2_server.c:3266(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_INVALID_PARAMETER] || at ../../source3/smbd/smb2_sesssetup.c:146 I can reproduce on master using a windows 2k16 DC as client, wip patch attached.
Created attachment 15446 [details] wip patch
Created attachment 15447 [details] lab packet capture
Created attachment 15448 [details] smbclient tests smbclient patched to send three empty blobs against windows and against patched smbd (looping).
(In reply to Isaac Boukris from comment #3) If you look at the captures, you'll see that Windows returns NT_STATUS_INVALID_PARAMETER when it gets an empty token in the 2nd request. While a patched Samba continues. We should match Windows here and don't allow endless loops with empty blobs
(In reply to Stefan Metzmacher from comment #4) Metze, correct but this capture of samba is from the initial patch, I made two follow up patches both fixing the loop and adding a tests for it, please look in MR 754, thanks!
It would also be good to have a test with a fake gss client mech which is send before NTLMSSP and actually contains a token. Maybe we could use a fixed kerberos blob, that way we could also easily run tests against windows. As the server doesn't understand it we should fallback. In the server patch we should only ignore the empty token when we got SPNEGO_NEG_TOKEN_INIT. When we get SPNEGO_NEG_TOKEN_TARG from the client we should always pass the token to the submech even if it's empty.
Created attachment 15515 [details] pcap_smbclient_3_empty_fixed From log.smbd on fixed server: [2019/10/07 14:34:52.707754, 2] ../../auth/ntlmssp/ntlmssp.c:119(gensec_ntlmssp_update_find) Failed to parse NTLMSSP packet: zero length [2019/10/07 14:34:52.707804, 3] ../../auth/gensec/spnego.c:1444(gensec_spnego_server_negTokenTarg_step) gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_INVALID_PARAMETER [2019/10/07 14:34:52.707849, 3] ../../source3/smbd/smb2_server.c:3264(smbd_smb2_request_error_ex) smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_INVALID_PARAMETER] || at ../../source3/smbd/smb2_sesssetup.c:146
Created attachment 15535 [details] Patch for v4-10-test branch
Created attachment 15536 [details] Patch for v4-11-test branch
Comment on attachment 15535 [details] Patch for v4-10-test branch This only contains one patch out of 8
Comment on attachment 15536 [details] Patch for v4-11-test branch This only contains one patch out of 8
@asn, i see all eight commits ? btw respective pipelines: https://gitlab.com/samba-team/devel/samba/pipelines/88575553 https://gitlab.com/samba-team/devel/samba/pipelines/88576550
Marking the attachments as patch displays them correctly. I have a two intelligent text editor and it had a small button next message. I've fixed the attachments ...
Created attachment 15537 [details] Patch for v4-9-test branch This is a partial patchset for 4-9 branch which applies cleanly. It only includes the server side fix and subset of the tests. CI running at: https://gitlab.com/samba-team/devel/samba/pipelines/88642093
(In reply to Isaac Boukris from comment #14) Is this fix coming to Samba version 4.9.x ? And if yes, do you have a rough schedule for it? I'm asking because we have major issues with this bug in our customers' environment, currently running mostly version 4.8.x. We'd also love to see it as soon as possible in RHEL 7 / RHEL 8 on which around 600 servers are running here. Regards, Martin
Martin, Samba 4.9 is in security fixes only mode, see: https://wiki.samba.org/index.php/Samba_Release_Planning#General_information If you need this fixed in RHEL you should talk to your Red Hat support contact.
(In reply to Andreas Schneider from comment #16) There will be one bug fix release of 4.9 on October 22.
Pushed to autobuild-v4-{11,10,9}-test.
(In reply to Karolin Seeger from comment #18) Pushed to all branches. Closing out bug report. Thanks!