Network Administration / Windows 2000 Server
Group policies in Windows 2000 facilitate and provide a means for managing both change control and distributed security. They enable you as a system administrator to enforce restrictions that can prevent system changes and the resulting chaos that could ensue. This article provides an overview of group policies and what they can do for you.
Before you start learning about group policies, you need to first understand why you need to learn about group policies and what they provide your organization. As mentioned, group policies target two primary, intertwined issues: change control and security. Change control refers to the ability to control changes to the operating system—whether major or minor—that can have an impact on system stability, functionality, and security. For example, group policies enable you to extend change control over the following:
All of these items hold consequences for both workstations and servers—change control is not an issue just for servers. In fact, properly maintained and secured severs can be less susceptible to change given that they are often secured (or should be) behind locked doors. Because they are not isolated from the network, however, servers are just as vulnerable through the network.
Let's take a look at some examples where change control could have saved the day to illustrate how important the issue is for both workstations and servers.
Scenario 1
A bookkeeper who considers herself a power user is constantly tweaking her system. The fax machine is located in another office, and she wants fax capability through her fax modem. So, she enables the fax service and in the process, accidentally changes other settings that prevent her modem from working properly with her key reporting application. Her reporting application program—unfortunately poorly designed—crashes and takes the last month's data with it.
Although the bookkeeper has faithfully backed up each day, an unrelated and unexpected problem with the tape backup system prevents her from restoring the data. Customers are lost, sales are lost, and fines are imposed because of late reporting...all because the user wasn't prevented from making a simple change to the system.
Scenario 2
A junior network administrator is working on Saturday to perform some routine maintenance that includes archiving several folders on the primary server, which hosts the company's Web site and mail, to tape. While the backup is in process, the administrator gets bored and starts exploring the server. He launches the IIS console and without realizing it, stops an auxiliary site that provides support services. Moving on to the Exchange Server console, the administrator does a little more damage, disabling mail for a handful of users—but more importantly, he stops the store, effectively shutting down the mail server.
Clients can't download patches or check the status of support issues until Monday when the services are restored. The support staff is flooded with mail from hot customers who couldn't connect or even send a support request because the mail server was down. The company loses one junior administrator, and their status drops a few notches in the eyes of their customers.
Scenario 3
Over the weekend, the company president of a small publishing company installs some shareware that he downloaded from the Internet onto his notebook. The shareware contains a Trojan horse virus that disables his anti-virus software to prevent its detection.
Monday morning he connects his system to his docking station, and the virus spreads to the network, rapidly infecting all systems and servers and effectively shutting the business down for three days while they bring in outside help to repair the problems. The production staff loses three days, can't complete their projects, and misses several publication deadlines, resulting in lost ad revenue and lost customers.
Each of these problems stems from personnel who are poorly trained, careless, or don't follow established procedures. There is still the possibility for accidents, even with the most conscientious and careful users and administrators. Compounding the potential problems, most users don't understand the possible implications of the changes they make. As if that isn't enough, not all organizations develop change control policies, much less enforce them.
Imposing change control would have prevented all of these potentially catastrophic problems. The old adage that an ounce of prevention is worth a pound of cure was never truer. And, these examples illustrate that no one should be above company policies or outside the change control envelope, regardless of their position in the organization.
To apply change control effectively, you first need to understand your users and the types of tasks they need to perform. With that understanding in mind, you can accommodate their application and operating system needs while still imposing adequate security to protect their systems and the network.
First, classify the users based on the types of tasks they need to perform and the applications they use to accomplish those tasks.
In addition to classifying users by their job area, you should also take a look at the types of systems they use. These include:
Why is an understanding of how each user works and the types of systems they use important to applying change control? Classifying users by their job area will help you begin to develop change policies based on job function, security levels, applications required, and so on, and translate job classifications into domain security groups. Getting a handle on the big picture will help you develop and implement policies that allow users enough latitude to do their jobs effectively and efficiently without exposing their systems and the network to compromise.
If you're working strictly in a workgroup environment without domain security, you can still use this knowledge to plan local security policies for each computer. In addition, understanding the types of systems each user or group uses will help you identify potential security risks associated with specific types of systems.
For example, if most of your workstations are diskless Terminal Services clients without Internet connectivity, you don't have to worry much about users introducing unauthorized applications through download. Systems with modems or direct Internet access, or remote systems over which you have little control, are a different story.
In addition to understanding users' responsibilities and the systems they use, you also need to become familiar with the applications they use. This doesn't mean you need to become an expert at using the application and become capable of answering any question about it (although your users no doubt expect that from you). Instead, you need to understand their applications in the context of how changes that the users are allowed to make can impact those applications, what changes they need to be able to make because of the applications, and how to recover their applications and data if they manage to drive through some loophole you've overlooked.
Finally, make sure you develop an adequate recovery strategy to accommodate problems when they do occur. Perhaps the best way to do this is to plan for the scenario that group policies don't exist, put in place recovery strategies to deal with the possibilities engendered by rampant changes, and then apply change restrictions to prevent all of those possibilities from occurring. In other words, plan for the worst and design for the best.
Group policies enable you to control a wide range of capabilities and actions. Which ones you address depend on your situation and how they impact your users and systems. The following list summarizes the key issues to address:
In addition to the types of change control described above, you'll find that as you become comfortable with group policies they will play an increasingly important role in how you administer your network. You'll use group policies not only to apply change control at the workstation and server level but also to apply granular security and distributed administration to such services as DNS and DHCP, control application installation and deployment, and much more.
Some of the functions and benefits of group policies are easy to see, while others might take you by surprise. For example, you've no doubt surmised by this point that group policies let you enforce change control over a wide variety of items. You can, however, also use group policies to redirect folders, manage Internet Explorer settings, apply logon and logoff scripts, and much more. The following list summarizes key features and functionality offered by group policies:
Before you start defining and implementing group policies, take the time to analyze your network, systems, users, and groups to determine how best to use group policies. Take into account the previous discussion and decide how users should be grouped for the most effective policy application, which groups can accomplish which tasks, what restrictions need to be in place, and so on. You don't need a final picture at this point, just a good overall understanding so you can begin to develop your implementation and application of group policies.
Do you want to write feature articles, tutorials or stories on industry trends? In addition to publishing opportunities available on our website, you get your name in front of thousand individual readers that access our site every day.
Our Partners