Security is an essential part of just about every network, and part of having good security involves knowing what security features are available to you and understanding the recommended procedures for using those features. In this Daily Drill Down, I’ll discuss some of the basic Windows NT security features, and I’ll outline the recommended procedures for getting the most out of the various security settings.
The basic unit of Windows NT security is the user account. You can apply all sorts of different permissions and restrictions to the user account. The primary tool for managing user accounts is the User Manager For Domains, which is accessible through Start | Programs | Administrative Tools (Common).
Before you read any further, you should know that, to manage domain security, you must be logged in as an administrator or as an account operator. You also should be logged into the domain that you plan to manage. On any given networked Windows NT computer that’s part of a domain (except for domain controllers), there are two different Administrator accounts. One account manages the local machine; the other account manages the domain. You can choose either account by selecting the domain name or the local computer’s name from the Domain field at login.
Once you’ve signed in as an administrator and you’ve opened the User Manager For Domains, you’ll see a list of user accounts that are currently set up on the domain. You can either create a new user account by selecting the New User command from the User menu, or you can edit an existing account by double-clicking it. When you double-click an account or create a new account, the first thing that you’ll see is the user’s properties sheet. This sheet contains the user’s name and description. More importantly, this sheet allows you to change the password and to set the current state of the password and the account. For example, you can force the user to change the password, you can prevent the password from expiring, or you can disable the account altogether.
Below the basic user fields are some other buttons. You can use these buttons to set other security options, such as group memberships, user profiles, the hours when a user is allowed to login, which workstations the user is allowed to login from, and the type and expiration date of the user’s account. The last button lets you decide whether or not the user will be allowed to dial in.
Although these properties can be set for individual users, there are also blanket policies that apply to all users. For example, if you select the Account command from the User Manager For Domain’s Policies menu, you’ll see the Account Policy dialog box. This dialog box allows you to set many factors, including the frequency with which passwords expire, minimum password length, password history, and account lockout policies.
File permissions vs. share permissions
Now that you understand a little bit about how the User Manager For Domains works, it’s time to talk about assigning resources to users. Basically, User Manager for Domains is responsible for setting the policies that allow a user to login. Assigning resources is done elsewhere.
Before I begin discussing the various methods of granting permissions to resources, however, I should point out that Windows NT has two basic methods of granting access to files: through file permissions and through share permissions. When you access a file or directory on a Windows NT Server from across a network, you do so by attaching to a share point on that server. Share permissions involve setting policies that determine who can access a particular share and which types of access different users have.
You can control access to a share point by right-clicking a shared directory and selecting the Properties command from the resulting context menu. When you see the share’s properties sheet, select the Share tab, which contains the name of the share, a field that allows you to list the purpose of the share, a field that lets you limit the number of users who can access the share, and a Permissions button. If you click Permissions, you’ll see that, by default, the group Everyone has full control to the share point. You can use the Remove button to remove the rights for Everyone, or you can use the Type Of Access drop-down menu to give Everyone a more restrictive permission, such as Read, Change, or No Access. You can use the Add button to grant access to the share to any user or group.
Share permissions work well, but they have certain limitations. For example, they offer absolutely no protection if a user is logged on directly to the server because the user is accessing the files directly instead of passing through a network share point. Another drawback is that you can get into some really tricky security issues if you create one share point for a directory and a separate share point for a subdirectory of the original directory. To get around these issues, you should assign file permissions instead of share permissions. File permissions apply to individual files and directories rather than to share points. In effect, the permissions don’t care from which location the user is logging in. File permissions eliminate most problems that result from overlapping permissions.
To establish a set of file permissions, you must use the NTFS file system to format the volume that contains the files or directories. Once a volume is formatted as NTFS, you’re free to set all of the file permissions that you want. Begin by selecting and right-clicking the directory or files to which you want to apply the permissions. Next, choose the Properties command from the resulting context menu. When you see the object’s properties sheet, select the Security tab. Now, click the Permissions button. You’ll see a dialog box that looks a lot like the one that was used for setting share permissions. This dialog box functions almost identically to the one that controls share permissions—except for the fact that it’s applying the permissions at the file level. You can replace permissions on subdirectories or on existing files by checking the corresponding boxes.
Before you can set up your server’s security, you must understand the concept of groups. A group is nothing more than a collection of users. Usually, these users are grouped together because they share a common set of permissions. For example, I’ve already mentioned that Everyone has full control of a share by default. Everyone is a group that’s built into Windows NT. It contains each of the individual users on the domain. You might create other groups, too, such as a group for the employees in the marketing department or for the employees in the finance department.
There are two basic types of groups: global groups and local groups. A global group is available anywhere on the domain, while a local group is available only on a specific server or workstation. A local group may contain global groups, but a global group can’t contain a local group. You can create a new group by selecting either the New Global Group or the New Local Group command from the User menu in User Manager For Domains. User Manager For Domains can also establish which users are members of a given group.
Obviously, global groups and local groups have different purposes. Assume for a moment that your network has multiple servers, each using file permissions. Now, suppose that some resources need to be available to members of the marketing department, other resources need to be available to members of the finance department, and still other resources need to be available to members of both departments. One way to handle such a situation would be to create a global group for marketing and a global group for finance. Then, on the server, you could create local groups for specific resources. These local groups might contain names like Budget, Proposals, and HRForms. You could assign the Finance global group to the Budget local group, the Marketing global group to the Proposals local group, and both global groups to the HRForms local group. Although this procedure may sound like overkill, it’s a good technique to use. As your network grows, using this technique will make it easier to manage. A network that’s easy to manage and that’s very consistent in structure tends to be secure because the chances of accidentally overlooking a critical permission are slim to none.
Putting it all together
So far, I’ve discussed setting up users and groups, and I’ve discussed the difference between share permissions and file permissions. As you can tell, Windows NT gives you a lot to work with in the way of security. Surprisingly, these are only a few of the most basic security options that Windows NT offers. With so many options to choose from, you may be confused about what to use. Don’t worry, though. I’ll offer some guidelines that will help you out.
Although you can never really avoid using shares on your server, I recommend that you keep the default share permissions so that Everyone has full control. Then, you can set the more restrictive permissions at the file level. This method keeps your data more secure. From an administrative standpoint, this method also makes it easier to have one type of permission—instead of mixing file and share permissions and never really knowing which permission applies to any given resource.
When you grant permissions at the file level, you should only grant permissions to groups, never to individuals. That way, you’ll make managing everything much easier. For example, suppose that your company has a marketing department and a finance department. Let’s say that the marketing department has 47 directories, which its members must be able to access, and the finance department has 51 directories. Now, imagine that you’ve assigned rights to individual users. If a user moved from marketing to finance, you’d have to track down and remove 47 separate permissions to marketing directories for that user. Then, you’d have to assign 51 permissions to the various finance directories manually. If you had used groups instead, you could have deleted the user from the marketing group and then added the user to the finance group. The entire process would have taken about twenty seconds—not half of the afternoon.
I also recommend that you assign permissions only to local groups. If your local groups contain only global groups, it will be easy for you to determine who has access to any given resource. For example, if you need to know who has access to the HRForms directory, you’ll know that the only permissions of the HRForms directories are assigned to the HRForms local group. If you look at the HRForms local group, you’ll be able to tell instantly which global groups are assigned to it.
These techniques may seem tedious to set up initially. As your network grows, however, using the techniques that I’ve described will pay off eventually. They save you a lot of time as you manage the network, and they will provide you with a very clear view of your network’s security structure. These techniques also will eliminate most of the security loopholes that overlapping permissions cause.
Brien M. Posey is an MCSE who works as a freelance technical writer and as a network engineer for the Department of Defense. If you’d like to contact Brien, send him an e-mail. (Because of the large volume of e-mail he receives, it’s impossible for him to respond to every message. However, he does read them all.)
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.