Author: NetworkAdminKB.com
Created: 2007-11-18
Modified: 2010-02-05
In my previous article The Golden Rules of Permissions Administration I covered the general rules for applying permissions to file structures and applications like Active Directory, SQL server, Sharepoint server, etc. In this article I will be talking about axioms for making permissions administration easier.
An axiom may be defined as a universally accepted truth that requires no proof. In this article I will demonstrate why these axioms are truly the best philosophy to follow when creating and administrating a file structure. I will use the file structure as an example throughout this article as it is the most widely understood permissions based system available. However, these axioms can apply to almost every application that has its own permissions. These axioms are also meant to be used in conjunction with The Golden Rules of Permissions Administration. They both work together to define a complete permissions administration philosophy.
As I have discovered over the 15+ years that I have been doing administration most administrators come from a background where they are taught simple rules (often conveyed as best practices) to applying permissions. Because these administrators are taught only rules without a cohesive and sound administration philosophy they can create more issues for themselves. What these administrators should be taught is that best practices are the foundation of any good implementation. However, as the administrator it is their job to create and implement a consistent administration philosophy to be followed in their organization.
The Axioms of Permissions Administration can be thought of as an administration philosophy that is built on a collection of best practices that build upon each other. Therefore, most axioms require the previous axioms be implemented as well. A few axioms are stand alone and work on their own. However, it should be noted that to make the whole system work correctly each axiom should be followed. Doing so will greatly simplify your administration.
The Axioms of Permissions Administration
1) Create a group to implement the File Structure Administrators Role
2) All File Structure Administrators need to understand Data Classification
3) Do not create new Shares for all new requests
a. Instead create general shares that can be used for the same general purpose.
4) Never assign Users Full Control to any folder to which a File Structure Administrator created.
a. Instead only allow File Structure Administrators Full Control to a file structure.
5) Never remove File Structure Administrators from any Share created.
6) File Structure Administrators control the directory structure where permissions are required.
7) Apply Read Write and/or Read Only permissions for Users to “leaf” folders
8) Apply Read Only permissions for Users to the directory structure leading up to the “leaf” folders.
9) On folders (leaf or non-leaf) where unique permissions are set, do not inherit permissions from parent folder.
a. Instead copy the permissions, keeping those that should flow throughout the directory structure (i.e. File Structure Administrators Full Control), remove those permissions that should stop, and apply new permissions for users that should have access.
10) Never remove the SYSTEM permissions from the file structure
11) Always assign the Local Administrators Group Full Control
Axiom 1: Create a group to implement the File Structure Administrators Role
On the surface, every IT department understands the concept of a File Structure Administrator, but they fail to properly identify and quantify that role within the IT organization. A common mistake that many administrators make is thinking that Domain Admins or the local Administrators group are the file structure administrators in the company. An example of this flawed thinking is when administrators ONLY add one or both of these groups to the Share or NTFS permissions with Full Control on every share or folder they create. This flawed practice is indicative of the lack of a clearly defined File Structure Administrators group.
While Domain Admins or the local Administrators groups commonly have employees that require the Full Control permission to all shares, they are not the only IT personnel in the company that may have this requirement. Other examples may be helpdesk, or desktop support personnel, etc.
Given the nature of the file structure and its purpose at a company, every IT department should understand the need to have a clearly defined File Structure Administrators Role that contains the IT personnel that will be required to implement and administer all file structures for its company. It is this group of people that need to be trained in the methods and practices being described here. Please read The Golden Rules of Permissions Administration for more information about how to create a Role group.
Axiom 2: All File Structure Administrators need to understand Data Classification
A basic underlying principal that any file structure attempts to solve is data classification. However, most administrators are not properly taught this and are unable to conceptualize the issues relating to data classification and a file structure. Data classification as it pertains to a file structure is not overly complex but is meant to solve the following issues.
1) Organize the data
a. This is best done by senior people that have a good understanding of the way the business works. Usually data on a file server is organized into Personal Folders, Departmental Folders, Public Folders, and Applications.
b. Do not overly complicate things by trying to organizing your file structure beyond how the company is structured. The foundation of your directory structure should be based on your company’s organization.. Using the company structure as the foundation to the Personal, Departmental and Public folders will always provide a solid solution of easy to manage data.
c. Specific Secured folders should be setup in each Department’s folder and a common Secured folder should be provided in the Public folders. This will simplify securing important documents, while maintaining data classification.
2) Classify the data
a. This is usually done by determining who owns the data, who will require access, and what access is required.
b. The classification of data typically falls into several basic types: Departmental Data, Shared Data (sometimes called Public), User Data (home folders), and Application Data (exes, database files, dll, and all other Application specific files).
c. Examples:
i. If all department users need access to the same files, then the files go in a department share, without any special security (other than what the department folder already provides)
ii. If non-sensitive data needs to be shared between users in various departments, then the files go on the Public share where everyone can access and modify it if necessary.
3) Secure the data
a. This is the amount of security that needs to be applied to the data.
b. Example: Common data place on a public share need not be secured, while important payroll information should be placed in the payroll department’s Secure folder and have security limiting access to just those members of payroll that require access. If users outside of payroll need access then the data should be moved to the public Secured folder and appropriately secured for the specific users.
All three of these values work together to determine the proper placement of data and the proper security the data should receive. Data classification within an organization is a crucial element of the any administration philosophy and should not be neglected, but need not be overly complex either.
Axiom 3: Do not create new Shares for all new requests
A common mistake that administrators make is creating new shares for every new request. This causes a proliferation in the number of shares on a server, and the drive mappings or UNC paths that a user requires to gain access to them. It is considered a Best Practice to create general shares that are designed for a specific classification of data, and then create a folder structure that organizes that data so new requests can be accommodated easily. In general you only need the following basic Shares on each file server to share all types of data. As the classification of data changes from personal, to department, to public, etc its location should change.
- Home (Personal) folder share
- This holds the user home folder and their personal documents
- Department share
- Information is shared between department members only.
- Public share
- Information is shared between all users or users from multiple departments
- Application share
- Each application receives its own folder and security.
Below is an example of a poorly organized file server.
A better solution may look like this
This solution organizes the data in to appropriate data classification of Applications, Departments by location first, Public Data, and User Home folders. A preferred method for the Department Share would be organize by department first then location, but given the limited information shown in the example this was easier to show.
Axiom 4: Grant File Structure Administrators Full Control to a file structure.
Now that we have defined the purpose of the File Structure Administrators group, it is important that we give this group the appropriate permissions on all the shares and file structures that they may administer. The objective here is to make sure the administrators maintain control of the file structures they implement. This means that on every share created the File Structure Administrators group is applied Full Control. Since this group of people should be the only people creating Shares it stands to reason they should want to maintain access for themselves so they can properly administrate permissions in the future.
Once we have the Share configured so that File Structure Administrators are given Full Control, we can use the NTFS permissions to extend that Full Control to the NTFS file structure. This is done by applying the role group NTFS Full Control permission as well. This is usually done through a Resource Group.
If you have not read my previous article The Golden Rules of Permissions Administration I suggest you read it so you can gain a better understanding of a Role and Resource Group. The important thing to understand in this situation is that the entire file structure is considered the resource for the File Structure Administrators group. Therefore, all the individual folders will have the exact same group applied to them with Full Control access. Furthermore, this requires only a single Resource Group for the entire file structure.
In a centralized administration model only one Resource Group for the File Structure Administrators will be needed for all file servers. In a decentralized model, separate Resource Groups will be needed for the various File Structure Administrator Groups. These Resource Groups can be created either on a per server basis, or for a group of file servers that a specific set of administrators may be responsible for.
Axiom 5: Limit Share permission to 3 groups and 3 permission types
Many administrators are easily confused by Share permissions and how they interact with NTFS permissions. The easiest way to deal with Share permissions is to think of them in terms of Maximum permissions, and then leverage NTFS permissions to restrict access down from that maximum.
As a Best Practice Share permissions should be used to simplify administration and prevent users from accidently receiving more permission’s then they should. This is accomplished by leveraging the Share to NTFS permission comparison of most restrictive applies by always setting the Share to the Maximum that any group of users can receive. Used in this manner Share permission’s become very useful for limiting mistakes by administrators.
The following is the recommended Best Practice for all Shares created. Any Share created only needs three basic permissions levels: Read Only, Read Write, and Full Control. Therefore, we only need three groups applied (one for each permission type) so that the users are properly placed into one of those three groups.
The Recommend Best Practice for Share Permissions
- Everyone: Read (Read Only)
- Authenticated Users: Change (Read Write)
- Sharename Group: Full Control
- Members: File Structure Admins
By using the Everyone group for Read Only permissions, this allows Guest users to attach the share and read its contents. (See Differences between Authenticated Users, Domain Users, and Everyone groups). In a properly data classified Share (Axiom 2), the share’s contents are normally just folders that are restricted via NTFS permissions, so any user that falls into the Everyone group should only have access to the folder structure leading up to where data is actually stored. This allows Guest users to see what folders they may need access to so they can request it via the proper procedure, while preventing these un-authorized Guest users from accessing any real data.
By using the Authenticated Users group for Change (Read and Write) we can greatly simplify administration of the Shares. Through this group 98% of all permissions will be granted. All normal users will automatically be limited to a maximum permission type of Read and Write. Furthermore, Full Control can not be easily granted by accident.
By creating a specific group to grant the Full Control permission on the Share we can make sure that only member of that group (by default File Structure Administrators should be added) are expressly given that permission. Users outside of this group will be considered Authenticated Users or Everyone and will be limited to those group’s permissions.
Axiom 6: File Structure Administrators control the directory structure where permissions are required.
It amazes me how often File Structure Administrators fail to understand that they control the file system. It’s their job, not the user’s job, to design and implement folder structures and corresponding security. This means taking a leadership position on any request and setting and following standards. It is not the job of a File Structure Administrator to implement the user request verbatim, rather gather the requirements of the request and tell the user how it will be implemented.
Remember as a File Structure Administrator it is your job to deal with the file structure on a daily basis and therefore you should make it easy for you to administer, while providing access to the data for the users. As such take personal pride in all requests and make your job easier. File Structure Administrators are not simply brainless robots doing everything that users request without thought of how to maintain it long term. Quite the opposite, their whole job revolves around thinking long term and how to best support everything they implement through migrations, upgrades, future requests, etc. as well as organizing and classifying all data put on the file servers. More time spent upfront planning the file structure implementation will result in less maintenance needed over time.
As a File Structure Administrator you should understand the following about all requests that are made
- A specific location of a file or folder is not a requirement for any user request. Users (not programs) can access files and folders in any location, they are not limited to a particular location. Requests to have files or folders in specific locations for specific reasons are superseded by the files and folders data classification and corresponding security. As a File Structure Administrator your job is to properly organize, classify, and secure the request as it relates to the whole company, not just the individual request.
- A request may indicate who has access, but how that access is granted is determined by the standards at your company. Group naming conventions and type of access (Read Only, Read Write, etc), are determined by the File Structure Administrators and company standards, not the users.
- Users should only receive one of two basic permissions, Read Only and Read Write. List Folder Contents is not needed in a proper file system structure.
- Read the remaining Axioms for specifics on how to permission new file structures made by request.
Because the File Structure Administrators control the directory structure anywhere permissions are required it is considered a Best Practice for users to only be allowed control over (i.e. Read Write access to) “leaf” folders in a directory structure. These folders are considered “leaf” folders because they represent the furthest edge of where unique permissions are set, all permissions past this point are simply inherited. This provides the best administrator friendly solutions for file structures, and simplifies administration of the file structure for the File Structure Administrators.
Axiom 7: Apply Read Write and/or Read Only permissions for users to “leaf” folders
Since it is a Best Practice to only allow users to place content in leaf folders, these folders are where a bulk of the permissions administration takes place. File Structure Administrators should secure the folder using either (or both) Read Only or Read Write as the permission and according to the practices outlined in my previous article The Golden Rules of Permissions Administration
Single permissions like List Folder Contents have little benefit and are generally not needed. List Folder Contents allows users to read the directory listing, but not read the file contents. In real life there is rarely a need for a user to do such a thing (an application may require this single permission, but rarely a user), rather this permission is given to overcome a poor file structure design or poor planning on the File Structure Administrators part. In either case there are ways to over come limitations of existing implementations.
For example, some administrators will use List Folder Contents as a way to provide users access to folders lower in the directory structure, by preventing these users from accessing files in the directory structure leading up to the desired folder. The proper way to overcome this issue is to re-evaluate the files data classification. Once this is done the correct course of active is to move the affected files (the files the user needs access to, not the files that would receive the List Folder Contents permission) into a folder based on their new data classification and then secure the folder by only allowing proper users access to the folder. Doing these things will move the data to a proper leaf folder again, and follows Axioms 2 and 6 from above.
Giving a user the single permission Write will allow them to create a file, not Read or Execute it. This type of implementation is called a drop folder and is a special case that is rarely needed. Overall Read Only and Read Write will cover 99.9% of access requests for files and folders.
Axiom 8: Apply Read Only permissions for users to the directory structure leading up to the “leaf” folders
Using Read Only as the basis for permissions to read a file structure simplifies administration. This also helps to limit the number of groups that need to be created to manage a file system to just two types (Read Only and Read Write). While List Folder Contents could be used for this purpose, the added administration is not worth the effort because it will increase the number of groups that need to be created to three, and limiting user access to List Folder Contents is rarely needed.
As discussed previously it is a Best Practice to only allow users to place content in a leaf folder. Thus, using Read Only instead of List Folder Contents provides no difference when browsing the folder structure leading up to a leaf folder. Because there is no difference in the effective permissions, and because we can simplify our administration by reducing the number of groups needed it is usually considered a Best Practice to use Read Only as the permission leading up to the leaf folder.
Because all folders leading up to the leaf folders do not contain any files it is possible to simplify administration even more by using very broad groups (Everyone or Authenticated Users) to provide access to this part of the directory structure. While other more restrictive groups could be used the benefit is minimal.
A side effect of implementing this rule is that common administrative ideas about limiting access need not be addressed. This frees the file structure administrator to provide very broad access for users without compromising security or creating administratively burdensome groups that need to be maintained. The reason for this is because from a security perspective being able to access a directory structure with no files is not a security concern at all, therefore there is not a need to create groups to limit access to this structure.
Axiom 9: On folders (leaf or non-leaf) where unique permissions are set, do not inherit permissions from parent folder
Many administrators struggle with the decision to Inherit or Not Inherit permissions from the parent folder. This ultimately leads to flaws in security because of the inconsistent manner that the security is applied to the directory structure. As a Best Practice a File Structure Administrator should copy the permissions, keeping those that show should flow throughout the directory structure (i.e. File Structure Administrators Full Control), remove those permissions that should stop, and apply new permissions for users that should have access.
This Axiom is best implemented in a Resource Security Model in which the leaf folders are each considered a Resource and have two basic permission groups created and assigned (Read Only and Read Write). Below is a screen shot showing and example of how the permissions can be applied before and after this rule is implemented.
Read my previous article The Golden Rules of Permissions Administration to further understand how to best implement a resource security model.
Axiom 10: Never remove the SYSTEM permissions from the file structure
The SYSTEM permission is how the Operating System accesses files when needed. This permission can be used during a system backup, file compression / decompression, virus scanning, and other common activities. Because of the potential for a negative impact on your file server it is considered a Best Practice to leave the SYSTEM account applied to all file structures and files with Full Control access.
Axiom 11: Always assign the Local Administrators Group Full Control
Because nothing in IT is perfect and ultimately bad things happen, you should always grant the local Administrators group Full Control over the file structure. If the server becomes disconnected from the domain, or data needs to be restored from tape, etc. then this permission will be a time saver. I can tell you from personal experience there are plenty of times when this permission will be the life saver you need it to be.
Summary
Implementing these Axioms will help reduce and simplify daily administration of file structure or other permission based structures. Axioms of Permissions Administration along with The Golden Rules of Permissions Administration provide a comprehensive administration and security philosophy that is designed to fit any size or type of business.
Definitions
Read Only: In NTFS this is more commonly called Read-Execute. It is a collection of three NTFS permissions; Read-Execute, Read, and List Folder Contents. For Share permissions this is simply the Read Permission.
Read Write: In NTFS this is more commonly called Modify. It is a collection of five NTFS permissions; Modify, Read-Execute, Read, List Folder Contents, and Write. For Share permissions this is simply the Change permission.