FOR SYSTEM ADMINISTRATORS AND USERS. August 2012 Version 2

Transcription

1 FOR SYSTEM ADMINISTRATORS AND USERS August 2012 Version 2

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 Check Effective Rights Folder structure for your Faculty or Department Example of a Folder Structure ICS: General Rules of Thumb Keep security simple and understandable, or else: Bibliography... 16

3 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 errorprone. 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 1

4 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 2

5 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 ( 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 3

6 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 4

7 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 5

8 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 Security Report Draft 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. DON TS Remove files or data you no longer need to prevent unauthorized access to them. 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 6

9 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 7

10 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 Full Control Modify List Folder Contents Read and Execute Write Read Description Permission to read, write, change and delete files and sub-folders. Permission to read and write to files in the folder, and to delete current folder. Permission to obtain listing of files and folders and to execute files. Permission to list files and folders and to execute files. Permission to create new files and folders within selected folder. Permission to list files and folders. BASIC FILE PERMISSIONS Permission Full Control Modify Read and Execute Write Read Description Permission to read, write, change and delete the file. Permission to read and write to and delete the file. Permission to view file contents and execute file. Permission to write to the file. 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 8

11 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 9

12 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 Traverse folder / execute file List folder / read data Read attributes Read extended attributes Create files / write data Create folders / append data Write attributes Write extended attributes Delete subfolders and files Delete Read permissions Change permissions Take ownership Description Allows access to folder regardless of whether access is provided to data in folder. Allows execution of a file. Traverse folder option provides permission to view file and folder names. Read data allows contents of files to be viewed. Allows read-only access to the basic attributes of a file or folder. Allows read-only access to extended attributes of a file. 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 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) Allows the basic attributes of a file or folder to be changed. Allows extended attributes of a file to be changed. Provides permission to delete any files or sub-folders contained in a folder. 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. Provides read access to both basic and special permissions of files and folders. Allows basic and special permissions of a file or folder to be changed. 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 10

13 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 11

14 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 12

15 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 13

16 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 14

17 KEEP SECURITY SIMPLE AND UNDERSTANDABLE, OR ELSE: August 22, 2012 Version 2 15

18 BIBLIOGRAPHY How to Implement Role-based Access Control. (2007, October). Retrieved July 2012, from ComputerWeekly: Understanding Windows Server 2008 File and Folder Ownership and Permissions. (2011, April). Retrieved July 2012, from Techotopia: hip_and_permissions Best Practices for Securing your Computer, Accounts, and Data. (2012, July). Retrieved from Indiana University: University IT Services : Finn, A. (2005). Securing Active Directory Using a Roles-Based Approach. Retrieved July 2012, from 2000 Trainers: Gebel, G., & Neuenschwander, M. (2007, March). User Authorization. Retrieved July 2012, from Gartner: &ref=docDisplay Hiemstra, J. (n.d.). Shared Folder and NTFS Permissions. Retrieved July 2012, from TechExams.net: Kampman, K. (2011, May). Identity in SharePoint Retrieved from Gartner: 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: Microsoft. (2005, January). Windows Server: Best practices for Shared Folders. Retrieved July 2012, from Microsoft Technet: Microsoft. (2012, July). Best Practices for Securing Files with NTFS Permissions (IIS 6.0). Retrieved July 2012, from Microsoft: Posey, B. M. (2009). Quick tips for troubleshooting NTFS permissions. Retrieved from SearchWindowsServer: Vanover, R. (2006). 10 Things You Should Know About Working With NTFS Permissions. Retrieved July 2012, from TechRepublic: Various University Web Sites. (n.d.). August 22, 2012 Version 2 16

19 Windows 2003 NTFS and Share Permissions. (n.d.). Retrieved July 2012, from MC MCSE Certification Resources: August 22, 2012 Version 2 17