I'm setting up an automated process on one Windows machine that backs up data from another. The process will run as a local account that exists on both machines and matches user name and password. I'm using the ability of windows to use matching accounts to provide login-less "authentication" which I have used numerous time without issue. However, now I'm encountering problems.
The following two machines are involved:
DEV03
- Windows Server 2008 R2 x64 (happens to be a VMware VM, not that it should matter)
- IP: 10.12.48.97, 10.12.48.88
DEV04
- Windows Server 2003 x86
- IP: 10.12.48.126
Neither of these machines are in an Active Directory domain nor can I place them in one. They are both, however, in the same workgroup.
An account with user name administrator
exists on both machines with the same password. The account is in the local Administrators
group on each machine.
I RDP into both machines and log in using the administrator
account. I then start a regular command prompt from the start menu one of two ways:
- started regularly, running as the desktop session's logged in user (
administrator
). This is noted in the below results as(logon)
- started with "Run as different user" (2008) or "Run as..." (2003). I still use the
administrator
account, entered manually. (I realize this seems odd and shouldn't matter, but I included it to be sure I wasn't going crazy and because I'm sure I got different results, but maybe not now that I retest and lay it all out.) This is noted in the results as the account name,administrator
Once in the command prompt I issue a simple dir
command on an administrative share on the other machine.
Here's the test result breakdown:
Test RDP ON Run As Dir of Result
=================================================================
1 DEV03 (logon) \\10.12.48.126\c$ Succeeds
2 DEV03 administrator \\10.12.48.126\c$ Succeeds
3 DEV03 (logon) \\DEV04\c$ 'Access is denied.'
4 DEV03 administrator \\DEV04\c$ 'Access is denied.'
-----------------------------------------------------------------
5 DEV04 (logon) \\10.12.48.88\c$ Succeeds
6 DEV04 administrator \\10.12.48.88\c$ Succeeds
7 DEV04 (logon) \\10.12.48.97\c$ 'Logon failure: unknown user name or bad password.'
8 DEV04 administrator \\10.12.48.97\c$ 'Logon failure: unknown user name or bad password.'
9 DEV04 (logon) \\DEV03\c$ Succeeds
10 DEV04 administrator \\DEV03\c$ Succeeds
Pinging DEV03 from DEV04 returns the .88 IP. So I am beginning to think this problem has something to do with the host name. However, I have never encountered this problem before, despite having servers with multiple IP addresses, which makes me suspect Window Server 2008 a little.
I have rebooted both servers and flushed DNS for good measure.
I'm mostly concerned with tests 5 thru 8. Why would the connections behave differently based on the inbound IP address? I don't see anything in IP settings on the server that suggest some difference in authentication behavior. Certainly it's not a firewall issue because it's connecting, just failing authentication.
Are user accounts associated to a windows server host name? Is it possible that the server is associating the host name with the first IP (.88) (event though that was added second) and not recognizing it for the other IP?
Your best bet is to take a sniffer (say, Wireshark) and see the packets. They will tell you what exactly happens out there. Windows has many peculiarities in SMB logon procedure, in particular, algorithms to logon via a simple host name, full DNS name and IP address are all different.
My guesses: you may be required to login as
<target host name>\administrator
in certain cases, your 2-IP server might have some differences in SMB configuration between the 2 addresses, you may have cached logons for some of your test cases.Also, if the 2 IPs of your server are assigneed to the same NIC, i'd advise you to drop one of them as a needless hurdle: if a NIC has multiple IPs, Windows only uses one of them for outbound connections.