Using Groups to Manage File System Security

When it comes to permissioning a file system, Microsoft has a very specific method that aims to reduce risk and simplify administration. Careful adherence to this technique will allow programmatic manipulation of file structure permissions using ADSI.

Unfortunately, most enterprises deviate from the file-permissioning guidelines set forth by Microsoft because they appear overly complicated to maintain. Microsoft recommends the following strategy for managing Windows NT security groups:

Place all user accounts into global groups in the user domain.
Add these global groups to a local group in the resource domain.
Apply permissions to resources by modifying the Access Control List (ACL) to include an Access Control Entriy (ACE) for the local group.

In most enterprises, however, practice all-too-often dictates that a conglomerate of user accounts be added directly to the ACLs for specific files in the file system as well as global groups added to ACLs on directories, and other severe departures are made from Microsoft's best practice advice.

There is a whole list of reasons why you should follow the advice from the folks in Redmond, but perhaps the most compelling reason is for pure administrative elegance . If you always use the "users in globals, globals in locals, permission resources using locals" strategy, after a directory has been set up, you should not need to add or remove ACEs in the resource's ACL.

If you have ever had someone (or worse yet, been the someone) in the system administration group apply a new ACL to a high level in the file system (such as the entire drive) and then propagate the changes throughout the file structure, you are well aware of the benefits gained by eliminating the need for direct ACL manipulation. By simply creating a group for each directory that requires unique permissions, you can eliminate all ACL management after the file structure has been created.

Consider the following directory structure:

 D:\ D:\Data D:\Data\MSOfficeData D:\Data\VisualStudioData D:\Apps D:\Apps\MSOffice D:\Apps\VisualStudio

In most enterprises, users requiring access to a specific directory are granted access through modification of the ACL to include an ACE for the user account or perhaps a global group that the user belongs to. Although you could easily grant a user access to both the D:\Apps\MSOffice and D:\Data\MSOfficeData directories in this manner, you must grant this access in more than one place at a time. While this may seem trivial in the two-directory example shown here, it is rather significant when an application requires permissions in 10 “20 directories for proper operation.

Creating an Inheritance Structure

You can gain significantly more control over the file system by simply creating one local group on the file server for each directory in the structure. If users require differing levels of access (Read-Only, Change, Full Control, or No Access) you can create several local groups per directory to accommodate these variances in access levels.

Beginning at the root of the filespace, grant the D_Drive groups ( assuming it is indeed the D: drive you are permissioning) access, and propagate the changes down the entire structure. Continue down all directories in the tree until you have applied every local group to every directory requiring unique permissions in the file system.

What you have now created is an inheritance structure in which a user granted access at a point high up in the directory structure (such as the D: drive) has access to this resource and everything below it. Likewise, a user granted access in the middle of the structure can see everything below where the account group membership allows, but cannot access anything above.

Consider Table 5.1 as an example of the ACLs for the MSOffice application directory.

Table 5.1. Establishing a File System Inheritence Structure

Resource	Local Group	Access Level
D:	D_Drive_FC	Full Control
	D_Drive_CH	Change
	D_Drive_RO	Read Only
D:\Apps	D_Drive_FC	Inherited (Full Control)
	D_Drive_CH	Inherited (Change)
	D_Drive_RO	Inherited (Read Only)
	D_Apps_FC	Full Control
	D_Apps_CH	Change Control
	D_Apps_RO	Read Only
D:\Apps\MSOffice	D_Drive_FC	Inherited (Full Control)
	D_Drive_CH	Inherited (Change)
	D_Drive_RO	Inherited (Read Only)
	D_Apps_FC	Inherited (Full Control)
	D_Apps_CH	Inherited (Change)
	D_Apps_RO	Inherited (Read Only)
	D_Apps_MSOffice_FC	Full Control
	D_Apps_MSOffice_CH	Change
	D_Apps_MSOffice_RO	Read Only

It is clear from this table that users belonging to the D_Apps_MSOffice_RO group will have read-only access to the D:\Apps\MSOffice directory, but cannot access anything in the D:\Apps level of the file structure, nor will they enjoy access to D:\Apps\VisualStudio.

If we create an MSOffice_Users global group in the user domain, we can add this group to the appropriate local groups on the server (such as D_Apps_MSOffice and D_Data_MSOfficeData ). This eliminates the need to assign explicit permissions to both of these directories for each user account requiring access.

Next, by adding user accounts to the MSOffice_Users global group in the user domain, any user account belonging to this group will enjoy access to both the application and data directories associated with MSOffice.

Note

This may seem to be a significant amount of work to initially implement, but there are immense benefits to this method of file system security management, including the capability to manage file system security using ADSI .

By avoiding direct manipulation of the ACLs on individual resources, you eliminate a significant amount of risk from incorrectly modified ACLs that were propagated down the directory structure from a higher-level directory. An administrator should manage group memberships on a regular basis, not ACLs .

Note

To help set up a new file server using this method, a script is available in the sample code for this book to help create and manage the directories and groups using this security administration method .

You can find this script at http://www.newriders.com/adsi .

Application developers should carefully consider this method; it can allow extremely granular access to files and resources in addition to simplifying administration. Rather than describing the ACLs required for the application to run and still retain a secure environment (or, worse yet, not apply any security to the file system at all), the developer can create groups and CACLS scripts to initially deploy the application.

Top