This is an old one but still I see it everywhere on fileservers.

When you’re about to modify an ACL on a folder or share do you recognize this picture:

From a Windows Vista/2008 Server and later you probably also recognize this picture:

-Well of course I want access permanently, I’m one of the file share admins.

Click Continue!

Well that’s one of the reasons why your security tab is bloated and over time could be quite big and have a lots of unknown accounts.

Let’s break this down…

Scenario 1:

When a user needs access to a folder the admin go to Properties of that folder and add the user to the security tab.

Advantage: The user gets access.

Disadvantage: Over time the list in Security tab could be very long, the user could be spread to different root folders and subfolders making it hard to remove access and worse if inheritance is broken. If user account in Active Directory is deleted, the ACLs won’t be deleted, you will only see Account Unknown(SID). Local administration on fileservers. This could be a big administrative burden and is hard to overview.

Scenario 2:

On Windows Vista/2008 Server and later.

Users that create, administer and work in the folders is only member of the local administrators group (or worse Domain Admins).

If user A creates the folder and user B want to add a subfolder he will get the permissions denied when he tries to entry the root folder, but he is local admin on the server so he thinks this is weird and continues to get his permissions so he can complete his work.

Advantage: The user can complete his work.

Disadvantage: Over time the list in Security tab could be very long, the user could be spread to different root folders and subfolders making it hard to remove access and worse if inheritance is broken. If user account in Active Directory is deleted, the ACLs won’t be deleted, you will only see Account Unknown(SID). Local administration on fileservers. This could be a big administrative burden and is hard to overview.

Why does this happen in scenario 2 you may ask (I can’t count how many times I have heard this question).

The easy answer is:

In Windows Vista and 2008 Server UAC arrived and is still working.

From MS:

Assume that User Account Control (UAC) is enabled, and you use Windows Explorer to access a folder for which you don’t have Read permissions. Additionally, the folder is not marked by both the Hidden and System attributes. In this situation, Windows Explorer displays a dialog box that prompts you with the following:

You don’t currently have permission to access this folder. Click Continue to permanently get access to this folder.

Note In Windows Vista and Windows Server 2008, the second sentence does not include the word “permanently”; it just says “Click Continue to get access to this folder.”

You then have the option to click Continue or Cancel. (Continue is selected by default.) If you click Continue, UAC tries to obtain administrative rights on your behalf. Depending on the UAC security settings that control the behavior of the UAC elevation prompt, and on whether you are a member of the Administrators group, you may be prompted for consent or for credentials. Or, you may not be prompted at all. If UAC can obtain administrative rights, a background process will change the permissions on the folder, and on all its subfolders and files, to grant your user account access to them. In Windows Vista and Windows Server 2008, the background process grants your user account Read and Execute permissions. In later versions of Windows, this process grants your user account Full Control.

http://support.microsoft.com/kb/950934

So, another reason for disabling good old UAC 🙂

Quick answer:

NO! There is better reasons for having it enabled.

http://technet.microsoft.com/en-us/library/dd834802.aspx

But, how can we easily manage files and folders permissions?

We take help from Active Directory.

Create a Domain Local Security Group. Take advantage of using a good naming convention and use the Description and Notes fields of the Object.

Give this group the appropriate permissions on the folder/share. Add users to the group.

And voila! The users that is member of that group will never get that annoying prompt that he hasn’t access even dough he in some way have it. Sorry that I can’t show you a picture of this working, but you just have to trust me and try this at home.

Advantage: Moves administration to a central point (ADUC). If you give users access with security groups you could make your access control lists pretty clean. You could easily overview which users have access by looking in the “Members” tab of the security group, or you can look at the user objects “Member of” tab to see a complete list of what that user has access to.

Disadvantage: In large environments you could get troubles with token bloat (but that’s another story).

Group Policy:

And at last if the local administrator or e.g. Domain Admins (which not should be used!) still wants to mess up the ACLs we have some Group Policys that could be activated on the fileservers.

(Note. Disabling UAC features could reduce the overall security on the fileservers. And incorrectly used all servers.)

In the GPMC create a new GPO and edit it. navigate to:

Computer Configuration –> Windows Settings –> Security Settings –> Local Policies –> Security Options

Configure these three policys:

1. User Account Control: Admin Approval Mode for the Built-in Administrator account – Disabled
2. User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode – Elevate without prompting
3. User Account Control: Run all administrators in Admin Approval Mode – Disabled

Link the GPO to your Fileserver OU.

Summary:

If you work with security groups in Active Directory you only need to set the Access Control List (ACL) for that folder once when you create it. And then all the administration moves to ADUC (or the newer Administrative Center if you prefer that).

If you delete a user or remove him from the ACL group, you will never see an unknown SID again.

But what if you delete that group you ask, well, that group should exist for as long as the folder exist. Delete both when you’re done with it.

Easy and clean daily administration from one central point (ADUC) with no weird prompts about permissions.