13

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?

bwerks
  • 752
  • 3
  • 10
  • 22
  • I think you've switched "test server" and "workstation" in the machine list, or am I just not following this? – charlesbridge Mar 30 '11 at 18:57
  • I have performed this type of procedure many times. Some of your steps I don't have. The one thing I can think of missing is giving Everyone access to the share and file system. Does that help? – Jeremy Mar 31 '11 at 15:58
  • 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. – Jeff Atwood May 22 '11 at 09:21
  • You might have to downgrade the NTLMv3/Kerberos settings to LM.. I can't remember and don't have one on hand. – Grizly Oct 23 '11 at 09:03
  • Have you been prompted when attempting to connect to the hidden share drive C$? – danno Apr 17 '12 at 18:19
  • 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. –  Mar 14 '13 at 06:28

8 Answers8

4

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".

Magellan
  • 4,431
  • 3
  • 29
  • 53
lllukej
  • 41
  • 2
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.

QueBall
  • 31
  • 2
  • 1
    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 Aug 09 '12 at 23:20
1

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

Nick O'Neil
  • 1,769
  • 11
  • 10
  • This requires a logged in user which isn't always available. – NotMe Apr 05 '11 at 18:44
  • No, it requires a script and a registry entry in either \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or RunOnce – Grizly Aug 09 '12 at 23:23
1

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.

Valeriy.N
  • 11
  • 1
0

I can't see that you've added EVERYONE to the network share/security permissions, Guest (once enabled) should be included in this group. As described here.

Also some good answers here, relating to a similar questions (2003).

BoyMars
  • 1,012
  • 1
  • 6
  • 15
  • 3
    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. – bwerks May 06 '11 at 07:34
0

Have you run through this article (below) in detail? It's not so much a list of steps, as a detailed top-bottom for how this functionality happens.

http://www.minasi.com/newsletters/nws0312.htm

Brandon Langley
  • 201
  • 2
  • 3
0

Have you tried explicitly adding the computer account, i.e. computername$ to have permissions on the share and via NTFS? Obviously, this wouldn't work with non-domain joined machines.

Dave P
  • 396
  • 1
  • 4
0

It is always going to prompt until you do one of two things. Both acomplish the same task of caching the credentials (which ironically in this case do not matter but still need to be present).

One is to map the drive and make the mapping persistent. The other is to open up credential manager directly and add a login (any login) for the server you are connecting to. Credential Manager is accessed from the users control panel item or directly at "Control Panel\All Control Panel Items\Credential Manager".

Bryansix
  • 11
  • 1