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] packet capture
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 'administrator@domain.fqdn%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. Thanks!