Default Groups and Administrative Security
So far in this series, I've introduced you to the various types of groups in Windows 2000 and shown you some techniques that you can use to enhance your organization's security by nesting those groups. However, I haven't yet discussed one type of group. Like Windows NT, Windows 2000 has many built-in groups designed for special purposes. In this article, I'll introduce you to those groups and show you how to get the most out of using them.
Windows 2000 Default Groups
If you're a Windows NT veteran, you may recall that Windows NT has a few built-in groups, such as the Users group or the Administrators group. However, Windows 2000 contains more built-in groups than Windows NTin fact, there are so many that the groups are divided into categories. These categories are called predefined groups, built-in groups, built-in local groups, and special identity groups. Each type of default group that I just mentioned has its own specific purpose. As with Windows NT, the individual groups within each group type regulate the tasks that group members can perform. In the sections that follow, I'll explain the purposes of each type of group.
Predefined groups are nothing more than global groups. You can control who has access to what by adding these predefined groups to domain local groups or by adding permissions directly to these groups. The predefined groups include Domain Admins, Domain Guests, Domain Users, and Enterprise Admins.
Built-in groups give group members the authority to perform specific tasks at the domain level. For example, Account Operators can create, delete, and modify user accounts within the domain. Most of the built-in groups closely match groups found in Windows NT. The built-in groups include Account Operators, Administrators, Backup Operators, Guests, Pre-Windows 2000 Compatible Access, Print Operators, Replicator, Server Operators, and Users.
Built-In Local Groups
Built-in local groups are located only on stand-alone servers, member servers, and Windows 2000 Professional workstations. They allow users of the machine to perform specific system-related tasks, such as backing up the system. The built-in local groups function very similarly--if not identically--to their Windows NT counterparts. As with Windows NT, most of the built-in local groups are empty by default. It's up to the local administrator to assign group memberships. The built-in local groups include Administrators, Backup Operators, Guests, Power Users, Replicators, and Users.
Special Identity Groups
Special identity groups deserve a little more explanation than the groups I've already discussed. Unlike other groups, you can't add users to or remove users from special identity groups. Instead, special identity groups represent different users at different times. In fact, you can't even see the special identity groups when you're administering groups. The only time you'll ever see them is when you assign permissions to resources. The following list describes some of the special identity groups and their functions:
- Anonymous LoginIncludes any user who is using Windows 2000 resources but didn't go through the authentication process.
- Authenticated UserIncludes all users who are authenticated into the network by using a valid user account. When assigning permissions, you can use the Authenticated User group in place of the Everyone group to prevent anonymous access to resources.
- Creator OwnerRefers to the user who created or took ownership of the resource to which you're assigning permissions. For example, if the User Brien created a resource, but the Administrator took ownership of it, then the Creator Owner would be the Administrator.
- Dial-upIncludes anyone who's currently connected to the network through a dial-up connection.
- EveryoneIncludes all users who access the system. As I mentioned earlier, be careful about assigning resources to Everyone, because you could accidentally allow unauthenticated users to access the system. One way of reducing this problem is to disable the Guest account. Remember that the Guest is a part of Everyone; and in some cases, Windows 2000 represents anonymous users as a guest.
- InteractiveRefers to users who are logged on to a local machine. As you may recall, users who are logged in locally are said to be logged in interactively. Therefore, if you want to restrict a resource so that it can only be accessed locally, this is the resource to use. Likewise, you can make a resource available only through the network by applying a denial to the Interactive group.
- NetworkThe exact opposite of the Interactive group; includes any users who are accessing a given machine from another computer. Remember that just because users are on the network, they aren't necessarily members of the Network group. The Network group is specific to each machine. Therefore, a user isn't a member of a machine's Network group unless he is currently accessing resources on that machine.
After reading the first part of this article, you might assume that because you're an administrator, that you should usually be logged in as Administrator or as a member of the Administrators group. However, nothing could be further from the truth. Logging on as the Administrator or as a member of the Administrators group opens your network to certain security risks. For example, how many times have you become distracted by an urgent phone call or a visit from a friend and accidentally walked away from your desk with your PC still logged on? Not only does accidentally staying logged in contribute to security risks, but viruses can do much more damage to a machine if the user who's logged in has administrative privileges.
Like myself, you're probably not in the habit of installing viruses, but consider this situation: Imagine searching the Web for technical support information on a minor network problem. Now, suppose that your search takes you to a site you've never heard of. Nothing is stopping that unfamiliar site from running a script designed to format your hard disk or steal passwords. If you're logged in to the system as an administrator, the script will usually have no problem unleashing whatever mayhem it was designed for. However, if you're logged in as someone with lower privileges, the script probably won't be able to complete because of insufficient permissions.
That theory sounds good on paper, but let's face itit's a bit unrealistic to think that you'll be able to get through even a single day without needing those administrative privileges. Fortunately, there's a solution: I recommend setting yourself up with a common user account and making that account a member of the Users group or the Power Users group. Remember that if you're a member of the Users group, you'll be able to run programs and browse the Web. If you belong to the Power Users group, you'll be able to run programs, browse the Web, and use many of the Control Panel applets to do things like install printers or install programs.
Security for Administrators
Using the RunAs Command
Unless you plan to engage in a very long administrative session, I recommend using the RunAs command for tasks that require administrative privileges. The RunAs command allows you to run a task as if you were logged in as an administrator. However, the administrative privileges apply only to that single task. All other processes still limit you to your original permissions.
You can access the RunAs command two ways: from the command line or through the GUI. You'll have to use several switches with the RunAs command, so enter RUNAS /? to see a summary of the command's syntax if you want to use the command-line method.
To access the RunAs command through the GUI, navigate to the menu item or shortcut you want to run. Next, hold down the Shift key and right-click to open the program's context menu. Select RunAs, and you'll be prompted for a login name, password, and domain name. Once you've entered this information, you're in business. It's important to point out that simply right-clicking on a shortcut isn't good enough in this caseunless you're holding down the Shift key, Windows 2000 hides the RunAs command from the context menu.
As you can see, using the RunAs command can greatly increase your network's security. However, your network's security can also benefit from using the other techniques -- such as group nesting -- that I've discussed in this series of articles. If after reading this series you decide to implement group-based security, remember that proper planning and use of the various types of groups goes a long way to preventing permissions overlaps and other potential security problems. //
Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.