TABLE OF CONTENTS
SECTION 1: BEST PRACTICES FOR SYSADMINS .............................................................................................................. 1
Best Practices Recommendations ............................................................................................................................. 1
Permissions ........................................................................................................................................................... 1
Security ................................................................................................................................................................. 2
Miscellaneous ....................................................................................................................................................... 3
SharePoint ............................................................................................................................................................. 4
SECTION 2: BEST PRACTICES FOR USERS ....................................................................................................................... 6
Do’s ........................................................................................................................................................................... 6
Don’ts ........................................................................................................................................................................ 6
SECTION 3: HOWTO ....................................................................................................................................................... 7
Roles vs. Groups ........................................................................................................................................................ 7
Inheritance ................................................................................................................................................................ 7
Understand Rights and Permissions .......................................................................................................................... 8
Basic Folder Permissions ....................................................................................................................................... 8
Basic File Permissions ........................................................................................................................................... 8
Special Permissions ............................................................................................................................................. 10
Check Effective Rights ............................................................................................................................................. 10
Folder structure for your Faculty or Department ................................................................................................... 13
Example of a Folder Structure ............................................................................................................................ 13
ICS: General Rules of Thumb ............................................................................................................................... 13
Keep security simple and understandable, or else: ................................................................................................ 15
Bibliography ................................................................................................................................................................. 16
August 22, 2012 Version 2 1
SECTION 1: BEST PRACTICES FOR SYSADMINS
BEST PRACTICES RECOMMENDATIONS
A Best Practices list has been generated by using information gathered from various sources including Microsoft
and Gartner. This list is by no means complete. McGill provides access to many excellent e-books explaining
Microsoft Windows permissions, best practices, security, etc.
PERMISSIONS
1. Assign permissions to groups rather than to users.
Assigning permissions to groups simplifies management of shared resources, because you can then add
users to or remove them from the groups without having to reassign permissions.
You should not add permissions to each user one by one. If someone leaves or joins the group then you
would have to modify the permissions for every single file: this operation is time-consuming and error-
prone. Adding someone to a group is a straightforward operation.
2. Use roles rather than assigning rights to a user.
Roles are another means of abstraction for classifying subjects based on their intended function. For
example, all users in the role of “sales manager” could be granted different levels of access than users in
the role of “sales clerk.” As a user's job responsibility changes, his or her role assignment will change, and
as a result, the user's permissions will also change.
Refer to Section 3 for more information regarding Roles.
3. Assign permissions to an object as high on the tree as possible and then apply inheritance to propagate
the security settings through the tree.
When a file or sub-folder is created in an existing folder (referred to as the parent folder) it inherits, by
default, all of the permissions of the parent folder. Similarly, when the permissions on a parent folder are
changed, those changes are automatically inherited by all child files and folders contained within that
parent folder.
See Section 3 for more information regarding Inheritance.
4. Avoid using Deny permissions except in the following cases: a. Use Deny permissions to exclude a subset of a group which has Allowed permissions. b. Use Deny to exclude one special permission when you have already granted full control to a user
or group.
It is usually necessary to explicitly deny permissions only when you want to override specific permissions
that are already assigned. Although Deny beats Allow, an explicit Allow overrides an inherited Deny.
August 22, 2012 Version 2 2
5. Remember permissions are cumulative.
Rights to a folder + rights as a member of group1 + rights as a member of group 2 = this user’s
permissions.
6. Understand NTFS vs. share permissions.
The biggest point of confusion about sharing with Windows systems is that the NTFS and share-level
permissions both have an effect on the user's ability to access resources on a network. This is especially
important to remember for Windows desktop and Windows Server, which have default share permissions
as read-only. This makes the NTFS permissions limited to read when accessing them over the network..
The best way to distinguish share permissions from NTFS permissions is to consider share permissions as
an entry point to the resources. Only after the share permissions offer Change and/or Full Control can the
NTFS permissions of that type be used.
The combination of share-level and NTFS permissions can seem like administrative overhead, but consider
this: Share permissions act as a point of entry for the NTFS permissions over the network. When you enter
a network resource through a share, the share permissions dictate what you can do through the share as
a whole. The NTFS permissions dictate what you can do to specific files and folders. In the troubleshooting
mode, identify whether share-level permissions can be ruled out of the issue.
SECURITY
7. Keep security simple and understandable.
Avoid overly long path names.
8. Never over-privilege. Never assign full control – A person can then change their rights.
Grant the most restrictive permissions that still allow users to perform required tasks. For example, if
users need only to read information in a folder, and they will never delete, create, or change files, assign
the Read permission.
The worst thing you can do to solve a rights problem is to make someone a member of Administrators or
some other powerful group to circumvent a permissions issue. Simply giving more rights to a user does
not address the issue. Always identify the issue to determine the best solution.
See Section 3 for more information regarding Permissions.
9. If giving rights, have the user logout and log back in.
Each time a user logs on; Windows creates an access token. The access token is a representation of the
user account and contains elements including User Rights. An access token is not updated until the next
logon, which means that if you add a user to a group, the user must log off and log on before the access
token is updated.
August 22, 2012 Version 2 3
10. After making changes always verify Effective rights.
It can be difficult to determine how permissions may accumulate to affect a particular user or group for
any given file or folder. In order to make this task a little easier, Windows provides a feature known as
Effective Permissions which will list the cumulative permissions for a user or group. On the Effective
Permissions tab of the Advanced Security Settings for a file or folder you can select a user or group and
see the effective permissions. These are the results of the permissions directly assigned to the file or
folder and permission inherited from parent folders.
See Section 3 for more information regarding Effective Rights.
11. Related to the previous point, perform periodic reviews of permissions.
This should be used when staff change roles in a department, leave the department or leave McGill.
12. Do not enable administrative privileges until needed.
Don’t log into a computer with administrative rights unless you must do so to perform specific tasks. Use
“Run as Administrator” instead to perform administrator functions.
13. Install a Personal Firewall on your workstation.
A firewall protects shared resources from access through the Internet.
MISCELLANEOUS
14. Use intuitive, short labels for shared resources.
Avoid overly long path names and special characters (@,/,\,:), many of which are not allowed in folder
and file names.
Groups and computer names must be prefaced with a unit’s ORG code e.g. 526-ICS. This is a PIA (Planning
and Institutional Affairs) naming convention (http://www.mcgill.ca/pia/unit) chosen for its uniqueness.
15. Create a folder structure based on the needs of the Department/Faculty.
Organize resources so that objects with the same security requirements are located in the same folder.
Refer to Section 3 for one example of a possible Folder Structure.
16. Know when to copy and when to move.
Be careful moving files around. Standard copy and move operations deliver different results that can
maintain your configured permissions--or break them. A good way to remember this is that copy
operations will create the permissions of the destination container, and move operations will maintain
that of the parent container. If you move, a file keeps its rights. If you copy, it inherits the rights of the
new location. It is a good practice to use COPY; it verifies that source/destination hold the same number
of folders and files.
Memorization mechanism: CC/MM -- CopiesCreate/MovesMaintain.
August 22, 2012 Version 2 4
17. When you share applications, organize all shared applications in one folder.
Organizing all applications in one shared folder simplifies administration, because there is only one
location for installing and upgrading software. For example, if users require the Read permission for
several application folders, store the application folders in the same parent folder. Then, share the parent
folder, rather than sharing each individual application folder. Note that if you need to change the location
of an application, you may need to reinstall it.
18. Cleanup.
When a user leaves the department, don't leave their files and folders on the server indefinitely. Move
files that belong elsewhere or with a replacement employee, and delete the others [assuming the
employee was informed to clean up before they left).
19. Any action not following recommended guidelines should be documented with answers to the
following questions:
Who is taking the action? What is the action? Why is this action taking place?
SHAREPOINT
Many of the Best Practices listed above are relevant to SharePoint as well. Here are a few of them.
20. Permission levels should always be assigned to groups of one or more users rather than to individual
users.
Make sure you know “who has access to what.”
21. Do not interrupt the Inheritance Model.
By default, a permission level granted to a group at the Web Application or Site parent level is passed to
child objects in the hierarchy. Permissions can be modified at the child levels, but doing so interrupts or
breaks the inheritance model, in that inheritance no longer works with child objects beneath the parent
where inheritance is interrupted
Departure from default, hierarchical permissions should be carefully documented; optionally, new groups
and associated permission levels should be established to avoid introducing exceptions and the potential
side effects of changing permissions and breaking inheritance, such as introducing inappropriate write
capabilities to items in a list.
If unique permissions are required, it may be more effective to design a special permission level and
assign it to a particular group. Defaults are boring but effective: SharePoint comes with design templates
that serve particular applications. Whenever an organization has special needs, it may be of benefit to
start from an existing template and document the necessary alterations. Consistent application of
templates and terminology will help to improve understanding of applications
August 22, 2012 Version 2 5
22. Document all.
Understand your risks —plan, document, and enforce: As the sensitivity of information published in
SharePoint rises, so does the need to document and manage its purpose and use. This applies to identity
as well as organizational information assets.
August 22, 2012 Version 2 6
SECTION 2: BEST PRACTICES FOR USERS
Your home directory has been set up to ensure safe keeping of your folders and files. The following are a few Do's
and Don'ts for your files and folders.
DO’S
1. Do ask questions.
Never be embarrassed to ask if you are not sure about your home directory folder, other folder structures
and your files.
2. Do choose meaningful file and folder names.
A file named Report is not as helpful as 03-2012 Security Report Draft 6.
3. Do know when to copy and when to move.
Be careful moving files around. Standard copy and move operations deliver default results that can
maintain your configured permissions--or break them. A good way to remember this is that copy
operations will create the permissions of the destination container, and move operations will maintain
that of the parent container. If you move, a file keeps its rights. If you copy, it inherits the rights of the
new location.
Memorization mechanism: CC/MM -- CopiesCreate/MovesMaintain.
4. Do be very careful when sharing private/sensitive data.
Do not move or copy private data from its original location unless asked to do so by your supervisor. Once
it is moved/copied ensure it is visible only to those authorized to see it.
5. Do remove sharing private/sensitive data securely.
Remove files or data you no longer need to prevent unauthorized access to them.
DON’TS
6. Don't keep files and folders no longer used.
Folders and files no longer used and obsolete should be deleted.
7. Don’t save files locally on your desktop machine or on external drives or media.
Never save data on your desktop machine. Data on the network is backed up regularly and can be
restored if you accidently delete it. Additionally data on the network is better protected than data on your
local machine.
8. Don’t store confidential or sensitive data on removable media (CD, DVD, and USB Stick).
9. Don’t install applications onto the network.
August 22, 2012 Version 2 7
SECTION 3: HOWTO
ROLES VS. GROUPS
Groups and roles represent collections of users who perform similar tasks, or have a similar status in an
organization.
Examples of groups are Employees, Developers, or Sales Personnel. Members of groups can be users and other
groups. Group membership is part of a user basic identity. Users always log on with all the permissions associated
with the groups to which they belong. Roles differ from groups in several ways. Members of roles can be
users, groups, and other roles. Role membership is not part of the user basic identity.
A role is a collection of permissions that can be applied to either a user or to a group. Roles are usually associated
with capabilities whereas groups with access to folders, packages etc.
Role-based access control takes the privileges associated with each role in the company and maps them directly
into the systems used for accessing IT resources. Implemented properly, it enables users to carry out activities -
and only those activities - allowed by their role.
INHERITANCE
To turn off inheritance for a child file or folder, right click the object in Windows Explorer, select Properties and
then click on the Security tab of the properties dialog. On the Security properties panel, click on the Advanced
button to display the Advanced Security Settings dialog followed by Edit... to display the editable permission
settings. In this dialog, unselect the check box next to Include inheritable permissions from parent object. Once
selected, a warning dialog will appear providing the choice to retain the current inherited permissions, or to
remove any inherited permissions keeping only permissions which have been explicitly set on the selected object:
Consider starting a new folder share as high in the path as possible rather than breaking inheritance.
August 22, 2012 Version 2 8
UNDERSTAND RIGHTS AND PERMISSIONS
The basic permission settings available differ slightly between files and folders. The following table lists the basic
folder permissions.
BASIC FOLDER PERMISSIONS
Permission Description
Full Control Permission to read, write, change and delete files and sub-folders.
Modify Permission to read and write to files in the folder, and to delete current folder.
List Folder Contents Permission to obtain listing of files and folders and to execute files.
Read and Execute Permission to list files and folders and to execute files.
Write Permission to create new files and folders within selected folder.
Read Permission to list files and folders.
BASIC FILE PERMISSIONS
Permission Description
Full Control Permission to read, write, change and delete the file.
Modify Permission to read and write to and delete the file.
Read and Execute Permission to view file contents and execute file.
Write Permission to write to the file.
Read Permission to view the files contents.
To change the basic permission on a file or folder access the security panel of the properties dialog and click Edit to
display an editable version of the current settings. To change permissions for users or groups already configured,
simply select the desired user or group from the list and change the settings in the permissions list as required
(keeping in mind that any grayed out permissions are inherited from the parent folder). Click Apply to commit the
changes.
To configure permissions for users or groups not already listed, click on the Edit... button on the security properties
panel and click on Add.... Enter the names of users or groups separated by semi-colons (;) in the Select Users or
Groups dialog box and then click on Check names to verify the names exist. Click on OK to confirm the user or
group and return to the editing dialog. With the new user or group selected, configure the desired permissions and
then Apply the settings when completed.
August 22, 2012 Version 2 9
File Permissions Override Folder Permissions.
For example, if user David has been allowed Read permissions for the folder and Modify permission for a file
work.doc, his effective permissions for the work.doc file is Modify. The exception to this rule is the permission Full
Control. Folders, Groups or users that have Full Control for a folder can delete files and subfolders in it regardless
of the permissions set on those files and subfolders.
Special File and Folder Permissions
Basic file and folder permissions are really just pre-packaged collections of special permissions. Special permissions
provide a much more fine grained approach to defining permissions on files and folders than is offered by basic
permissions. The current special permissions configured on a file or folder can be viewed and modified by right
clicking on the object in Windows Explorer, selecting Properties, clicking on the Security tab of the properties
dialog and pressing the Advanced button. This will display the Permissions page of the Advanced Security Settings
dialog which contains a list of users and groups for which permissions have been defined. Click on Edit to access
the editable view of the permissions. Select a user or group from the list and click on the Edit... once again to
display the Permission Entry for the selected user or group for this file or folder. This dialog will appear as
illustrated in the following figure:
To change the special permissions simply make the appropriate selections in the list (keeping in mind that any
August 22, 2012 Version 2 10
grayed out permissions are inherited). To add special permissions for a user or group not currently listed in the
Advanced Security Settings page, click on the Add... button and use the Select Users and Groups dialog to add new
users or groups to the permission entries list.
Windows Server 2008 (or to be more exact, NTFS) provides 14 special permission options, each of which may be
allowed or denied. The following table lists each of these settings and describes the option in more detail.
SPECIAL PERMISSIONS
Permission Description
Traverse folder / execute file Allows access to folder regardless of whether access is provided to data in folder. Allows execution of a file.
List folder / read data Traverse folder option provides permission to view file and folder names. Read data allows contents of files to be viewed.
Read attributes Allows read-only access to the basic attributes of a file or folder.
Read extended attributes Allows read-only access to extended attributes of a file.
Create files / write data Create files option allows the creation or placement (via move or copy) of files in a folder. Write data allows data in a file to be overwritten (does not permit appending of data).
Create folders / append data Create folders option allows creation of sub-folders in current folder. Append data allows data to be appended to an existing file (file may not be overwritten)
Write attributes Allows the basic attributes of a file or folder to be changed.
Write extended attributes Allows extended attributes of a file to be changed.
Delete subfolders and files Provides permission to delete any files or sub-folders contained in a folder.
Delete Allows a file or folder to be deleted. When deleting a folder, the user or group must have permission to delete any sub-folders or files contained therein.
Read permissions Provides read access to both basic and special permissions of files and folders.
Change permissions Allows basic and special permissions of a file or folder to be changed.
Take ownership Allows user to take ownership of a file or folder.
CHECK EFFECTIVE RIGHTS
To access this feature, right click on the required file or folder in Windows Explorer, select Properties and then
select the Security tab in the resulting properties dialog. Within the security panel, click on Advanced and select
the Effective Permissions tab in the Advanced Security Settings dialog. The next step is to specify the user or group
for which the effective permissions are to be calculated. To achieve this, click on the Select button and use the
Select User or Group dialog to specify or search for a particular user or group and then click on OK. The effective
permissions for the chosen user or group will subsequently be displayed, as illustrated below:
August 22, 2012 Version 2 11
There are two caveats when assessing a user's Effective Rights:
First, the Effective Permissions tool only tells you what the effective permissions are -- not where those
permissions come from. Therefore, if you end up having an unexpected set of effective permissions, you'll usually
end up having to find out what groups the user belongs to and evaluate the permissions on each individual group
to find out why the user has that permission set.
The other frustrating aspect of the Effective Permissions tool is that there are a lot of factors it doesn't take into
account. The tool only looks at the NTFS permissions that are assigned to users and groups, and then makes an
evaluation by combining any applicable permissions. There are some situations, however, in which the way a user
logs in makes a difference in how the permissions are applied.
For example, if a user is accessing an object remotely, then any local group memberships or other local privileges
are completely ignored. Since the Effective Permissions tool doesn't know how a user will be logging in, it may
report a different set of effective permissions than what might actually be applied in the real world.
On top of this, there are a number of well known SIDs that are not taken into account when the NTFS permissions
are evaluated. The most well-known of these include:
• Anonymous Logon • Batch, Creator Group • Dialup
August 22, 2012 Version 2 12
• Enterprise Domain Controllers • Interactive • Network • Proxy • Restricted • Remote • Service • System • Terminal Server User • Other Organization • This Organization
Unfortunately, there is no getting around the inaccuracies that are built into the Effective Permissions, however,
just knowing about the inaccuracies makes troubleshooting NTFS permission problems a whole lot easier.
August 22, 2012 Version 2 13
FOLDER STRUCTURE FOR YOUR FACULTY OR DEPARTMENT
EXAMPLE OF A FOLDER STRUCTURE
One possible structure recommended by ICS (depending on your specific requirements) is to create 3 subfolders
under a unit’s departmental share folder (deptshare) to keep the structure (and rights management) simple and
effective. These folders are named APPS, SHARE and USER. In some departments where a folder structure was
already in place there are subfolders named PGMS, GROUPS and USERS (or equivalent).
DEPTSHARE\APPS\<appname>
DEPTSHARE\SHARE\<sharename>
DEPTSHARE\SHARE\EVERYONE (or equivalent e.g. COMMON) as a general “all user” share
DEPTSHARE\USER\<DASNAME> (dasname to simplify scripting and ensure uniqueness)
The drive letter G: is mapped at the deptshare level so one can traverse down to the 3 basic subfolders mentioned
above. The drive letter F: is mapped to a user’s home folder and one common drive letter to the “Everyone” share.
Standardizing drive letters within a unit is helpful to users and administrators. Other drive mappings are upon
request or to further map common letters to a specific share for a unit or sub-unit.
This makes one’s user F: drive look similar to one’s R: drive as it also uses DASNAME. However, they differ in that
the F: drive is for the employee’s position whereas the R: drive is one’s personal 1 GB folder that will follow them
around McGill. The F: drive remains property of the unit and typically one’s positional replacement will inherit the
contents when the employee leaves.
They try to make the SHARE folders as basic as possible for rights with either a Read/Write group and/or a Read
Only group at the top SHARE level and they allow the rights to flow down. They try to avoid Deny rights and
broken inheritance by suggesting a new SHARE be created instead of making changes deeper into the folder path,
although sometimes this is unavoidable. This keeps the management simple for them and the navigation simple
for their clients. Rights reviews are also easier to accomplish.
ICS: GENERAL RULES OF THUMB
CREATOR/OWNER
“We remove this default NTFS permission set from the root of a deptshare. This adds Creator/Owner everywhere
and adds the actual creator with EXPLICIT FULL permissions “this folder only.” If you don’t check and remove the
creator from an AD group you are using to secure a folder you may be surprised that they still have access due to
this effect. Also, because it is FULL control granted, a user can take ownership and change permissions at will.
With Creator/Owner removed you remove rights clutter and can be assured of rights control by AD groups only.
Users can no longer take ownership but if they are still the true owner of a folder, can change permissions.
DELETE VS DELETE SUBFOLDERS AND FILES
August 22, 2012 Version 2 14
Never give FULL control to a folder. We often see a group giving “read/execute” access and/or a group for
“modify” access. However, the “modify” permission set grants the “delete” right as well. We try to go one step
further in our default setup for a read/write group by removing the “delete” right and replacing it with the “delete
subfolders and files” right (delete child). This emulates the Novell DI (delete inhibit) function and is used at the
SHARE\<sharename> level. In case of an accidental Move or Delete, this will preserve the SHARE folder and its
permissions. One can then restore or copy back (if found) the folder contents and not have to figure out the
groups and permissions again.
TRAVERSE FOLDER RIGHTS
We setup (or try to) one Traverse group for each folder level and nest these groups in the Traverse group above it
to ensure smooth traversing through a folder structure without rights clutter or explicit rights being used. This is
handy for accessing deptshares other than one’s own from a common top level drive map, without having to map
more drive letters to explicit folder paths for users in logon scripts. This also resolves some recently discovered
Windows 7 issues with applications in share folders that WinXP had no issues with. Furthermore, we use the
‘correct’ rights set for this to work in McGill’s environment. ….
THIS FOLDER ONLY:
Traverse folder/Execute file (allow) List Folder/Read Data (allow) Read Attributes (allow) Read Extended Attributes (allow) Read Permissions (allow)”
This is courtesy of IT Customer Services (ICS).
August 22, 2012 Version 2 16
BIBLIOGRAPHY
How to Implement Role-based Access Control. (2007, October). Retrieved July 2012, from ComputerWeekly:
http://www.computerweekly.com/news/2240083532/How-to-implement-role-based-access-control
Understanding Windows Server 2008 File and Folder Ownership and Permissions. (2011, April). Retrieved July 2012,
from Techotopia:
http://www.techotopia.com/index.php/Understanding_Windows_Server_2008_File_and_Folder_Owners
hip_and_Permissions
Best Practices for Securing your Computer, Accounts, and Data. (2012, July). Retrieved from Indiana University:
University IT Services : http://uits.iu.edu/page/akln
Finn, A. (2005). Securing Active Directory Using a Roles-Based Approach. Retrieved July 2012, from 2000 Trainers:
http://www.2000trainers.com/security/active-directory-security-roles/
Gebel, G., & Neuenschwander, M. (2007, March). User Authorization. Retrieved July 2012, from Gartner:
http://my.gartner.com/portal/server.pt?open=512&objID=256&mode=2&PageID=2350940&docCode=20
3272&ref=docDisplay
Hiemstra, J. (n.d.). Shared Folder and NTFS Permissions. Retrieved July 2012, from TechExams.net:
http://www.techexams.net/technotes/70290/permissions.shtml
Kampman, K. (2011, May). Identity in SharePoint 2010. Retrieved from Gartner:
http://my.gartner.com/portal/server.pt?open=512&objID=256&mode=2&PageID=2350940&resId=16886
22&ref=QuickSearch&sthkw=Identity+in+SharePoint+2010
Lenski, B. (2009). Follow Best Practice for Windows File/Folder Security Management. CERN Computer Newsletter,
1.
Microsoft. (2005). Best Practices for Permissions and User Rights. Retrieved July 2012, from Technet Microsoft:
http://technet.microsoft.com/en-us/library/cc779601(v=WS.10).aspx
Microsoft. (2005, January). Windows Server: Best practices for Shared Folders. Retrieved July 2012, from Microsoft
Technet: http://technet.microsoft.com/en-us/library/cc780313(v=ws.10).aspx
Microsoft. (2012, July). Best Practices for Securing Files with NTFS Permissions (IIS 6.0). Retrieved July 2012, from
Microsoft: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/f26e91fb-
ecbf-4632-8c2f-bd17cce6b874.mspx?mfr=true
Posey, B. M. (2009). Quick tips for troubleshooting NTFS permissions. Retrieved from SearchWindowsServer:
http://searchwindowsserver.techtarget.com/tip/Quick-tips-for-troubleshooting-NTFS-permissions
Vanover, R. (2006). 10 Things You Should Know About Working With NTFS Permissions. Retrieved July 2012, from
TechRepublic: http://www.techrepublic.com/article/10-things-you-should-know-about-working-with-
ntfs-permissions/6059618
Various University Web Sites. (n.d.).
Top Related