The 12 Commandments of File Sharing

File shares can be a vital exchange point for collaborative user files that are too large to send as email attachments. Aside from the convenience of easy user access, these shares typically exist on a server with redundant storage solutions, which minimizes the potential of losing data through disk failure because you can back up data centrally rather than having to back up each user's client PC. (Anyone who has paid a data-recovery service $1000 to $3000 to pull crucial data from a failed desktop PC hard disk can appreciate the value of file-server storage redundancy.)

For these reasons, file shares are a commonly used resource. However, file sharing is also a highly vulnerable practice, and if you don't know what you're doing, you can put corporate data at risk. I've discovered that many systems administrators don't really understand how share and NTFS permissions interact and don't have a solid overall plan for their shared-folder resources. To help you analyze your current shared-folder environment and perhaps pick up a few new best practices, I've put together the following 12 commandments of file sharing.

1. Develop Standard Permissions
Although each share owner will eventually grant customized permissions to particular groups on that share, you need to develop a standard group of permissions to put on all shared folders when you create them. Typically, this set of permissions will be Administrators and System-Full Control. Also, consider using a Global Deny group that specifies Deny for all permissions settings. (See commandment 9 for an explanation of this group.)

2. Keep the Permissions Simple
A simple permissions structure is easier to manage. Yes, you can create 47 groups to manage a file share and assign permissions at a number of different levels, but is doing so a good idea? If you don't help share owners think through the initial structural requirements for their file-share permissions, you're doing them a disservice. Often, the requirements that share owners start out with are actually an unrealistic wish list that will make managing the share point difficult for both IT and the share's owner.

When a share owner outlines an elaborate permissions structure, try to see whether you can achieve similar results with a simpler approach. In some cases, the owner will be a manager who will explain that he or she needs to protect data from employees. Statements such as "We need to keep Jim from seeing this data because he might misuse it" or "We can't give Sally Change permissions because last year she accidentally dragged one of our key data folders off the server onto her desktop" indicate that some past training problems or departmental politics are driving the requirements for overly complex share permissions. Perhaps a better solution is for Jim to take an ethics course or for Sally to get some basic computer-etiquette training.

3. Use Security Groups
The Microsoft certification training courses encourage the use of security groups instead of individual user accounts for assigning permissions. Most of you start out diligently following that advice, but things can quickly deteriorate into a permissions free-for-all, and you begin assigning permissions to individual users. After you begin the slide down this slippery slope, administrative overhead can become a nightmare. If additional users require similar permissions, you have to duplicate or clone user permissions with a third-party tool such as Small Wonders Software's Security Explorer. If the file share is large, flowing down the cloned permissions can take hours. Unless you keep detailed documentation, you might lose track of which permissions a user actually has and you'll need to use your third-party tool to create reports that contain that information. To avoid these pitfalls, the best approach is to always assign permissions at the group level.

4. Give Groups Succinct and Intuitive Names
Give your security groups names that identify the permissions that group members have and which file shares those permissions apply to. This naming approach gives you a direct mapping of groups to file-share locations and makes life easier for the security or Help desk team that will populate the group with new employees after the initial group and share are set up. Try to keep the names to fewer than 20 characters and avoid spaces and ampersands (&). These steps will make command-shell scripting operations to assign or capture share permissions easier because some commands, such as the Net Localgroup command, don't support names longer than 20 characters. Table 1 shows how you can make a relatively short security group name communicate the share and subfolder location and the permissions the group has on that folder.

5. Define Permissions Sets That Reflect Department or Job
After you determine your share and folder permissions strategy and create the first-level groups that you developed in commandments 3 and 4, you could directly populate these groups with usernames. However, if you're running in Windows native mode and can support local group nesting, you can simplify your permissions assignment by creating a second level of local groups that contain the user accounts. Name these groups according to department or job role (e.g., SalesManagers), then add them to the top-level security groups. For example, add the local SalesManagers group, containing the user accounts of all sales managers, to the SalesAircraft-C security group (listed in Table 1) to grant any sales manager Change access to the Aircraft subfolder in the \FileServerASales share. Of course, the sales managers will need to access other resources—which brings up the concept of a permissions set.

