Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am in the long and arduous process of resolving my confusion over Windows permissions, and would love to get some clarity over the following.

I would like to provision a Windows share such that any anonymous Windows computer on the network (we do not use a domain controller) can type \\servername\sharename and have read-only access to the files therein.

What I know:

  • The "Everyone" group does not include the "anonymous" SID. (Though strangely, that article doesn't "apply" to 2008 R2...)
  • There are two "levels" (probably not the best word) of permissions on the files themselves: the Share Permissions and the NTFS Permissions. (i.e. Share and Storage Management -> Properties -> Permissions)
  • There are some gotchas about operating in an environment without a domain controller but with identically-named user accounts on multiple machines.

What I think I know:

  • "Making Network Services Discoverable" should have no impact on the accessibility of properly-permissioned shares.
  • NTFS permissions must ALSO be configured for this share to be accessible -- not just share permissions!(?) (Despite Share and Storage Management claiming they only apply to local access.)
  • The "Everyone" group should not be left out of access permissions even though it explicitly refers to local user accounts, BECAUSE a client computer logged on as the same username as one local to the server will try to authenticate as that user, and be denied if there is a difference in password. (*groan*)

What I don't know:

  • Are there any gotchas having to do with cached credentials or server response? Should I reboot my test client workstation after every attempt to connect to the share?
  • Should the "Guest" account have anything to do with this, on either the share or NTFS permissions?
  • Am I correct in observing the need to configure "ANONYMOUS LOGON" with read permissions on BOTH the share and NTFS permissions? Same for "Everyone" group?
share|improve this question
    
Share permissions only apply to the visibility of the share name. The content permissions are held in the file system independently. The share can also be partially hidden from compliant client by adding a '$' suffix. Cached credentials are not relevant for work group access. The client is not caching as it owns the credentials it presents. There are additional down-level protocols that also ignore case with registry keys that suppress them from use. –  Pekka Dec 19 '13 at 20:11
    
"Share permissions only apply to the visibility of the share name"' This is not true at all. Share and NTFS perms are indeed two levels of permission, and they are additive. If you are denied access at the share level (nothing to do with visibility of the share), then there aren't any NTFS permissions you can have that will grant you what you were denied. –  mfinni Dec 19 '13 at 20:26

2 Answers 2

First, setting up anonymous access to a share isn't that bad, you just have to include Anonymous in Everyone (you actually linked to it yourself):

  1. Open the Local Group Policy Manager (gpedit)
  2. Computer Configuration
  3. Windows Settings
  4. Security Settings
  5. Local Policies
  6. Security Options -- Network access: Let Everyone permissions to apply to anonymous users from Disabled to Enabled
  7. Change Network access: Restrict anonymous access to Named Pipes and Shares to disabled
  8. Network access: Shares that can be accessed anonymously - set the share name there you are sharing.

As far as the Share itself goes then. Set the Share Permissions as "Everyone - Modify" and "Administrators - Full Control". Then set the NTFS permissions as Administrators - Full Control and Everyone - <whatever rights needed>

That should handle your need.

share|improve this answer
    
So, it's preferable to change those settings rather than add the "ANONYMOUS LOGIN" security object to the share permissions? Why do "Everyone" users need 'modify' ('change'? No 'modify' on share permissions.) on the share? I created a test share that seems to be accessible with just 'read' set on "Everyone" and anon. –  NReilingh Dec 19 '13 at 20:32
    
Sorry, it's habit for me. I always set SHARE perms that way and then lock them down to read-only at the NTFS level. That way if I do require that someone suddenly needs write access I don't have to modify the share perms. –  TheCleaner Dec 19 '13 at 21:02
    
Is there a reason Administrators should have full control on the share permissions? (Presuming I never want to modify the share when connecting to it remotely) –  NReilingh Dec 20 '13 at 6:38
    
They would need it for Full Control NTFS permissions to work on the files/folders within the share. –  TheCleaner Dec 20 '13 at 14:14
    
Even if Administrators only need Full Control when accessing the files locally??? –  NReilingh Dec 20 '13 at 16:07
up vote 0 down vote accepted

Three things need to be done to set up access for anonymous users under the "Everyone" group, which is cleaner than using 'ANONYMOUS LOGON' explicitly:

1. Create the File Share

  • NTFS permissions: set 'Read & Execute', 'List Folder Contents', and 'Read' for the 'Everyone' group
  • Share permissions: set 'Read' for the "Everyone" group

2. Adjust Local Security Policy

Open "Local Security Policy", navigate to Security Settings -> Local Policies -> Security Options, and set:

  • Network access: Let Everyone permissions apply to anonymous users - Enabled
  • Network access: Restrict anonymous access to Named Pipes and Shares - Disabled
  • Edit Network access: Shares that can be accessed anonymously to be the name of the share you created. (Formatting is ambiguous, but don't include the server name, and presumedly this is a comma-delimited list if you need more than one.)

3. Allow Access Without a Password

  • Open "Advanced sharing settings", either from "Network and Sharing Center" in control panels, or by clicking the link in Properties on the directory (under Password Protection).
  • Change the "Password protected sharing" setting to off.

Other notes:

  • Permissions need to be granted for users BOTH on the NTFS and Share levels
  • Consider any testing you do on a machine logged in as a user whose name matches one on your server to be useless (but rebooting a true test machine will not be necessary)
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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