What are the best Practices for default Local Groups in a Windows Server 2008?

Posted on 2011-03-08
Last Modified: 2012-05-11
We are currently working with Windows Server 2003 and 2008.

We recently had an issue with some shared folders being accidentally being shared with everyone in the comopany, which is a potential security risk.

The issue was that shared folders were being granted access to everyone and the security was being done by NTFS access.
The problem was that by default all folders in a server are granted read access to the local users group and further investigation let us know that by default the "Domain Users" group is assigned to the local users group, thus implicitly all shared folders where being granted read access to all company users.

Now what would you suggest to prevent this from happening?

(A) Shared folders should not be granted access to "Everyone" unless is required to be that way.

(B) Remove the "domain Users" and "authenticated users" from the local users group which is automatically added when a server is added to the domain.

(C) Remove the local Users group from the folder that is being shared.

I feel option (B) is the most secure, but I'm afraid it may affect the servers performance or that some services may stop working correctly
My 2nd option would be option (A) since i feel i have more control over who has access to the shares and prevents access being granted accidentally because of inheritage of folders.

Option (C) seems to me is error prone but is the way we are working right now and in my opinion we should stop doing that.

What do experts advice?
Question by:hispanicteleservices
LVL 18

Assisted Solution

by:Jeremy Weisinger
Jeremy Weisinger earned 83 total points
ID: 35075734
Actually I recommend option C. You should know the permissions set on folders that are shared.

Option A: It's true that you can use this method but then you still have to modify the NTFS permissions and therefore can make things more complex when troubleshooting access and control issues

Option B: You should not do this. Domain Users should be left in the local Users group

Option C: This is the best option in my opinion. I always setup shares so that the share permissions are Everyone Full Control and then just use NTFS to control the security of the files and folders.
LVL 16

Accepted Solution

Bruno PACI earned 84 total points
ID: 35075740

In my opinion, the (B) option must be forget because the local group membership is not only useful for file access. A lot of local policies uses local groups to control access to the server and removing "domain users" or "authenticated users" from the "Users" local group will have a lot of side effects on your server.

Option (A) is securely a good option (why allow access is it is not needed) but in practice it's usually not easy to implement because under one share you can find a lot of subdirectories, each one with its own permissions. Removing "everyone" access one the share level will force you to enumerate all permissions given on subdirectories to ensure that permissions on the share include at least all of them.
This is really a big job and a time consuming task, probably so much time consuming that your administrators will give up and will re-use "everyone group" on share permissions for most of your shares.

That's why in practice our customers avoid to manage permission at share level by giving "All access" to this group on the shares. Then, they can concentrate on NTFS permissions.

So, option (C) is certainly the most realistic way to manage permissions on your file ressources as soon as you have a lot of files and directories with different permissions.

Have a food day.
LVL 42

Assisted Solution

kevinhsieh earned 83 total points
ID: 35077292
Option C is the recommended practice. You can't really control things through share permissions, and default share permissions used to be everyone full. That's how I set my shares and I control access via NTFS. You should remove inheritance from the top folder in your share and then set the NTFS permissions from there.
Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.


Author Comment

ID: 35078571
Thank you, i guess that's unanimous. Option C it is.
I might add that what I had in mind with option A is to have control over what permissions are being set within the subdirectories.

Parent Folder A
   Subfolder A
       subfolder B

If some users needs read access to Folder A, I create a share for A and grant those users read access to share A
If someone in that group also needs write access to subfolder B, I create a separate share for B and grant write access to that one user (so the user could use the parent A share to write in subfolder B or use the subfolder B share to write).
And so on for every new access needed (using groups of course).

This way I know through the shares what accesses have been granted at any level in the directory tree.

It has happended before in our company that after a few years of using a big share (thousands of directories and subdirectories), some folders inherit permissions, some don't and in the end we lose control of the inheritance of the folder and no longer know who has access to what nor who should and who shouldn't unless you have a good documentation for that.

Of course, this probably could end up with more shares than you would want to in a single server and you would have to come up with a heck of a good standard for naming all those shares.

LVL 42

Expert Comment

ID: 35079568
The problem would also be that you couldn't have subfolders with more restrictive access if you tried to do everything at the share level. Tis is also a good reason not to give users Full access over the folders. If they don't have Full control, they can't change permissions. This at least makes it plausable that the server administrators can setup things properly and that the configuration won't drift too much.
LVL 16

Expert Comment

by:Bruno PACI
ID: 35085911

I'm sorry but your solution to use specific shares with specific permissions is not a good one. You give an example that is simple and in that case, yes, it works like you want.

But now, let's suppose you want to give users write access on the parent folder A (so with your method you will create a share for the parent folder with write permissions on it). Until there, it's works mike you want... now you want to create a subfolder where these users must only bu allowed to read (no write access). With the "shares" solution you can not prohibit users that have write access on the parent share to write in the subfolder !
The only solution is then to user NTFS permissions on the subfolder. You will obtain a very complex folder structure that uses some share permissions and dome NTFS permissions. It will be very hard for administrators to finally know what final permissions a user has on a particular folder because thay'll have to take care of share permissions AND NTFS permissions.

That's why the best practice is to avoid managing share permission level by configuring them as All access fo Everyone and only manage permissions at NTFS level.

You told that with NTFS permissions you may obtain some bad side effects abotu inherited rights and non inherited rights and have finally a complex permission structure.
That's not really true in my opinion. on NTFS you are able to define which rights are inheritable and which are not.
So you have all the tools to make a clear permissions structure and if your administrators take a little care of that structure it will stay stable during time.

There are some basic rules you have to care of, as an example: never give "Full Access" to users to allow a write access. "Full access" is to much because it permit users to change rights and then to change inheritance. Only SYSTEM and "Administrators" should be granted "Full access" permissions.
Also, remove "CREATOR OWNER" permissions everywhere...

Some basic rules will help you to maintain a simple and efficient NTFS structure.

Have a good day

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A procedure for exporting installed hotfix details of remote computers using powershell
This article describes my battle tested process for setting up delegation. I use this process anywhere that I need to setup delegation. In the article I will show how it applies to Active Directory
This tutorial will walk an individual through the steps necessary to enable the VMware\Hyper-V licensed feature of Backup Exec 2012. In addition, how to add a VMware server and configure a backup job. The first step is to acquire the necessary licen…
This video shows how to use Hyena, from SystemTools Software, to bulk import 100 user accounts from an external text file. View in 1080p for best video quality.

828 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question