I'm not sure what your level of familiarity is with Wireshark, so my apologies if this is too verbose or terse. ;-)
Essentially you'd want to install and start Wireshark on either end – it shouldn't matter which – and begin capturing on the appropriate interface:
- In Wireshark, click the
Capture menu, then Options…
- Select the appropriate interface.
- Since you mention you're not on a domain, I'd suggest entering a
Capture Filter to limit the amount of captured traffic, something like:
host 169.254.255.127
The IP address should be for the remote host.
Start the capture, then attempt to browse the share.- Wait until the share appears, or you are presented with an invalid username/password box, then stop the capture.
I might suggest that you do this twice from each location; first, with a correct username and password; and second, with an invalid username and/or password. In between each attempt, be sure to disconnect from the remote share (so that it will re-request authentication), by doing:
net use \\remoteserver\SharedFolder /delete
What we are looking for here is SMB data, so the first way to prune out everything unrelated is to apply a simple Display filter in the Filter: field in the toolbars:
smb
In the beginning, you should see essentially three types of transmissions in the Info field:
Negotiate Protocol Request/Response
These show the protocols supported by the client, and which protocol was accepted by the server. You can expand this out in the Packet details section to see whether the server is using NTLM, Kerberos, etc.Session Setup AndX Request/Response
This is authentication, which is hopefully happening in a challenge/response style. You'll see several possible Responses from the server:
STATUS_MORE_PROCESSING_REQUIRED: authentication is underway.STATUS_LOGON_FAILURE: this is a logon failure – you will be most interested in these!- (nothing), in which case you can expand
SMB > SMB Header and look for NT Status: STATUS_SUCCESS, which indicates a successful authentication.
Tree Connect AndX Request/Response
This is the client asking to connect to a particular location on the server; you'll typically see accesses to IPC$ as well as the share you really want.
So what you're actually looking for, then, are lines that say STATUS_LOGON_FAILURE. Then, look one line above that to see which user failed to authenticate.
Now, it's typical to see login failures whenever you browse a share; that's because Windows tries to authenticate using the logged-on user account first. So don't be surprised to see, even between the "modern" OS families (2k3, Vista, 2k8), logon failures.
When I ran this test earlier, I saw three logon failures with LOCALCOMPUTER\localuser before it even tried to use REMOTECOMPUTER\remoteuser (which, in my case, succeeded on the first try). And when I tried it against a machine on another domain, I got ten logon failures! That's before it even prompted me for alternate credentials.
If you want to filter out everything but authentication, change the display filter to:
smb.cmd == 0x73
To see a list of all logon failures, change the display filter to:
smb.nt_status == 0xc000006d
Keep in mind that these logon failures might not have any impact, as typically the account won't exist on the remote machine (so there is no "negative accounting", so to speak, to be done for it).
Edit: You might want to pause for a few seconds when it prompts for alternate credentials, so that you have a clear idea of which authentication failures belong to the "automated" attempts, and which belong to you deliberately mistyping the credentials.
Let us know what you find out!
Best Answer
Try saving RDP files using MSTSC. There may be a bug with caching them and selecting the servers from the drop-down menu.
How about looking here? Microsoft