My network admin and I are being driven up the wall by some Windows authentication weirdness -- we both have more of a background in Linux, so I apologize in advance for any of my ignorance in the following.

We have configured file shares on Windows Server 2008 R2 with read-only for anonymous access. We do NOT have a Windows domain controller on our network, so these shares are available to any computer on the network.

I have an account on this server for the purpose of RDP login, and that account has write access to the share.

On other servers, I have the same username (locally configured, as we don't have a domain controller). While trying to connect to the share from this server, I am prompted to provide a login, even though the share is supposed to be readable without a login.

What's more confusing, another account on this second server configured exactly the same as mine with the exception of username is able to connect without issue.

The substantive difference in behavior that I can see between my user account and others is that when I try to connect to the share (from the start menu, typing \\servername\), on my account I do not see the available shares "autocomplete" in the list, whereas on an otherwise identical account with a different name, they do. When I manually type the full name of the share and try to connect, I am presented with an authentication dialog: Enter Network Password (to connect to [servername]) with the "Domain" of the local machine listed beneath the password field.

To add to my confusion and frustration, we had two shares like this on different servers (call them A and B) -- I was having trouble connecting to B and not to A. Then, after removing my server B account from having read/write access to the B share (so that only 'everyone-read' remained), I could connect to B successfully, but then A stopped working.

EDIT, more info:
There was a point at which we were prompted to turn on "network discovery" while working with the share configuration, but it seemed it would have impact on more than just the shares. We don't want to "advertise" them to all windows client systems, just have them accessible when requested. And after all, any regular old system on the network was able to access it without any credentials, so I don't presume this would have had a favorable (if any) impact.

Has anyone ever seen anything like this? The best I can guess is that this would be a lot simpler if we had a domain server, and that this has something to do with having identically-named user accounts on each server, under that server's own domain. My colleagues has the same kinds of accounts and does not have this problem, so I can only assume there's some permission/security configuration I am missing on the file share server.

  • So the local user account that you're logged in with when trying to connect to the share, and the local user account on the remote system, have the same username but different passwords? Am I interpreting that correctly? – Shane Madden Dec 19 '13 at 3:43
  • The last time I tested, yes, that was the case. – NReilingh Dec 19 '13 at 5:49
  • @Shane Madden The Anonymous group is not the same as any user. It still requires an authenticated connection. If you need entirely open access, you need to provide these permissions to the group Everyone. – Pekka Dec 19 '13 at 18:17
  • @Pekka I thought it was the other way around -- that "Everyone" required an authenticated connection, but "Anonymous" allowed for open access? – NReilingh Dec 19 '13 at 18:33
  • @Shane Madden Sorry, I had the names reversed. See support.microsoft.com/kb/278259 for the full explanation. This is the reason why the mismatched passwords would have triggered the errors you were seeing. – Pekka Dec 19 '13 at 18:44

When running as a local user, Windows will always attempt to authenticate to the remote share using the logged in username and password - so if your local username and local password matched across systems, you'd automatically be authenticated.

This seems to be causing a problem in this case, as your system's trying to authenticate using the logged in user and password and getting a credential failure. I'm not quite sure why this is causing it to not fail back to just logging in anonymously, but the matching local usernames is almost certainly the cause of this strangeness.

And yes, this situation would be a lot simpler if you were using Active Directory.

| improve this answer | |
  • Damn! Tested, and you're exactly right. Thanks for the explanation! – NReilingh Dec 19 '13 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.