Anonymous access to SMB share hosted on Server 2008 R2 Enterprise

Question

First off, I have read through this post and a whole slew of non-SF posts which seem to address the same or a similar problem, however I was still unable to fix my problem.

I've got three machines in this situation:

• a domain-joined server that runs Server 2008 R2 Enterprise ("share server")
• a domain-unjoined test server running Server 2003 R2 SP2 ("test server")
• a domain-joined workstation running XP Pro SP3 ("workstation")

The share server is exposing a share on the network that the test server must access--it's a Source/Symbol Server share for our debugging purposes. I believe visual studio simply accesses the the share with its own credentials in this case, meaning that the share must be accessible anonymously since the test server isn't joined to the domain and there's no opportunity to supply domain authentication.

I've attempted a lot of things to avoid the authentication window when accessing the share:

• I've enabled the Guest account on the share server and given Guest full sharing/NTFS permissions for the share.
• I've given ANONYMOUS LOGON full sharing/NTFS permissions for the share.
• I've added my share to “Network Access: Shares that can be accessed anonymously” in LSP.
• I've disabled “Network access: Restrict anonymous access to Named Pipes and Shares” in LSP.
• I've enabled “Network access: Let Everyone permissions apply to anonymous users” in LSP.
• Added ANONYMOUS LOGON to “Access this computer from the network” in LSP.
• Added the Guest account to “Access this computer from the network” in LSP.
• Attempted to provision the share using the Share and Storage Management MMC snap-in.

Unfortunately when I attempt to access the share from the test server, I still see the prompt and I'm forced to enter "Guest" manually.

I also tried this workflow using the local administrator account on a workstation, and the same thing happens both with and without XP Simple File Sharing enabled.

Any idea why I'm getting these results, or what I should have done differently?

Solution 1

You did everything correct with the exception of the local account accessing the share cannot be on both systems. Essentially, if the non-domain account running your application is called "administrator" then you must not have a local account on the domain server named "administrator".

Solution 2

If the username you are using the login with exists on the server but has a different password it will always prompt for the password no matter what guest and anonymous settings you have created.

Try logging in with a username that does not exist anywhere on the server or it's domain.

The other option is the make the password on the stand alone server exactly the same as it is on the identical named user on the domain.

Solution 3

Possibly temp workaround . You can create local user account(an give share\ntfs permissions) on the "share server" with same name & password as account used on your "test server" for running app accessing shares.

Solution 4

How about mapping a network drive, and utilizing a persistent connection syntax would be something like this.

net use H: \path\to\server\ PASSWORD_CLEAR_TXT /user:domain\user /persistent:yes

if at any time you want to delete it net use h: /delete

View more solutions

Comments

[Bill]

just out of curiosity, does using a more recent OS (say Windows 7, or Windows Server 2008) change anything in this scenario of workgroup joined vs. domain joined shares? It strikes me that Win2k3 server is pretty darn old and maybe it's a handshaking issue.

[Grizly]

You might have to downgrade the NTLMv3/Kerberos settings to LM.. I can't remember and don't have one on hand.

[danno]

Have you been prompted when attempting to connect to the hidden share drive C$?

[Admin]

I have the same problem for anonymous printing on one of my networks. Worked fine and just broke today. Printer status says "access denied". If I open \\\servername\ I get a credentials prompt and can enter "Guest" as the username, then things work again. Previously I didn't need to enter "Guest", the clients would connect anonymously and automatically use the server's Guest account. No recent Windows Updates and the Group Policy Results (RSOP) look sane for the server. Client (WinXP) and server (2008 R2) are on separate sides of a firewall, packet capture shows no dropped packets.

[user355002]

This requires a logged in user which isn't always available.

[bwerks]

As I understand it, the Everyone group does not apply to this scenario since the meaning of Everyone is "any authenticated user" i.e. Everyone explicitly excludes ANONYMOUS LOGON by default. Even still, just to be safe I did enable the "Let Everyone permissions apply to anonymous users" setting.

[Grizly]

That's a good point actually. The Guest credentials (not the password as such) will exist on the Test-Server and will be passed to the Share-Server, which will fail as its wrong, its for the other way around.

[Grizly]

No, it requires a script and a registry entry in either \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersio‌​n\Run or RunOnce