Wednesday, April 1, 2009

NTFS Permissions

Here is a piece detailing my methodology in dealing with users and network file space. I use NTFS permissions, which is a file security schema implemented in the NTFS file system from Microsoft.

Some of the key rules of NTFS permissions: There are six standard rules for folders, five for files. These standard permissions control general aspects of file security. There are also 14 special permissions which allow a much more detailed control of access and security. Every permission can be explicitly allowed or denied, or they can be inherited from a parent object. Deny can also be implied by the absence of explicit or inherited allow permissions. Permissions are assigned via the presence of objects in an Access Control List(ACL), but permissions belong to the object to which they are assigned, not to the user or group in the ACL.

I use Shares, NTFS Permissions, and User Groups in concert to provide users ever-expanding rings of file access. I begin with the premise that users need, at a minimum, the following areas of file storage: First, they need a private space to keep their work that is in progress, confidential, or other things that are generally not to be shared with others. Second, users who work together need a file space that helps them to work together. Third, users who work together across departmental boundaries also need a shared space to help them get things done.

To accomplish my three levels of access, I create the following folder structure: In my data volume (which is created separate from my operating system volume) I will create a folder called “user data” or some similarly descriptive name that gives me a clue as to the content of that folder. This folder becomes the root of the user share structure. Next, inside the root folder I create a folder called Users. Inside Users I create a folder for every employee's user name. These folders inside Users are the private folders for the employees, also known as “Home Directory” or “Home Drive” and often assigned the drive letter H:(for “Home”). Usually they are shared as jdoe$. The trailing dollar sign makes it a hidden share, so that people poking around the file system will not see the folder if they are coming across the network and don't have access to a folder higher up in the tree. That completes the personal folder.

Next, back up in User Data, I'll create a folder called “Departments.” In that folder I'll create sub-folders like “Finance,” “Marketing,” “Development,” “Human Resources,” and so on. This will give the users in the same department a place to store files that they are sharing with departmental co-workers. I give the department's users full control inside their department shares so that they can create new folder structures inside that are helpful for them.

Next, returning again to User Data, I create a folder called “Public.” The public folder is available to all, and all users have full control. It is akin to the wild west of file systems, but it serves a valuable purpose in allowing users from different departments who may be working together on a project a collaborative space. Additionally, I can create sub folders in Public and block inheritance. This allows me to create, for example, a folder called “HR Info” in which the HR users have full control and all others have read only. HR can then deposit files like the employee handbook or benefits information in that folder and all users can read it. This saves me from having to create too many folders that get mapped as drives.

All employees are trained in the structure of the folder tree and the rights that they and others have throughout. It is made clear to them who can see what, where, and they are also assured that there is no such thing as “privacy” on corporate file servers or computers. We give you a “private” space, but it's always available to the system administrator at the command of the appropriate management staff. It may be called private, but nothing should be in there that would be against any company policy, civil law, or reasonable moral standard.

Once my folders are in place, I go on to create groups for every department. I place the appropriate users in each of the departmental groups, and then I set the NTFS permissions on the Department sub folders by group. The rights to Public are assigned to the “Everyone” group, and rights to the user folders are assigned per user.

At this point you may be saying to yourself “That's a lot of people with full control!” I agree, it is, and the concern over files being inadvertently or maliciously deleted is a legitimate one. For this reason I have implemented other file-security solutions so that I may recover any file in moments. It's the best of both worlds.

There are special circumstances that will occur. For example, let's say a share is desired for the department heads only. I would create a “Department Heads” folder in the Departments sub folder. I would then create a group and give access rights to that group, then finally add the heads to that group.

The way I provide access to the various shares is through a Visual Basic login script. The script uses variables to make it simple. When a user logs on, the script runs and finds the user name and all groups that the user belongs to. With this information it maps network drives on the workstation. H: is the private share, I: is the department share, J: is public, and special folders follow if the user is a member of other groups.

Here is a little graphic to illustrate the folder structure. Hopefully it comes through ok.


D:
|--->User Data - (not shared, no permissions)
|
|------->Users - (not shared, no permission)
| |-------->jdoe$ - (hidden share, permissions only for Jane Doe)
| |-------->tjones$ - (hidden share, permissions only for Tom Jones)
|
|------->Departments - (not shared, no permissions)
| |-------->Finance - (shared, permissions for the Finance group)
| |-------->Marketing - (shared, permissions for the Marketing group)
|
|------->Public - (shared, permissions for the Everyone group)

No comments:

Post a Comment