Securing Shared Resources

Know how to let users in—and keep them out

As an administrator, you must ensure that users have access to only the system resources they need. Controlling access to shared resources and troubleshooting access problems requires a thorough understanding of Windows NT accounts, authentication, NTFS file and directory permissions, permission inheritance, and explicit share permissions. I start by explaining the basics of NTFS file permissions and tell you how to define access controls that permit or deny access to resources. Then I discuss how you create shares and implement optional share-point access controls. After I cover the basics, I review common security-related mistakes people make when they set up shared resources—and tell you how to avoid those mistakes. Although the procedures in this article apply to shared files and directories, you can use the same rules to control access to printers and other shareable devices.

NTFS File and Directory Permissions
The best way to protect shared resources is to guard the share contents with NTFS file and directory permissions. To do this, you need to understand how permissions work and how files and directories inherit the permissions of their parent containers. With this knowledge, you can spot holes in your security and recognize when to replace the default wide-open access with more-restrictive access.

File permissions. File and directory permissions associate an account or group with one or more NTFS file permissions. NTFS supports six base-level permissions: Read (R), Write (W), Execute (X), Delete (D), Change Permissions (P), and Take Ownership (O). To simplify the definition process, the file system combines the base permissions into commonly used high-level permissions, such as List, Read, Add, Add & Read, Change, Full Control, and Special Access. For example, when you grant high-level Read access on a file, the Read function expands to Read and Execute (RX). Add & Read permission combines Read, Write, and Execute (RWX). Change permission combines Read, Write, Execute, and Delete (RWXD). Full Control includes RWXD and the Take Ownership permission. By default, the user who creates a file or directory (i.e., the Creator Owner) always has Full Control, which includes the Take Ownership permission. No Access, the most restrictive permission, denies access to the individual or group account you associate with this permission. When you assign the No Access permission to a group, the OS denies access to all members of that group, including accounts that have administrative rights.

Directory permissions. Directory permissions are slightly more complicated than file permissions because you're defining two sets of access controls: One set controls access to the directory, and the other set defines the default (i.e., inherited) permissions for files and directories you create in the directory. To display NTFS permissions, right-click a file or directory in Windows Explorer and select Properties from the drop-down menu. In the Properties dialog box, click the Security tab, then click the Permissions button to produce a display similar to the one Figure 1, page 12, shows.

After you select a permission from the Type of Access drop-down list, you'll see two sets of permissions next to that account or group in the Name area of the Directory Permissions dialog box. These are, respectively, the permissions for the directory and the permissions for the files in that directory. For example, when you set Add & Read permission on a directory, the Directory Permissions dialog box displays (RWX) (RX), signifying Read, Write, and Execute permissions on the directory, and Read and Execute permissions on files and subdirectories in the directory. When you select List access, the directory permission is (RX) (Not Specified), where (Not Specified) means users can't access files in the directory unless individual file permissions specifically grant the user access. If the Type of Access drop-down list doesn't contain the specific permissions you need for a file or directory, select Special Directory Access or Special File Access, then select individual permissions as appropriate.

Defining Access Controls
Before we discuss propagating permissions, let's get into a bit more detail about access controls. If you don't have administrative rights and you need to define an object's access controls, you must own the file or directory, or the object must explicitly grant you Change Permissions. Unless you change the NTFS default settings, Creator Owner ordinarily has Full Control, which, by definition, lets you change the access controls. The permissions you define for a file or directory constitute the discretionary ACL (DACL), which some administrators refer to as the ACL. Each entry on the list is an access control entry (ACE). To modify an ACE, highlight the entry on the Directory Permissions screen, as Figure 1 shows, and make a new selection in the Type of Access field. Alternatively, you can double-click the entry and select permissions in the Special Access dialog box that appears. To add an ACE, click the Add button in Figure 1 to bring up the Add Users and Groups dialog box, which Figure 2 shows. From the Names area, select the account or accounts you want to associate with specific access controls. Select the type of access from the Type of Access drop-down list.

How access controls work. When you request access to a local file or connect to a share, the Security Reference Monitor (SRM) compares your access token and the type of access you request with each ACE in the order in which the ACEs appear in the ACL. The owner's default group and the Creator Owner entries appear at the top of the list so that the file owner can gain access with a minimum of processing overhead. The SRM processes all the ACEs in the ACL and creates a cumulative permission mask that includes the access permissions for the groups to which the user belongs and any explicit permissions the user account has for the resource. An exception to this rule is the No Access permission. If a user account matches the account or group in the No Access ACE, the SRM immediately refuses the connection and won't process the remaining ACEs.

You must be sensitive to the order and number of ACEs you place in a DACL. Every ACE adds processing time to a file-access request, so a DACL with many ACEs can significantly increase overhead. When the ACEs start to pile up, you can almost always shorten the ACL and improve efficiency by defining a new group that contains the accounts of users or groups that need access.

Propagating Permissions
When you modify the permissions on a file, the changes apply immediately. When you modify permissions on a directory, the changes apply only to new files you store in the directory. To propagate new access controls to all objects in the directory, select the Replace Permissions on Subdirectories and Replace Permissions on Existing Files check boxes. If the directory contains a lot of files, NT can take several minutes to propagate the new permissions.