A permissions set is the entire package or set of permissions that a user in a given department and job assignment requires to perform his or her job. The resources that the user needs to access might exist across many servers and diverse shares. The permissions set can change as new resources are added and resource-access needs change. For example, management could determine that the sales consultants who previously needed only Read permissions on an area now require Change permissions. The end goal of a permissions set is to make permissions assignment simple and accurate.

Department- or job-based permissions sets are useful when a new employee is hired to fill a specific department and job role that requires access to appropriate share areas. For example, when the company hires a new sales consultant, you add the person to the SalesConsultants group, and he or she instantly has all the permissions that a sales consultant needs. When the sales consultant is promoted to sales manager, you can change the person's permissions by adding the user to the SalesManagers group and removing him or her from the SalesConsultants group. Table 2 shows a sample permissions set. Simply adding users to the SalesManagers group instantly gives the users the permissions they need and removes the potential for access to sensitive areas that they shouldn't access. If someone creates a new share and associated security group (e.g., HRreporting-C) that needs to be added to the SalesManager permissions set, simply add the SalesManager group to the HRreporting-C group, and all the sales managers will have the correct permissions without you needing to add individual sales manager IDs to the HRreporting-C group.

6. Know How to Determine Effective Permissions
Creating effective share-level, NTFS, and overall permissions can be confusing and can result in excessively loose access or, on the other extreme, the dreaded Access Denied message for users that require share access. The rule of thumb for determining effective permissions is "loose, loose, tight."

The first loose is for the folder permissions. When, because of group membership, a user has different permissions at the NTFS file and folder levels, the actual file or folder permission is the least restrictive permission of all the permissions assigned to a user or to groups to which the user belongs. For example, a user who has List file and folder permissions because of membership in one group and Read permissions because of membership in another group will actually have the more loose of these two permissions settings (i.e., Read permissions).

Note: When you create a shared folder, you must grant users at least NTFS List or Read permissions on the root folder that you used to create the share. If you neglect to grant List or Read permissions, users will get an Access Denied message even if the share permissions and other subfolder NTFS permissions look correct because the users don't have permission to drill down through the shared folder to their final destination.

The second loose is for the share permissions. When a user has different share permissions because of group membership, the actual share-level permission is the least-restrictive permission of all the permissions assigned to a user or to groups to which the user belongs. For example, a user with Read and Change permissions on a certain share will have Change permissions on that share because it's the least restrictive of the two settings.

The tight is for the effective permissions that are the result of combining the folder permissions and the share permissions. Our sample user has Read permissions at the NTFS level and Change permissions at the share level. The effective overall permission is the more restrictive of the two settings—in our example, Read.

7. Don't Use the Everyone Group
Often the Everyone group is granted Full Control on share and NTFS permissions by default. The Everyone group combined with Full Control is a big security hole and should be removed on both share and NTFS permissions. If you need a general user access group, use the Authenticated Users group instead.

8. Avoid Folder Spread
On The Outer Limits science-fiction series, the announcer claimed, "We control the vertical. We control the horizontal." If only we administrators had as easy a time controlling the vertical and horizontal spread of our shared folders. On the horizontal side of the problem, you've probably all created public shares for which you granted users Change permissions at the share root level to let users organize their own data. The next time you accessed the share, you discovered that it contained 100 folders and 50 files at the root level. This folder overload can make it difficult for users to find the files and folders they're looking for.

A better approach is to use NTFS permissions to limit root-level folder creation to Administrators. Inside the Read-only root-level folder, create 3 to 10 logical folders for user data and grant users Change permissions on and below the logical folders. You'll need to work with the departmental point of contact to define the top-level folder names.

