[Last Call] Learn about multicloud storage options and how to improve your company's cloud strategy. Register Now

x
?
Solved

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

Posted on 2011-03-08
6
Medium Priority
?
809 Views
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?
0
Comment
Question by:hispanicteleservices
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
6 Comments
 
LVL 22

Assisted Solution

by:Jeremy Weisinger
Jeremy Weisinger earned 332 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.
0
 
LVL 16

Accepted Solution

by:
Bruno PACI earned 336 total points
ID: 35075740
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
 
LVL 42

Assisted Solution

by:kevinhsieh
kevinhsieh earned 332 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.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 

Author Comment

by:hispanicteleservices
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.
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
 
LVL 42

Expert Comment

by:kevinhsieh
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.
0
 
LVL 16

Expert Comment

by:Bruno PACI
ID: 35085911
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

Tech or Treat!

Submit an article about your scariest tech experience—and the solution—and you’ll be automatically entered to win one of 4 fantastic tech gadgets.

Question has a verified solution.

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

Uncontrolled local administrators groups within any organization pose a huge security risk. Because these groups are locally managed it becomes difficult to audit and maintain them.
This article provides a convenient collection of links to Microsoft provided Security Patches for operating systems that have reached their End of Life support cycle. Included operating systems covered by this article are Windows XP,  Windows Server…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …
There are cases when e.g. an IT administrator wants to have full access and view into selected mailboxes on Exchange server, directly from his own email account in Outlook or Outlook Web Access. This proves useful when for example administrator want…
Suggested Courses

650 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