Bug 13206 - Unable to authenticate with an empty string domain ''
Unable to authenticate with an empty string domain ''
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB
4.7.4
All All
: P5 regression
: 4.8
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-08 03:42 UTC by Garming Sam
Modified: 2018-01-16 08:44 UTC (History)
2 users (show)

See Also:


Attachments
patch for master (910 bytes, patch)
2018-01-08 03:42 UTC, Garming Sam
no flags Details
trace of windows (23.58 KB, application/vnd.tcpdump.pcap)
2018-01-08 21:13 UTC, Garming Sam
no flags Details
patch for master (with tests) (7.76 KB, patch)
2018-01-08 21:22 UTC, Garming Sam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Garming Sam 2018-01-08 03:42:12 UTC
There appears to be a regression with being able to authenticate with an empty string domain since 4.7 (introduced with modified UPN handling). This was noticed when running the Microsoft test-suites which did not appear to supply a domain when required.
Comment 1 Garming Sam 2018-01-08 03:42:52 UTC
Created attachment 13895 [details]
patch for master
Comment 2 Garming Sam 2018-01-08 03:43:56 UTC
Currently working on tidying up some tests, I've verified that these tests pass on v4-6-test but not master without the patch.
Comment 3 Andrew Bartlett 2018-01-08 03:46:11 UTC
Comment on attachment 13895 [details]
patch for master

The change looks good once the tests are included.  I'll review those on the list when they land.
Comment 4 Stefan Metzmacher 2018-01-08 09:23:54 UTC
(In reply to Andrew Bartlett from comment #3)

I'd really like to see tests and captures against windows before this hits master...
Comment 5 Andrew Bartlett 2018-01-08 09:29:10 UTC
Yes, Garming tested this against windows, the test that was run will be with the change that is included. 

The original use case was actually that the Microsoft Protocol Test Suites require this for the auto-configuration!
Comment 6 Garming Sam 2018-01-08 21:13:55 UTC
Created attachment 13896 [details]
trace of windows
Comment 7 Garming Sam 2018-01-08 21:15:05 UTC
You can see in frame 44, that no domain is specified.
Comment 8 Garming Sam 2018-01-08 21:16:24 UTC
The trace was generated by the bind.py test (__main__.BindTests.test_user_account_bind_no_domain) against Windows 2012 R2.
Comment 9 Garming Sam 2018-01-08 21:22:38 UTC
Created attachment 13897 [details]
patch for master (with tests)

Sending to the list also...
Comment 10 Stefan Metzmacher 2018-01-08 21:26:03 UTC
(In reply to Garming Sam from comment #8)

In order to judge if the patch is correct, you need to use NTLMSSP against
a member server.

Are you really seeing authentication errors against Samba?
I guess "sam_ignoredomain" backend is supposed to catch that case,
but "sam" needs to be strict as that's also used in the netlogon server,
while the fallback to "sam_ignoredomain" is only called for NTLMSSP
(and legacy SMB1 authentication).
Comment 11 Garming Sam 2018-01-08 21:44:23 UTC
test: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonEx
time: 2018-01-08 21:36:44.088516Z
successful: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonEx
time: 2018-01-08 21:36:44.088681Z
time: 2018-01-08 21:36:44.088831Z
test: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonExMSCHAPv2
time: 2018-01-08 21:36:44.248944Z
successful: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonExMSCHAPv2
time: 2018-01-08 21:36:44.249050Z
time: 2018-01-08 21:36:44.249131Z
test: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonExNTLM
time: 2018-01-08 21:36:44.408952Z
successful: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonExNTLM
time: 2018-01-08 21:36:44.409092Z
time: 2018-01-08 21:36:44.409207Z
test: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonEx_no_domain
time: 2018-01-08 21:36:44.559329Z
successful: samba.tests.py_credentials.PyCredentialsTests.test_SamLogonEx_no_domain

I've now run my NETLOGON test against my Windows DC and it seems to pass as well.
Comment 12 Andrew Bartlett 2018-01-08 21:54:55 UTC
(In reply to Stefan Metzmacher from comment #10)
I would note that this patch restores the 4.6 behaviour, avoiding a real-world regression.  

Given we have test results against Windows showing that the netlogon server needed to honour this, I think the patch is reasonable.