The vertical-spread problem is a bit tougher to control because over time, users tend to deepen the folder structure and exceed the 255-character path limit that Windows supports. This deep folder structure can result in files that users can't easily access and that might not be backed up properly. This problem is best controlled by careful monitoring and appropriate user notifications when a file path grows close to the 255-character limit. For more information about long pathnames, see Real-World Scripting, "Locating Long Paths in a Directory," January 2000, InstantDoc ID 7828.

9. Create a Global Deny Group
Sometimes you need to quickly deny a particular user access permissions across all shared resources in your environment. However, doing so can be difficult if you have multiple servers and multiple shares and can be further complicated if individual users have been granted access apart from groups. Identifying and changing a user's access permissions and removing the user from groups in which permissions flow down can take time. If an employee is being discharged or the object of some type of investigation, management might request instant removal of a user's access abilities. The simplest way to accomplish this is to create a Global Deny group that has only Deny permissions on all shares and in all NTFS permissions. Note that I don't use the term Global to define a group type (as in a local or a global group) but instead to describe a group that will be used across all your servers and all the shares in your environment.

Pick a descriptive name such as GlobalDeny-NA, which makes the group's purpose—to grant No Access—obvious. The population of this group usually will be empty. When the request comes to deny a certain user access, simply place that user's account in the group. Because Deny always takes precedence over other permissions, the user will be denied access. You can later take appropriate steps to remove the user's access from any directly granted permissions areas or permissions groups.

10. Actively Police Permissions Degradation
Often, administrators start with a well-designed permissions structure, which, over time, is modified by various individuals. Granting too many users Full Control at the NTFS file and folder or share level opens up the potential for users to modify the permissions structure and open up security holes or lock out authorized users. On more than one occasion, I've had well-meaning users who insisted they needed Full Control actually remove the Administrators group from the permissions structure and lock the other administrators and me out.

To help keep track of your permissions, maintain a spreadsheet, such as the one that Web Figure 1 (http://www.winnetmag.com, InstantDoc ID 42277) shows, that documents your shares' Security groups and permissions structure. You can use this information to explain share organization to management, and it's extremely valuable when reorganizations occur. Regular spot checks of permissions can ensure that the current permissions structure matches the design specifications on your spreadsheet. You can use scripts to help capture existing permissions and be better prepared to reconstruct the permissions in the event of a major disaster or emergency response to a short-term problem.

11. Develop an Emergency Response Strategy
Unfortunately, an all too frequent situation these days is to find your file shares becoming targets of viruses that can delete data not only from users' local disks but also from mapped drives. An unchecked virus operating in a user's context with Change permissions on a shared folder can result in mass infections or catastrophic data deletions. If a new virus attack gets past the corporate firewall and begins to affect your users and threaten your shares, which steps do you need to take to protect the data? Do you shut down all the servers? Isolate them from the network? Or perhaps take all your shares temporarily to Read-only so that at least some user work can continue? Now is the time to work out your response strategy, which will require close coordination and buy-in from management so that everyone understands the risks to shared data and how your plan will address this area of vulnerability.

12. Give Users Centrally Managed Shortcuts to Shared Resources
One clever way to grant users greater accessibility to shared resources is to give your user community a set of desktop shortcuts that point to shared resource locations. This setup can also reduce the risk that a virus will affect users' mapped drives on their desktop machines. You can customize these shortcuts according to the user's department or job function and deploy the shortcuts through Group Policy.

One trick to make resource management easier is to create a shortcut on the user's desktop that points to a Read-Only folder on a publicly available share. Inside this server-located folder, place shortcuts to all the shared resources you want the user to see. This setup lets you modify the shortcuts on a single central server location and have the changes take effect immediately. If changes occur in resource locations or if additional resources become available, you can make these changes on the server-located shortcuts without having to recreate any shortcuts on the user's desktop. If you deploy a desktop shortcut that gives different departments their own shared-resource views, simply create additional server-located folders as needed that contain shortcuts customized for each department. You can also add shortcuts to intranet or Internet Web resources.

Keep the Commandments
Your shared folders can be secure and a breeze to administer if you properly plan and manage your permissions structure. Just follow the 12 commandments of file sharing to stay on course in this important area.