august 2012 version 2 - mcgill...

FOR SYSTEM ADMINISTRATORS AND USERS

August 2012 Version 2

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.


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.


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.

http://www.mcgill.ca/pia/unit


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


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.


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.


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.


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


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.


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

http://www.techotopia.com/index.php/Image:Windows_server_2008_special_permissions.jpg


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


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:


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

http://www.techotopia.com/index.php/Image:Windows_server_2008_effective_permissions.jpg


• 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.


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


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).


KEEP SECURITY SIMPLE AND UNDERSTANDABLE, OR ELSE:


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.).


Windows 2003 NTFS and Share Permissions. (n.d.). Retrieved July 2012, from MC MCSE Certification Resources:

http://www.mcmcse.com/microsoft/guides/ntfs_and_share_permissions.shtml

august 2012 version 2 - mcgill...

Documents