[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 812
  • Last Modified:

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

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?
0
hispanicteleservices
Asked:
hispanicteleservices
3 Solutions
 
Jeremy WeisingerSenior Network Consultant / EngineerCommented:
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.
0
 
Bruno PACIIT ConsultantCommented:
Hi,

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.
0
 
kevinhsiehCommented:
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.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
hispanicteleservicesAuthor Commented:
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.
Ex.

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.

0
 
kevinhsiehCommented:
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.
0
 
Bruno PACIIT ConsultantCommented:
Hi,

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
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now