The following succeeds against a Windows member server joined to a Windows DC, and fails against a Samba member server joined to a Windows DC:
From a Windows client NOT joined to the domain, enter:
net use \\server-ip\share /USER:user@realm
Attached is a packet capture of the auth process. There are two NTLMSSP sessions:
- One with realm\user authentication - succeeds
- One with \user@realm authentication (empty domain) - fails.
The significance of this is that there are devices (e.g. some Xerox scanners) which are incapable of authenticating using Kerberos or as DOMAIN\user, but if you enter user@realm as username, it will authenticate as \user@realm - which succeeds with Windows.
Created attachment 12564 [details]
To reproduce using Samba tools, the following passes against a Windows member server (probably also if joined to a Samba DC, but not verified!), and fails against a Samba member server (assuming sufficinet access rights on the share):
smbtorture -k no -U 'email@example.com%admin-password' //server-ip/share smb2.getinfo
(haven't spotted an smbtorture test that just authenticates, the smb2.getinfo does some basic file IO in addition to session setup)
Created attachment 12598 [details]
git-am fix for 4.5.next
Re-assigning to Karolin for inclusion in 4.5.next.
(In reply to Jeremy Allison from comment #4)
Pushed to autobuild-v4-5-test.
(In reply to Karolin Seeger from comment #5)
Pushed to v4-5-test.
Closing out bug report.