1

I want to create a shared folder under Windows (actually, Windows XP, Vista, and Win 7) which can be mounted from a linux system without prompting for a username/password. But before attempting this, I first wanted to establish that this works between two Windows 7 machines.

So, on machine A (The server that will hold the public share), I created a folder and set its permissions such that Everyone has read/write access. Then I visited Control Panel -> Network and Sharing Center -> Advanced Sharing Settings and then selected "Turn off password protected sharing". Then, on machine B (The client that wants to access the public share with no username/password prompt), I tried to "map network driver" and I was immediately prompted by a password prompt.

Some search on google suggested changing "Acconts: Limit local account use of blank passwords to console logon only" to "Disabled". Tried that, no luck, still getting username/password prompt.

If I enter the username/password, I am not prompted for it again and can use the share as long as the session is active. But still, I really need to access the share without any username/password transaction whatsoever and this is not just a convenience related thing. Here is the actual reason: The device that will access this windows network share is an embedded system running uclinux. It will mount this share locally and then play media files. Its only user interface is a javascript based web page. So, if there is going to be any username/password transaction, I would have to ask the user to enter them over the web page, which will be ridiculously insecure and completely exposed to packet sniffing.

After hours of doing experiments, I have found one way to make this happen, but I am not really very fond of it... I first create a new user (shareuser) and give it a password (sharepass). Then I open Group Policy Editor and set "Deny log on locally" to "A\shareuser". Then, I create a folder on A and share it so that shareuser has Read access to it. This way, shareuser cannot login to A, but can access the shared folder. And, if someone discovers the shareuser/sharepass through network sniffing, they can just access the shared folder, but can't logon to A.

The same thing can be achieved by enabling the Guest user and then going to Group Policy Editor and deleting the "Guest" from the "Deny access to this computer from the network" setting. Again, Guest can mount the public share, but logging in to A as Guest won't be possible, because Guest is already not allowed to log in by default.

So my question would be, how can I create a network share that is truly public, so that it can be mounted from a linux machine without requiring a password? Sorry for the long question, but I wanted to explain the reason for really needing this...

Improve this question
5
  • Just for completeness, I considered using the Windows 7 Homegroup thing. But this seems to be strictly Windows 7 related and won't work with Vista and XP. I need to be able to mount shares on Win7, Vista, and XP
    – Timur Aydin
    Oct 12, 2012 at 20:32
  • I also tried enabling the "Public Music" folders, but still, wasn't able to avoid the username/password prompts.
    – Timur Aydin
    Oct 12, 2012 at 20:33
  • I think you're on the right track with the "Guest" account. That's the classic user account associated with anon access to a SMB share.
    – Chris Smith
    Oct 12, 2012 at 20:33
  • Thanks for the answer, Chris. the problem with that approach is the difficulty of explaining that to a customer. The Group Policy Editor is quite intimidating
    – Timur Aydin
    Oct 12, 2012 at 20:50
  • We won't have this problem with users that store their music collection on a NAS. This is because almost all NAS's are running samba, which does support truly public shared folders. Also, when we add support for UPNP and DLNA, this will become less of a problem.
    – Timur Aydin
    Oct 12, 2012 at 20:51

1 Answer 1

Reset to default
0

As far as I can tell, Microsoft considers anon access of any kind to be a security risk, possible only for legacy support. For good reason, really. That's why it's such a pain to enable it.

You already have a process to make it work by modifying system policy entries, so what you need is a way to do that programmatically.

Since the group policy options are just registry entries, find out which ones correspond to enabling the guest account for remote access and modify them during an elevated installation process. The mapping between policy options and registry entries are kept in the .admx files in your C:\Windows\PolicyDefinitions directory.

It's not the prettiest solution and an open share would compromise security but it should work.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .