The following are what I call the Golden Rules of Permissions Administration. These rules were developed through years of file server administration but generally apply to any application administration like SQL Server, Sharepoint server, Active Directory, etc.

The Golden Rules of Permissions Administration can be thought of as a hierarchy of best practices, the very best practice being the last rule in the list. Each “rule” represents an evolutionary step forward in the way administration is performed. As you gain understanding of the purpose of each rule you will start to appreciate that as each rule is implemented greater and greater flexibility and ease of administration is achieved.

The ultimate goal of these rules and administration in general is to simplify (greatly reduce the amount of time it takes to perform) daily administration of permissions over the long run. However, to achieve this goal there is more initial setup and configuration involved. If you find yourself reading the rules and concerning yourself with the extra work it takes to implement the next rule, then you are thinking about your work in the wrong terms…reactively, while the Golden Rules of Permissions Administration is truly a proactive approach and ultimately a time saver.

The Golden Rules of Permissions Administration

1. Never give “end users” the ability to administer permissions: instead insure that only professional administrators for the application can administer permissions. This will prevent problems in the long run.
2. Never assign permissions to an individual user: instead place the user into a group and assign permissions to the group.
3. Never assign permissions to an individual file (or object): instead place the file (or object) into a folder (or group, etc) and assign permissions to the folder (or group, etc).
4. Never assign permissions to a “user group”: instead create a specific “resource group” and place the users and/or “user groups” into that “resource group.”
5. Always assign permissions in a Resource Security Model: this requires a very high level view of the organization and great understanding of the individual application and needs of the organization.

Rule 1: Never give “end users” the ability to administer permissions.

First lets start be defining what an “end user” is. As it pertains to these rules an “end user” is anyone not willing to and/or not trained to follow all of these Golden Rules of Permissions Administration. That’s a pretty broad spectrum of people. I assume that most people reading this document have an Information Technology (IT) background, so the “end users” could be IT managers, developers or programmers, system administrators, helpdesk, security engineers, SQL server administrators, and other application specific IT professionals, in addition to the more common “end users” of non IT employees. Yes, as it pertains to this rule all these people are considered “end users” if they are not willing, not properly trained, or simply unable to follow (because lack of access to appropriate tools) the Golden Rules of Permissions Administration.

The entire point of defining “end users” is to highlight the importance of properly defining how administration should be done in your environment and not viewing administration as an “anyone can do it” type of job, because no one can do administration equally as well as a professional administrator following these rules.

The other item to note about “end users” that do permission administration is that they will never move beyond rule 2 or 3 of the Golden Rules of Permissions Administration. Therefore, these sub par implementations will forever burden professional administrators that will come in after the fact to fix the issues and problems. The reason for this is not simply because of a lack of skill or a lack of training, it is more likely they will not have access to the higher level administrative tools needed to create and/or access groups needed for rules 4 and 5 to be implemented. Also, even if they had access to these tools, the “end users” view of the company and technology may be so limited that their implementations usually have short comings in the long run.

Rule 2: Never assign permissions to an individual user

So much has been written about this rule that it almost seems pointless to discuss, but yet still poorly trained or lazy administrators will give access to individual users. There is only one instance in which an individual user should be assigned permissions directly to an object, which is when implementing a user home directory. This is the only time it is deemed necessary to assign permissions directly to the user. However, a caveat to this rule is that Rule 1 should also be followed. By not allowing the user to modify rights to their home directory you allow for a more secure environment. This is because when done properly only on administrator will have the ability to modify permissions to gain entry into the user directory, thus maintaining a solid barrier from tampering by other employees or by the individual users themselves.

Rule 3: Never assign permissions to an individual file (or object)

A core theme of the Golden Rules of Permission Administration is that individual objects and users are grouped together and permissions are always assigned by groups of users to groups of objects that require the same permissions. If you assign permissions to individual files or other objects that can be grouped together using folders (or other grouping methods) then you have missed a major opportunity to simplify your administration. The reason your administration will be simplified is because you can simply add files to the folder (or other grouping method) to assign the same permissions in the future to the same files.

Unfortunately, not all items that you can assign permissions to can be grouped. If this is the case then you are left with no choice but to assign a group of users to the individual item. This is rare and is the exception and not the rule. But you should always assign permissions to a grouping object and not the individual object when possible.

Rule 4: Never assign permissions to a “User Group”

To simplify this explanation we will use the following definition of a “User Group”. A “User Group” is a group created with members based on the idea that the users have something in common other than a resource to which they are being given access to. These are things that users will always have in common, and are things that other users clearly lack. These groups should always be strictly enforced to maintain the integrity of the group. Examples are: Departmental groups, location groups, and role groups like SQL DBA, or security admin, etc. Users that are clearly not members of these organizational structures should not be placed in these groups. Users are typically grouped in this manner. However, administrators make two common mistakes implementing these types of groups.

The biggest mistake administrators make in implementing these types of groups is using these groups to apply permissions directly to one or more individual objects, folders, etc. This action makes support and access of these resources more difficult to administer over time.

The second mistake is not adhering to a strict policy of keeping these groups made of members that clearly meet the defined organizational (departments, locations, etc) and role requirements (DBA, security admin, etc). When administrators place users into these groups because it is convenient they tend to unknowingly give access to other resources. This can lead to unauthorized access and other issues.

Properties of a User Group Security Model

1. Users are assigned directly to groups that are then directly assigned to resources
2. More than one group per access type (Read and Write, Read Only, Full Control, etc) is assigned to resources

Below is a very common example of a user group security model that you will find at many companies. Notice how a single group is directly assigned permissions to various folders. This is type of implementation is not recommended because it is more difficult to support.

example of a user group security model

For example assume an existing user, James is already in the “IT Users” group but now needs Read and Write (RW) access to Folder1 but no access to Folder2. In this scenario, there is no choice but to create a new group and assign that group to the Folder1 with RW access, then place James into the newly created group. You could assign James directly to Folder1 but that is a violation of previous rules. You could add James to HR Users but that would grant James access to Folder2 as well as other permissions not shown in the picture. All of these workarounds and can be avoided and simplified administration can be achieved by gaining an understanding of the next rule.

Rule 5: Always assign permissions in a Resource Security Model

The Resource Security Model is a multiple tier security model that is both flexible and easy to administer. The general types of objects used in a Resource Security Model are: Users objects, Organizational Groups (grouped by departments, locations, regions, etc), Role Groups (DBA, Security Admin, Helpdesk, etc), and Resource Groups.

Because of its flexibility the basic implementation of a Resource Security Model can be either two tier, three tier, or four tier. More tiers are normally implemented within the Organizational Groups because they easily lend themselves to group nesting. But for the purpose of this discussion the Organizational Groups are considered a single tier. All forms of this model can be used in a single environment allowing the greatest flexibility and ease of implementation.

Below is a diagram showing how these objects related to each other to create the Resource Security Model.

objects relations in a Resource Security Model

Descriptions of the different types of a Resource Security Model
* Two tier model: Resource groups are used to secure the object per access type, users are then placed directly into the Resource group.
* Three tier model:
– Type A: Resource groups are used to secure the object per access type, Role based groups are used to create a role with specific permissions via placement into different Resource groups. Users are place directly into each Role group.
– Type B: Resource groups are used to secure the object per access type, Organizational groups are then placed into the appropriate Resource group as appropriate for that department, location, etc. The users that are members of the Organizational group are automatically given access to the specified resources.
* Four tier model: Resource groups are used to secure the object per access type. Role based groups are used to create a role with specific permissions via placement into different Resource groups. Organizational groups are then placed into the appropriate Resource group as appropriate for that department, location, etc. The users that are members of the Organizational group are automatically given access to the specified resources.

In general using the Resource Security Model will result in the most flexible and easy to administrate security model your company can implement.

Properties of a Resource Security Model

1) Only one group per access type is assigned to the resources.
a. For example separate resource groups are created to secure a folder with Read Only (RO) and Read Write (RW) permissions.
b. Example names:
i. Foldername.RO
ii. Foldername.RW

2) Role Groups are used to place users into multiple Resource groups to create a specific “role” allowing multiple permissions to be given out with a single group if needed.

3) Organizational Groups are used to group users based on the organizational requirements of the company. These are an important requirement to help grant access quickly to users based on any of the following common organizational needed.
a. Department
b. Unit (a subset of a department)
i. For example Accounting may payroll, and accounts payable as a Unit of the Accounting Department.
c. Location
d. Region (a collection of locations)
e. Department by Location
f. Unit by Location
g. Department by Region
h. Unit by Region

If we go back to the previous permissions example given for James in Rule 4 and instead implement a Resource Security Model the solution would look like this:

example of a Resource Security Model

At the very beginning of this article I warned readers that the Golden Rules of Permissions Administration was a proactive approach that had a small cost, more initial setup and implementation time. That cost ultimately saves a lot more administration time post implementation because most changes are just a matter of adding users to groups versus redesigning and re-implementing security post implementation.

Summary

In most companies implementing the Golden Rules of Permission Administration and ultimately a Resource Security Model is not something that is done over night. It will take years of continual effort to replace the old security model with the new proper implementation. However, it can be done. All that is required is a single administrator that continually follows these rules when implementing new security, replaces the old security as needed, and makes the effort every day to follow these rules. Eventually, other administrators will also learn this method and your environment will become easier to administer.

I have personally setup and implemented this very model at several different companies with great success.

Definitions

The Long Run: This is a long term view of how a company or the technology that a company uses may change over time. For instance, acquisitions and divestitures, departmental restructuring, technology upgrades, technology abandonment, and new technology implementations. All of these things professional administrators encounter year after year, and administrators that follow the Golden Rules of Permissions Administration will make each one of these a less painful experience.

Simplify Administration: is easily talked about but rarely properly verbalized. As far as it applies to the Golden Rules of Permission Administration it is a practice of using a flexible Resource Security Model and a centralized administration console to assign permissions to all applications in the enterprise using methods that increase the efficiency of post implementation administration. Another key feature that a simplified administration model uses is a view that the ease of post implementation administration is more important than initial implementation time.

The last feature that is important to simplifying administration is the ability to have a highly trained engineer setup the initial security configuration and then have lower level administrators place the users into the groups as the need arises over time. This adds to the simplicity of administration by having a centralized administration console (like Active Directory) to provide permissions administration for all applications in the enterprise.

User Group: is a group created with members based on the idea that the users have something in common other than a resource to which they are being given access to. Typically theses groups can have names like “HR Department”, “Accounting Department”, “Managers”, “Domain Users”, “Domain Admins”, etc. It is important to note that these groups tend to fall into one of two types: Organizational Group or Role Group.

Organizational Group: is a group created with members based purely on the organizational structure of the company. These are usually considered a foundational level group for granting access to resources within the company. Users must be a member of the respective departments to be a member of these groups.

Role Group: is a group created to facilitate special types of access that may cross organizational boundaries. This type of group is very beneficial in allowing users from different department’s access to multiple resources quickly and easily.

Resource Group: is a group created specifically for a single resource and a specific access type. For example, granting access to a specific folder with Read/Write access.

Source: Permissions Rules