Making Effective Use of Permissions
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Published in TechRepublic's Windows NT Administrator Report (TechRepublic.com)
As you're probably aware, Windows NT provides a number of ways that you can grant access to resources. For example, you could grant permissions to an individual or to a group of users, and you could use file permissions or share permissions. Needless to say, with so many ways of controlling access, it's easy to make a mess of things and end up with overlapping permissions, which usually result in unexpected side effects. In this article, we'll explore some techniques you can use to effectively manage Windows NT resources.
On This Page
Using proper techniques
Before we begin, it's important for us to point out that when it comes to setting the permissions for your network, there's really no right or wrong way of going about it. The techniques we'll discuss in the remainder of this article are based purely on experience and are proven to work. However, if you already have a method of managing resources that works well for you, there's no reason to give up your method and adopt ours.
File vs. share permissions
You can set resource permissions in two places within Windows NT: at the file level or at the share level. Each method has advantages and disadvantages.
If you have experience with peer-to-peer networking, you're probably already familiar with share-level permissions. Share-level permissions are permissions that you can set for network shares. You can set share-level permissions by right-clicking on a folder and choosing Sharing from the resulting context menu. Once you've assigned a share name, you can grant access to the share by clicking the Permissions button and editing the share's permissions, as shown in Figure A.
Although share-level permissions work well across a network, they offer absolutely no protection against a user who's logged on locally to the computer containing the share. For example, let's say that Joe Smith wants to gain access to a file that's protected by share permissions. If the share was set to deny access to Mr. Smith, he wouldn't be able to access the file across the network. However, if he logged on locally at the server that's hosting the share, he would have no problem gaining access.
Another downside to share-level security is that your server can eventually contain so many shares that it's hard for users to remember what they all do. Keep in mind that if users want to search for information and they don't know which share it's contained in, they'll have to find the server in Network Neighborhood and search each share on the server for the desired information. Although there's technically nothing wrong with having a zillion shares on a server, doing so can cause frustrations for users.
File-level security usually provides more efficient protection than share-level security. The only real downside to file-level security is that it only works on an NTFS partition. For example, suppose your C partition is formatted as FAT and your D partition is formatted as NTFS. You can use either file-level or share-level permissions on your D partition, but you're limited to using share-level permissions on your C partition.
File-level permissions offer more protection than share-level permissions. Suppose Joe Smith is at it again and tries to access a file protected by file-level permissions. The permissions you assign will stop him from gaining access to the file both across the network and locally.
File-level permissions also offer a greater range of flexibility when assigning permissions. As we discussed earlier, setting share-level permissions requires you to share a directory and assign permissions to the share. When using file-level permissions, you can set access to a directory and all the files within it, or you can control access to an individual file, as shown in Figure B.
Although you can use a combination of file-level and share-level permissions, it's best to stick to one or the other. Mixing them on the same volume can result in contradictory user rights.
User permissions vs. group permissions
As you might already know, you can grant rights to either users or groups for both shares and files. However, in our experience it's best to grant permissions only to groups. For example, suppose your network is relatively small and one person needs access to a database. Now, suppose that you grant access to this one user. As time goes on, maybe a couple of other users need access to the database, so you give them access. As the years go on and your company and network grow, you may realize that a lot of people need access to your database, so you create a group and add them to the group. At that time, you must remember which users you granted individual permissions to, remove the individual permissions, and make those users members of the database group. As you can see, it can be much more work in the long run to set individual permissions than it is to simply create a group to start with.
Another advantage to only using groups is that as your LAN support staff grows or changes, it's easier for new people to know who has access to what. For example, suppose you wanted to know what a certain user has access to. User Manager For Domains won't display individual file permissions for each user, but it will show you which group or groups the user belongs to. As you can see in Figure C, it's quite easy to see at a glance exactly what a user has access to.
Types of groups
As you're probably aware, Windows NT maintains two sets of user accounts. For example, you have a local Administrator account that you can use to configure or add software to an individual workstation. Likewise, there's a domain Administrator account that's used to manage domain resources. Just as there are two different types of accounts, there are two different types of groups: global groups and local groups.
Global groups include the groups built into Windows NT domain controllers. They also include other groups that you create on domain controllers. Local groups are specific to Windows NT Workstation and to Windows NT member servers.
Setting group permissions
Obviously, the type of group you'll create depends on the location of the resource you're trying to grant permissions to. For example, if you need to grant access to a directory that resides on a domain controller, you can create a global group. You can then assign permissions to any domain user.
However, you may wonder what to do if the resource you need to regulate resides on a member server or on a workstation. Although you could create a local group for the resource, most users won't have a local account on the machine—and even if they did, they wouldn't be able to access that local account across the network.
Fortunately, there's a solution to this situation. Local groups can contain more than just local users. A local group may contain local users, domain users, global groups, and global groups from trusted domains. With that said, you can see how you can easily add the domain users to the local group and give the group access to the resource in question. However, doing so isn't usually the best solution to this problem.
A better solution is to create a global group designed to contain domain users who need access to the resource. You can then create a local group with access to the resource and make the global group a member of the local group. Although this process may sound complicated, you do things this way for ease of management. For example, suppose that the server containing the resource in question is on the other side of the building (or on the other side of the world). If you merely create a local group on the server and add domain users to the group, you have to physically go to that server any time you want to add or remove users from the group. But if the only local group member is a global group, you can add and remove users from the global group. Because of the nature of global groups, you can do this from anywhere—you never require physical access to the machine containing the resource.
What if you got this information too late?
If you inherited a network from someone else, or you weren't completely educated when you set up your network, there's a good chance that you may have a mixture of share and file permissions with resources assigned to groups and users. If this is the case, or if you're interested in gradually reorganizing your network in the manner that we've described, you may be interested in the side effects caused by mixed permissions.
Setting file permissions to a resource and then creating a share permission to the same resource can cause contradictory permissions. They can also be caused by assigning users access to a resource and then making them members of a group with permissions to the same resource. Finally, you could have overlapping permissions when a user is a member of two different groups with access to the same resource.
When a user has contradictory permissions, Windows NT always uses the most restrictive permission. For example, suppose a user is a member of one group that has read-only access to a resource and is a member of another group that has full control over the same resource. Since read-only is the more restrictive permission, that permission would apply. You should also keep in mind in such situations that a specific denial (assigning the No Access permission) overrides any other permissions you might have given the user. For example, suppose a user is a member of a group with full control to a resource and is a member of another group that's been given the No Access permission to the same resource. In such a situation, the user won't be able to access the resource, because No Access overrides Full Control.
In this article, we've discussed some techniques you can use to avoid unnecessary complications when setting Windows NT permissions. Although there's technically no right or wrong way to grant permissions, following these methods will help you to avoid overlapping permissions and unexpected side effects.
Brien M. Posey is an MCSE and a freelance technical writer. He also works as a network engineer for the Department of Defense. You can contact him via e-mail at Brien_Posey@xpressions.com. (Because of the large volume of e-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)
We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.