The Samba-Bugzilla – Bug 13206
Unable to authenticate with an empty string domain ''
Last modified: 2018-01-16 08:44:01 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.
Created attachment 13895 [details]
patch for master
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 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.
(In reply to Andrew Bartlett from comment #3)
I'd really like to see tests and captures against windows before this hits master...
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!
Created attachment 13896 [details]
trace of windows
You can see in frame 44, that no domain is specified.
The trace was generated by the bind.py test (__main__.BindTests.test_user_account_bind_no_domain) against Windows 2012 R2.
Created attachment 13897 [details]
patch for master (with tests)
Sending to the list also...
(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).
time: 2018-01-08 21:36:44.088516Z
time: 2018-01-08 21:36:44.088681Z
time: 2018-01-08 21:36:44.088831Z
time: 2018-01-08 21:36:44.248944Z
time: 2018-01-08 21:36:44.249050Z
time: 2018-01-08 21:36:44.249131Z
time: 2018-01-08 21:36:44.408952Z
time: 2018-01-08 21:36:44.409092Z
time: 2018-01-08 21:36:44.409207Z
time: 2018-01-08 21:36:44.559329Z
I've now run my NETLOGON test against my Windows DC and it seems to pass as well.
(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.