If your system hosts a directory in which specific users or groups can create and manage their own subdirectories and files, the directory must have the permission CREATOR OWNER:Full Control (All) (All). NT transfers permissions you set for the Creator Owner to the account of the user who creates an object within the directory. For example, suppose you give Add & Read permission on the directory to Everyone and Change permission to Creator Owner. When a user adds files to the directory, that user (i.e., the Creator Owner) can change and delete the files, but other users can only read the files.

To make your system easier to administer, start by defining access controls on an empty directory. Then populate the directory with files and lower-level structures. When users add files to the directory, each file automatically inherits the access controls from the second set of directory permissions.

Permission inheritance. When you create a new file or directory, the object inherits its parent container's permissions. NT assigns Everyone:Full Access to volumes, and if you don't override the default, any new file or directory you create at the top of a volume (e.g., C:temp or D:users) inherits this wide-open access. Files you create or copy within these unsecured top-level folders inherit the Everyone:Full Control ACL, but files that you move (i.e., cut and paste or drag) to a directory on the same volume retain their permission settings. It's easy to view this inheritance behavior. Create a temporary directory, and create a file called newfile.txt in the directory. You'll see that newfile.txt gets an exact copy of the permissions on the temporary directory. Next, restrict the permissions on newfile.txt to a specific account, and copy the file in place so that you have a copy of newfile.txt in the same temporary directory. The copy inherits its ACLs from the temp directory instead of from the original file. Now drag or cut and paste a file from another directory into temp, and check the permissions—you'll see that the permissions of the moved file are the same as the original's.

NT's handling of permission inheritance offers two implicit security lessons. The first lesson is that if you leave the default NTFS permissions, NT propagates this public access to all lower objects. Security-conscious administrators replace public access on data volumes with a more restrictive permission, such as Everyone:List or Everyone:Read. If your system has a volume that hosts only data for a classified project or other sensitive subject, protect the entire volume by giving only the group of users who need access to the data permission to Read or List at the volume level (i.e., set permissions on the drive letter). The exception to this rule is the system boot disk; you can disable logons or the OS if you remove Everyone access to the system boot disk without following the rules.

The second lesson is that permissions behave differently when you copy versus move files. When you copy files, the copied file always inherits permissions from the parent container. This means you lose all your carefully constructed access controls and, in the worst case, when the destination directory has Everyone:Full Control, the files you place there are open to accidental or purposeful misuse. To avoid overwriting ACLs, copy files and directories with the secure copy utility Scopy from the Microsoft Windows NT Server 4.0 Resource Kit. This utility accepts three command-line arguments: /o preserves file permissions, /a preserves audit settings, and /s includes all subdirectories in the copy operation.

Creating Shares
After you set up access controls on files and directories, you can create a share and establish share-level access controls. To create a share, you must have Administrator, Server Operator, or Power User rights on the machine that will host the share. Administrators can create remote shares by several methods, including using Windows Explorer, Server Manager for Domains, or the Net Share command. To create a local share in Windows Explorer, right-click the file or directory and select Sharing. The Properties dialog box, which Figure 3 shows, appears. (You can also reach the Properties dialog box by right-clicking a file or directory, selecting Properties, and clicking the Sharing tab.)

In the Properties dialog box, enter the share's name (it defaults to the directory's name). You can add a dollar sign ($) as the last character to hide the share and prevent NT from publishing the NetBIOS share name on the network. Users with the proper credentials can connect to hidden shares, but the share remains confidential because the OS doesn't publish it. To limit the number of concurrent accesses to the share, select Allow and enter a number. The User Limit setting defaults to Maximum Allowed, which means the number of concurrent accesses is unlimited.

Share permissions. Share permissions control which users connect to the share from the network. After a user connects to the share, NTFS permissions control how a user accesses the files. NT assigns the ACE Everyone:Full Control to a new share. Most systems administrators prefer to use the default Everyone:Full Control and restrict this public access with suitable NTFS permissions on the share's contents. This method is the most efficient way to implement shared resources because you avoid the overhead of maintaining and processing share-level access controls.

For a directory that contains confidential or proprietary information, it's wise to restrict share access to add a second level of protection. Share permissions apply to all files and subdirectories in the share and offer less granular protection than NTFS permissions. To restrict share access, click Permissions on the Sharing tab. The Access Through Share Permissions dialog box, which Figure 4 shows, appears. The Type of Access drop-down list offers four choices: No Access, Read, Change, and Full Control. To add and modify share permissions, use the Add Users and Groups dialog box, just as you do to modify NTFS permissions.

Guidelines for Securing Shared Resources
Now that we've covered the basics, let's look at some guidelines for doing a thorough job of securing shared resources. In general, NTFS permissions should be most permissive at the top of a volume and more restrictive as you create lower-level structures. Create the directory you'll share and define appropriate NTFS access controls before you create the share, limit the ACEs to only those you require, and place the most restrictive ACEs at the top of the DACL so that the system processes those ACEs first. Use the No Access permission sparingly, if at all, because it denies access to the accounts you associate with this permission. If you add an Everyone:No Access ACE, you render a file, directory, or share inaccessible.

Here are some tips for avoiding some common mistakes in securing shared resources:

NTFS permissions are the key to securing shared resources, so employ them carefully and check them often. And remember the rules for move versus copy. The file system overwrites ACLs when you copy files and directories, whether to the same or a different volume, as well as when you move files and directories to a different volume. You can lose all the access controls you set up for a share if you forget these basic rules.