Posts

Managing Data Access on Windows Fileservers: Assignment of Groups

 Step 3: Assignment of Groups

Assignment of Users to IT-Objects (Folders)

The third step in properly managing data access on Windows fileservers is to use security groups for assigning permissions.

A group consists of a set of users who have been granted certain permissions. This way, implementing and managing permissions become easier rather than assigning permissions to individual users.

To give users access to data (whether the data consists of email distribution lists, file structures on file servers, or SharePoint spaces), administrators can create groups and assign them the necessary permissions.

For example:

You can give an employee from the Sales Team direct access to the folder “\\departments\sales” with “Full Control” permission. Doing so will allow the user to read the data and make changes to it. But what else will that user be able to do? With “Full Control” permission, that employee can also assign permissions and revoke them. Potentially, he/she could revoke access permissions for all other users, including administrators. Therefore, assigning such individual permissions is not considered a best practice and can lead to administrative nightmares. It is recommended to assign permissions via Active Directory groups. What if this user only needs permission to read data? Should this access be the same for each individual member of the sales team?

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-08.png

Assignment of General Security Groups to IT-Objects (Folders)

The usual, though incorrect, approach for creating permission structures is as follows:

A permission group is created for a department (e.g. Sales). At the same time, data areas will be created (e.g. file services, SharePoint spaces, and mail distributions).

The group “Sales” will then be assigned to these data areas. For example, this group gets “Write Access” permission for the file server folder “Sales” and “Read” permission on the web server. The mail distribution group is also taken care of using this authorisation group.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

Next, we are faced with the following challenges:

  • The managing director would like to have access to “Sales”, but does not want to receive email from that group. Should the managing director be automatically put into the “Sales” group?
  • A trainee starts in “Sales”. He does not need access to mail distribution, but only requires “Read” access to the data areas. What permissions should he be given?
  • An employee from Human Resources needs “Read” access to a subset of the data area, but not to the web server. How will we proceed in this case?

In all the above cases, the simplest approach is no longer viable due to the following dilemma:

The permission groups should be constructed on the basis of the organisation’s structure, not on the demands and requirements of the data objects.

Permission Groups vs. Secure Objects (Folders)

The solution for the problem described above is as follows:

For each IT object, (in our example, each folder in the file system), access requirements must be defined. For all underlying objects, (in this case, more folders and files), this will be done implicitly through inheritance of permissions. This principle means that at least one security group must be created within the Active Directory for each object requiring permission (e.g. each folder).

This assignment of dedicated permission groups to each folder with permissions has all the desired benefits for daily operations and reports.

For each folder, it is possible to say exactly who has which permissions and access to the data in said folder, such as the users who are members of these particular permission groups.

Furthermore, we know what a user’s permissions will be thanks to the uniqueness of the assignment of an object (folder) to a permission group.

It is important to give the security groups succinct and intuitive names. With a proper naming approach, the permissions can easily be associated with their specific groups, making administration easier.

You can also nest security groups (add groups to other groups) to lower the number of permissions that are required to be awarded to users or groups individually.

It can be said that a 1:1 relationship exists between the objects (our folders) and the groups within the Active Directory, while a many:many relationship exists between the users and permission groups.

For the moment, we will ignore the fact that different groups are created for “Read” and “Write” permissions.

The below diagram shows how this works:

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\index01-01.png

Different Permission Groups for One Folder

For our example, we will create three security groups within the Active Directory for each folder that requires permissions:

  • A group for the award of LIST permissions
  • A group for the award of READ Permissions
  • A group for the award of WRITE Permissions

The below screenshot shows the three permission groups for the folder “\\departments\Sales”:

“Read” permissions are assigned when a user only needs to read files within a folder. For example, all public information about a project in the folder “Project Office” or all lists with sales prices in the folder “\\departments\Sales\Items” would be covered under “Read” permissions.

“Write” permissions will be awarded only if a user needs to alter files. It is important to keep in mind that assigning “Write” permissions also gives the user the permission to delete.

In the two examples above, “Write” permissions would be assigned to the staff members in project management or the project office who create and maintain information, as well as the staff members from the sales team who specify the sales prices based on internal calculations.

List permissions are required when a user needs rights to the folders deeper down in the file tree, but he does not have “Read” or “Write” permissions for all the folders on the levels above.

This will ensure that the user can access the folder to which he/she has received permissions.

With Excel and some knowledge of scripting, it is possible to construct a simple way to create and administrate these security groups with folder permissions.

Restriction of Folder Permissions and Assignment of Permissions to Permission Groups

After all the necessary security groups have been created within the Active Directory, it is necessary to give these groups permissions for all appropriate folders. One should start with the highest folder in the hierarchy. In our example, that would be the “Sales” folder.

The process of allocation of folder permissions is done in three steps:

i). In the first step, any existing inherited permissions must be deactivated or revoked.

This will ensure that the folder will only have explicitly assigned permissions. If you deactivate the permissions, you should also delete the associated user account(s) from the Active Directory so that the user(s) no longer enjoy access.

ii). In the second step, the permissions for the administrator group must be created. The following best practices are worth taking note of:

  1. The built-in account “system” receives “Full Control” permission. This is important since the operating system uses this account for certain services and processes. Thus, you should ensure that this permission is always granted.
  2. The local group “Administrators” will likewise receive “Full Control”. This ensures that the server administrators always have access to the necessary data and permissions. In addition, some backup programs also need these permissions to function correctly.
  3. Furthermore, you should create a security group for operators and administrators with “Full Control”. This guarantees that the IT administrators have the necessary permissions for the daily operation of the file server.

iii). In the third step, the security groups created for each folder must be assigned to the folder. The awarded permissions will be assigned as follows:

Awarding Additional Permissions for Deep Data Sub-Structures

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-07.png

You should avoid setting the level for managed folders to go very deeply within your folder structure. You can limit your folder structure to go not more than the fifth level.

If there are no restrictions on the number of levels in the file structure for the assignment of permissions, the complexity of the administration tasks increases exponentially. Suppose that the average number of subfolders in a file system is 10.

The complexity of the administration and documentation of the highest-level folder will be 10. If a second level is included, the complexity will increase to 10×10 or 100.

If we further assume that the average folder depth is 10 and that there are no restrictions on folder authorisations, the management complexity will be 10 billion.

That means an IT administrator may theoretically be required to manage 10 billion permissions. This further complicates documentation, reporting, and changes.

Avoid “Deny” Permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-09.png

The need to deny a user access to a specific folder does not mean that you should use the “Deny” permission, as doing so increases the complexity of administration, documentation, and reporting by an unnecessarily large magnitude.

For example, during each assignment of permissions, all “deny” groups within the parent data areas must be checked.

When planning the folder structure, one must always keep this consideration in mind and structure the files with their permission groups in such a way that the “Deny” permission is not used at all.

In practice, this is easily possible if you present the users with a folder structure and do not capitulate to the requests of every staff member.

Do Not Use the “Share” Permission

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-10.png

When creating shares within a file system, it is possible to restrict access to the shares to which “Share” permissions have been given.

This unnecessarily doubles the complexity of administration. Instead, one should generally assign a “Write” permission.

Furthermore, to avoid unwanted attempts to gain access, one can hide the shares (by putting a $ sign at the end of the share name).

In Windows Server 2012, the “access-based enumeration” setting has the effect that a user will only be able to see a folder if he/she has a permission to see it.

Download Checklist

Click here to download a checklist that will assist you with using security groups for assigning permissions .

Next…

In the next step, we’ll talk about assigning users to active directory security groups.