Controlling access to shared resources in Windows 2003 Server
One of the most fundamental tasks that any network administrator will face is controlling access to shared resources. Lately, it seems that there is a lot of emphasis placed on preventing outsiders from accessing your private network and on securing server and Web-based applications. However, it’s just as important to secure your data internally. Here are some of the various aspects of controlling access to shared files on a Windows 2003 Server.
Share access vs. file access
In Windows Server 2003, there are basically two levels that you can give someone access to a file through. You may grant (or block) access at the share level or at the file level. The concepts behind both are very different, and both methods have their good and bad points.
Setting up share level access involves right-clicking on a folder and selecting the Sharing and Security command from the resulting shortcut menu. When you do, you will see the folder’s properties sheet appear and the Sharing tab will be selected. Next, you must click the Share This Folder radio button and then enter a share name and a description for the share.
Now that you have created the share, you must click the Permissions button to control who has access to the share. By default, Everyone has Read access to the share. In Windows, Everyone refers to the group called Everyone which represents, as you can guess, every user object in Active Directory
This is new for Windows Server 2003. As you may recall, Windows 2000 gave everyone full access to a newly created share by default. Generally speaking, share level security works well, but it does have its downside. Suppose for a moment that you created a directory named Departments and then created subfolders beneath it named Finance, Marketing, and Sales. Any one that you gave access to the Departments share would automatically have access to the subfolders beneath it.
The problem comes into play if you wanted to create independent share points for the Finance, Marketing, and Sales folders. Suppose that you had a user that you wanted to have access to everything except for the sales folder. You could set the Sales folder’s permissions to block the user at the share level. However, if the user had access to the Departments share, he would automatically have access to the Sales folder because it lies beneath it.
If you are wondering how this can be when you have explicitly denied the user access to the Sales folder, I have an explanation that might help. First, you haven’t actually denied the user access to the sales folder. You’ve only denied the user access to the sales share. The user still has access to the Sales folder. The only restriction is that he can’t pass through the Sales share to get to the Sales folder. Instead, he must find a different way into the folder. In this case, that alternate way in would be by passing through the Department share.
As you can see, you would only want to use share level security to secure folders that will use a single tier permission structure throughout the folder tree. For more complex security structures, you are much better off implementing permissions by using file level security.
Before you can implement file level security, the volume containing the folder or file that you want to secure must be formatted using the NTFS file system. If you have installed Windows Server 2003 from scratch, then this shouldn’t be a problem. NTFS is the only file system that Windows Server 2003 is designed to use on newly created volumes or partitions.
However, if you have upgraded your server from Windows NT or Windows 2000, you might have a partition that is formatted as FAT or FAT-32. These partitions do not support file level security. If you have such partitions, you must convert them to NTFS prior to using file level security. You can do so with the CONVERT command. The syntax is CONVERT drive_letter: /FS:NTFS where drive_letter: is the drive that you want to convert. For example, if you wanted to convert the D: drive, you would enter CONVERT D: /FS:NTFS.
Once your partition is running the NTFS file system, you can apply permissions at either the file or at the folder level. To do so, right-click on the file or folder that you wish to secure and then select the Properties command from the resulting shortcut menu. When you do, you will see the file or folder’s properties sheet. Next, select the Security tab and you will see who has access to the file or folder.
When you create a file or folder on an NTFS volume, there are some default permissions that are applied. Obviously, the Administrator is given full control. The Creator Owner is given special permissions which basically amount to having full control. The system is given Full Control and the Users group is given Read & Execute, List Folder Contents, and Read permissions. Again, this is a deviation from Windows 2000, which gives Everyone Full Control to a newly created folder.
Of course these default permissions apply only at the root level. At lower levels of the directory structure, permissions are inherited from higher level folders. Therefore, if the Users group was blocked at a higher level then the users would not have access to a subfolder of the blocked folder because the permissions would be inherited from the parent folder. Of course, you can always override inheritance, but I will talk more about that later on.
For now though, I want to address a more pressing question. Is it more appropriate to use file level security or share level security? The answer is that it depends on who you ask. There is a lot of contradictory information about the right way to secure files and folders. Even if you look at various Microsoft documents, you will find inconsistencies. Therefore, I tend to disregard the various TechNet articles and do security my way.
The way that I implement security is to secure files and folders at the file level. However, simply saying that I implement security at the file level isn’t enough. There are several important ground rules that I follow to make things work correctly.
First, unless a user is accessing a file or folder directly from the server console, they will need a path through which to gain access to the file. In Windows, this path is usually a share point. Therefore, although I tend not to use share level security, I still use share points as a way of letting users access the protected files from across the network. The difference is that I set the security on my shares to allow everyone to have Full Control.
I want to clear up a common myth. In Windows 2000 Server, the Everyone group contained both authenticated and nonauthenticated (anonymous) users. This meant that in theory, someone who was just visiting your Web site and wasn’t even logged into your network was a member of the Everyone group. In Windows Server 2003 though, anonymous users are not a part of the Everyone group.
With that said, I implement the real security permissions at the NTFS level. To avoid confusion though, I only grant permissions to security groups; never to individual users. I also grant permission only to folders; rarely to individual files. Using this technique eliminates the vast majority of the confusion that may occur when granting permissions and when trying to determine who has access to what.
Now that I have discussed the basic differences between share level and file level permissions, I want to address the issue of inheritance. Earlier I explained that a file inherits the permissions of its parent folder. However, there’s quite a bit more to inheritance than that.
In previous versions of Windows, the only way to check a file or folder’s permissions was to look at the permissions of the parent folder and any permissions that had been explicitly assigned to the file or folder. You would then have to combine the inherited permissions with the explicit permissions to determine the effective permissions for the file or folder. What made this tricky was that sometimes conflict would occur because contradictory permissions might be assigned to the parent folder and the current file or folder.
In such a situation, it was easy to resolve contradictions because explicit permissions always override inherited permissions. What wasn’t so easy to figure out is the effective permissions for a particular user.
For example, what do you do if a user is a member of two different security groups with two different levels of access to a file or folder? Again, the rights are combined and an explicit deny overrides an explicit allow. It was possible to iron out such conflicts, but Windows 2000 file level security could be a nightmare if your file system, including inheritances, wasn’t extremely well organized.
In Windows 2003, Microsoft took the initiative to make inheritances and effective permissions much easier to calculate. To see how the new mechanisms work, right-click on a file or folder and select the Properties command from the resulting shortcut menu. When you do, you will see the file or folder’s properties sheet. Now, select the properties sheet’s Security tab. The Security tab displays assigned rights, but not inherited rights.
If you want to view the inherited rights for the file or folder, you will have to click the Advanced button. When you do, Windows will display the Advanced Security Settings properties sheet for the file or folder.
This properties sheet contains a Permissions tab. The top portion of the Permissions tab displays all users and groups that have access to the file or folder. This list tells the user or group name, the type of permission (Allow or Deny), and the effective permission (Full Control, Read, etc.). The nice part about this list is that not only does it tell you the effective permission, it even tells you where the permission was inherited from. If a permission was directly assigned to the file or folder rather than being inherited, the Inherited From column will simply display the words <not inherited>. The table’s last column even tells if the effective permission applies only to the current file or folder, or if it also applies to subfolders.
Another nice feature of the Permissions tab is that it contains its own set of Add, Edit, and Remove buttons. That way if you see a permission that you don’t like, you can fix the problem directly from this screen.
The Permissions tab also contains two check boxes that are worth mentioning. The first check box, when enabled, is designed to allow inheritable permissions from the parent to propagate this object and to all child objects. Basically, this means that if you select this check box then the current file or folder will inherit permissions from the parent folder. It also means that if you happen to be working with a folder rather than a file, that any permissions used here, whether assigned or inherited, will apply to subfolders.
This check box is selected by default. Normally, you would want to leave this check box selected. From a Windows administration standpoint, it is considered to be bad management to deselect this check box. The reason is that if you disable inherited permissions, then it tends to become more difficult to figure out what permissions belong to which folder. There are certainly cases where you would want to deselect this check box, but don’t deselect it unless you have no other choice.
The other check box is named Replace Permission Entries On Child Objects With Entries Shown Here That Apply To Child Objects. This is another check box that can get you into trouble. I strongly recommend never using this one.
Earlier I mentioned that the last column of the Permissions properties sheet tells whether the permission applies only to the current file or folder, or to subfolders as well. If you select this check box, then any permissions that show on the Permissions tab as being applicable to subfolders will be applied to subfolders. The catch is that these permissions will override any permissions that have been explicitly assigned to subfolders. You will almost never want to do this. The only time that I can see doing something like this is if you wanted to guarantee that a subfolder’s permissions were never changed.
I have talked a lot about the effective permissions for a file or folder, but I have not yet answered every question. Earlier, I stated that it was possible for a user to belong to multiple security groups that have contradictory permissions to a resource. In Windows 2000, you had to calculate the effective permissions for the user yourself by examining which permissions belonged to each group. However, Windows Server 2003 makes this process much easier.
To find effective permissions, return to the Advanced Security Settings properties sheet for the file or folder that you are working with, and select the Effective Permissions tab. This tab allows you to enter a user name or a group name and will then display the effective permissions for that user or group. This takes all of the guesswork out of securing a file or folder.
The last aspect of file security that I want to discuss is ownership. Every file on an NTFS partition has an owner. The owner is the user who created the file or folder. The owner is allowed to control who has what permissions to the file or folder.
The reason that I want to discuss this is because sometimes it's necessary to change ownership. For example, suppose that a user creates a folder and assigns some inappropriate permissions to the folder. The Administrator can’t change the permissions without first taking ownership of the folder.
To take ownership, an Administrator would open the Advanced Security Settings properties sheet for the folder, select the ownership tab, and then use the Change Owner option. There is also an option to change the ownership on all subfolders.
Taking ownership of a file or folder is not purely an administrative function though. While it's true that an administrator always has the option of taking ownership of a file or folder, anyone can take ownership of a file or folder if she has been assigned the right, Take Ownership Of Files Or Other Objects. The Restore Files And Directories permission also allows someone to take ownership if necessary.
The file’s current owner can also assign the Take Ownership permission to another user. When doing so, this only allows the recipient to take ownership of the current file or folder. It does not give the recipient global permissions to take ownership of any file or folder. Furthermore, simply conveying this right does not change the file or folder’s ownership. The recipient actually has to take ownership to complete the process.
Easier than it seems
As you can see, file permissions are relatively complex. However, Windows Server 2003 makes it much easier to accurately assign permissions than previous versions of Windows did. You have plenty of flexibility when assigning permissions. Just be careful when assigning permissions so you don't create conflicts that can lead to troubleshooting headaches later.