I've stumbled over this kind of misbehavior when connecting from Win2012R2 to Samba 3.6.6, in a "workgroup environment" (no proper NT domain).
Neither of the following two versions would work reliably:
NET USE X: \\server\share password /User:username
NET USE X: \\server\share /User:username password
Curiously, there was maybe 10% chance that it would work though!
And, if I tried skipping the password from among the cmdline args, and have "NET USE" prompt me, the chances were like 95% positive.
I had another share on a different server (Linux with a different upgrade history and config) that worked just fine.
Initially I suspected "special characters", because my new password was "stronger". I tried single or double quotes around the password, to no avail.
I tried making a very simple (and weak) password - to no avail.
I then found advice to first use cmdkey to save the correct logon credentials locally. This had never been required before, but I tried nonetheless:
cmdkey /add:<machine> /user:<username> /pass:<password>
This way I did save the credentials for the logged-in user at the client machine, but it did not solve the mysterious logon failures from NET USE.
Then I went fumbling in Samba config and logs.
When debugging Samba auth, the following smb.conf option may come in handy:
log level = 3 passdb:10 auth:10
The default is probably log level = 2, which doesn't even log failed login attempts.
Samba creates useful log files in /var/log/samba/.
For each incoming client machine, it creates two files:
log.<ip_address>
log.<netbios_name>
With an elevated log level, it's clearly visible that the IP-based log ends at the point where smbd learns the NetBios name of the machine - and continues in the second file.
And it was also clearly visible, that the "password verification" is actually quite a complex process :-) Both the CIFS network handshake has several exchanges of data, and the processing of the credentials on part of the Samba server is not exactly trivial either. On both successful and failed attempts, at the aforementioned log level 10 (selective for auth and passdb), you get two pages of dense log listing, where Samba hints at how it tries to prepend a domain and how it tries to map a user via username map, before finally trying to check the credentials (at least twice). Curiously, the process is slightly different for the two different usage styles of NET USE on the client: with password on the cmdline (syntax makes no difference) vs. with a password prompt. The precise process will likely also depend on the auth backend that you've chosen on the Samba server. Mine wass the simple old passdb (/etc/samba/smbpasswd).
To me, it has turned out that the culprit was probably the username map feature. The smb.conf on the Samba server is not my own baby, I learned about this feature along the way. I've found other people's warning that it can bite. It can even be used to map multiple Windows users to a single local UNIX user, or just 1:1 - either way, note that Samba will try to look up (verify) the logon credentials using the "remapped" username, rather than the original Windows username (which you can also have entered in the smbpasswd). Which was possibly my problem. As soon as I removed the "culprit username" from /etc/samba/smbusers, my NET USE line started to work, in either of the two formats with password at the cmdline.
Not sure why Samba sometimes tries the Windows username, while at other times it tries the remapped username. It may be a "feature" specific to the particular historical version of smbd and passdb. Or to a particular interaction of different CIFS implementations at the client and the server.
And then I had a follow-up problem (after auth) where security = user combined with group-accessible underlying directories and a misconfigured group in /etc/passwd (and /etc/group) meant that my clients logged in, but were denied access to such CIFS directories... Note that in some distroes or config styles,
all the UNIX users share a "users" default group, while in other distroes they get assigned an individual default group, newly created for each new user...
What use is this answer for a scenario, where the server is a Windows 2003 machine? Probably not much use, except for the general background, that CIFS has a long history / evolution behind it, and the various Windows CIFS generations may feature similar "cross-compatibility quirks" as the open-source Samba implementation. Start from policies permitting or denying older versions of the auth protocols: LanMan and NTLM1, which can in general become administratively forbidden on a more modern client or server, for security reasons (principal deficiencies in the old protocols). I specifically recall a situation where windows 7 (or was it Windows 8?) started insisting on NTLMv2 in the default config.
