When you design security for file resources, consider
The key to ensuring secure file access is to plan your share and NTFS permissions before you deploy resources.
After this lesson, you will be able to
Estimated lesson time: 45 minutes
Share permissions are used to secure network access to data stored on a server. Share permissions are flexible in that they aren't limited to a specific file system. You can establish shares for folders located on file allocation table (FAT), FAT32, NTFS, and CD-ROM file system (CDFS) volumes.
Although they're flexible, share permissions are limited in that they have no effect on a user who is logged on locally at the computer hosting the shared folder. For example, if share permissions for the Project folder are configured to deny Read access to members of the Sales group, the share permissions would only come into effect if the Sales group is connecting to the Project folder over the network. If seated at the server itself, a user could read and execute any file in the Project folder. It's only by combining share permissions with NTFS permissions that you achieve a totally secure file access solution.
You can enable a shared folder by editing the folder properties. In the Properties dialog box, configure the share permissions in the Sharing tab, as shown in Figure 6.3.
Figure 6.3 Enabling a shared folder
When you enable a shared folder, you can limit the maximum number of sessions that are allowed. To configure more precise permissions, click Permissions. The standard permissions for a share are
Changes to Shares in Windows 2000
In Windows 3.1, Windows 95, Windows 98, and Windows NT, if you assigned a logical drive letter to a file share, you could only establish a fake root directory at the folder that was shared. For example, if you used the command net use h:\\server\home\brian , the drive mapping when you connect to the H drive would be h:\brian>. If you wanted the Brian folder to appear as the root folder, you had to share the Brian folder separately. In organizations with large numbers of users, this created an impossibly long listing of available shared home folders.
In Windows 2000 the default behavior is different. Typing the above net use command results in the root being established at the Brian folder. In other words, if you switched to drive H, you'd see h:\> as the command prompt. This provides additional security because the user won't be able to navigate to any folders above or at the same level in the folder hierarchy.
This doesn't affect down-level clients. They still require separate shares to be established for each user home directory.
When you design share permissions, use the following guidelines to increase security of share permissions:
You need to establish two separate shares for Wide World Importers: one for the default applications in Washington and a second for the Graphics department in Dallas.
To meet the current requirements, you need to establish the following share permissions for the \\Washington\Applications share:
These permissions allow all users to read and install the applications. Administrators are able to modify files and change permissions on the files.
To meet the security requirements for share permissions in Dallas, the need to assign elevated privileges to Lisa Jacobson, David Jaffe, Stefan Knorr, and Linda Kobara requires you to define a different set of share permissions for \\Dallas\Applications. You must define the following permissions to meet security requirements:
While share permissions affect only network users, NTFS permissions affect both network users and users who are at the computer console. In addition to providing local folder security, NTFS allows permissions to be set for individual files within a folder. The ability to set permissions on files gives you more flexibility when you design your security model for file access.
This raises the question of why share permissions are even required. Remember that to connect to a network resource, you must have an entry point. The share provides this entry point, and you can secure it by using share permissions.
Windows 2000 introduces functionality in the NTFS file system that isn't found in Windows NT. (Unless otherwise indicated, "Windows NT" refers to versions 3.51 and 4.0.) This functionality includes
If permissions for a resource are inherited, you can't remove them directly. You must copy the inherited permissions to the folder, thus breaking the inheritance, and then remove the individual Access Control Entry (ACE) from the Discretionary Access Control List (DACL).
You can define NTFS permissions at either the folder or file level. For folders, you can assign the following permissions in the Security tab of the folder's Properties dialog box: Full Control, Modify, Read & Execute, List Folder Contents, Read, and Write. Likewise, you can set permissions for individual files to Full Control, Modify, Read & Execute, Read, and Write.
The predefined NTFS permissions are compilations of several special permissions, including
The owner of a file or folder can always change permissions, even if the current permissions explicitly deny access to the owner of the file or folder.
Table 6.1 outlines how the special permissions map to the default folder and file NTFS permissions.
Table 6.1 Special Permission Composition
|Special Permissions||Full Control||Modify||Read & Execute||List Folder Contents||Read||Write|
|Traverse Folder/Execute Files||X||X||X||X|
|List Folder/Read Data||X||X||X||X||X|
|Read Extended Attributes||X||X||X||X||X|
|Create Files/Write Data||X||X||X||X||X|
|Create Folders/Append Data||X||X||X|
|Write Extended Attributes||X||X||X|
|Delete Subfolders and Files||X|
In general, you can define most permissions by choosing the predefined permissions. Remember that you must create security groups that will be included in each ACE in the DACL. The DACL will have one ACE for each level of access you define for an object.
The following factors will affect your NTFS permission design:
For more information on using security templates to define security configuration, see Chapter 8, "Securing Microsoft Windows 2000–Based Computers."
For the software deployment at the Washington office, the NTFS permissions are going to be consistent for the entire directory structure. This allows you to define NTFS permissions at a higher level in the directory structure. You could deploy the following NTFS permissions to meet the security requirements:
The NTFS permissions for the Dallas office will be more complex. This is because you need to provide additional permissions for the Corporate Graphics and Templates folders. By taking advantage of NTFS permission inheritance, you can make the permission assignments shown in Figure 6.4.
Figure 6.4 Recommended NTFS permission assignments
These permission assignments take advantage of NTFS permission inheritance in that all subfolders of the Applications folder inherit the permissions assigned at the Applications folder.
An important aspect of securing file access is understanding the interaction of share and NTFS permissions. One set of permissions doesn't necessarily take precedence over the other. Instead, the most restrictive set becomes the effective permissions for the resource. Use the decision tree in Figure 6.5 to determine effective permissions of each security principal.
Figure 6.5 Combining share permissions and NTFS permissions
Because individual share permissions or NTFS permissions may vary depending on the group memberships of the security principal, you should perform this evaluation separately for each security principal. For example, the share and NTFS permissions shown in Table 6.2 have been assigned to a folder named Data.
Table 6.2 Share and NTFS Permissions Assigned to the Data Folder
|Share Permissions||NTFS Permissions|
|Users: Read||Users: Read & Execute|
|Administrators: Full Control||Users: Write|
If a member of the Marketing department attempts to access a file in the Data folder over the network, the permissions are evaluated as follows:
Likewise, the effective permissions for an administrator would be Modify because the NTFS permissions would be the most restrictive.
In general, your strategy should be to designate either share permissions or NTFS permissions as the primary permissions when you set your security. To define a more granular level of security, designate your effective security through NTFS permissions. Evaluate all folders below a shared folder to determine the highest level of permissions that a security group requires and set the share permissions at that level. This ensures that the share permissions won't become the most restrictive permissions and prevent the NTFS permissions from being the effective permissions.
Should I Just Leave the Default Share Permissions in Place?
Probably not. When you create a new share, the default share permissions include a single entry that assigns Full Control permission to the Everyone group. In a secure Windows 2000 network, modify this share permission to prevent granting excessive privileges if NTFS permissions aren't monitored.
The Full Control permission under NTFS includes three additional abilities over the Modify permission:
- Delete files and folders you don't have permissions to
- Take ownership of a file
- Change permissions of a file
In most networks, these permissions are restricted to the network's administrators. If this is the case in your network, a more effective set of default permissions to use for a shared folder are
- Administrators: Full Control
- Users: Change
If users require only Read access to a folder, you should change the Users permissions to Read rather than use Change.
These permissions allow users to create, read, delete, and modify any files in the share, but they can't redefine security settings within the folder.
Use the following guidelines when planning for combined share permissions and NTFS permissions:
In reviewing the initial share permissions and NTFS permissions applied to the Applications folders in Washington and Dallas, you see that neither share per-missions nor NTFS permissions assign excess permissions.
While you could have left share permissions for Wide World Importers at the default of Everyone being assigned Full Control permissions, doing so could have resulted in excess permissions if any of the NTFS permissions were applied incorrectly.
To troubleshoot any potential problems with NTFS and share permissions, Wide World Importers must complete the design by documenting all initial permission assignments. The documentation should include all folders where permissions are assigned, details on group memberships, and the rationale for each permission assignment. The documentation will assist in troubleshooting permissions later.
You must perform the design of share and NTFS permissions by inspecting both sets of permissions. The effective permissions for any resources are based on the most restrictive settings when comparing the share permissions to the NTFS permissions. When designing file security, always base the share permissions on the maximum level of permissions required by a security principal for the directory structure. This ensures that share permissions never restrict access that NTFS permissions are attempting to provide.