Developer

Get IT Done: Preparing to use Windows 2000 group policies

A guide to preparing Windows 2000 group policies


Change control and distributed security are two issues that affect not only large organizations but also small ones. In some respects, they can be even more important in a small organization than in a larger one. If you allow a key employee to change settings at will, the result could be a toasted system when it’s needed most. In a larger organization, the chances are better that you have a backup system on hand or an administrator readily available to save the day. In a small organization, it’s likely that neither is the case.

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 Daily Drill Down is the first of several articles that examine Windows 2000 Group Policies in detail, starting with an overview of what group policies can do for you and why you need them.

The importance of change control and security
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:
  • Hardware configuration
  • Client environment configuration (desktop settings and working environment, logon settings, and so on)
  • Operating system options (optional applications and features)
  • Applications
  • Security settings and policies
  • Connectivity and access to network resources

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.

The moral to these stories
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.

Understanding your users
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.
  • Knowledge workers: These users are typically more skilled than other users in their respective job areas and might be engineers, accountants, designers, developers, and so on. The fact that they are skilled in a particular area doesn’t necessarily equate to computer skill, however. These users typically work from a single computer and work with it most of the day.
  • Support staff: These users support the efforts of the business in a task-oriented way. They include data entry clerks, order takers, receptionists, assistants, shipping clerks, and so on. While some work from the same computer all day, others might work with one or more computers. Again, skill level in their area of job responsibility doesn’t equate to computer experience or skill level. These users run the gamut from novice to advanced users.
  • Technical: These are your system administrators and support staff. They typically work from several systems a day, but each probably has his or her own system, whether workstation or notebook. While they have a much higher computer skill level, they also have a higher risk factor because they typically have more latitude and knowledge to make changes.
  • Management: The company president, vice president, and other such executive staff fall into this category. They often work from notebook systems because they are more often on the go, presenting additional risk for introducing applications and changes to the network.

In addition to classifying users by their job area, you should also take a look at the types of systems they use. These include:
  • Fixed workstations. These users work from the same workstation all the time and do not need to take their work with them.
  • Remote workstations. These users connect to the office network through a dial-up or VPN connection but don’t need a notebook because they work from home or the remote office all the time.
  • Notebooks and docking stations. These users work both in and out of the office and need to take their systems with them.
  • Multiuser workstations. These users move from one workstation to another as needed and often don’t have their own user account, but instead use a guest account or whatever account is used to log on to the particular workstation.
  • Mobile computers. These users work with a notebook computer without a docking station and typically connect to the network via a dial-up connection or remote office.

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.

What to control
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:
  • Hardware changes: You can use change control to prevent users from changing existing hardware settings such as display resolution, drive settings, and so on. You can prevent them from changing drivers or installing additional drivers, which helps protect against systems going down because of faulty drivers.
  • Application installation and changes: Use change control to prevent users from installing applications or changing existing installations. This helps control problems caused by buggy applications and/or viruses and Trojan horses introduced through shareware or freeware (and not unheard of, but less common with, commercial applications).
  • Security needs: Use change control to define whether users can use encryption, IPSec, and other security features. This partly helps keep users out of trouble and helps protect against such situations as a user encrypting his or her documents and then leaving the company after deleting his/her certificates. Although you can recover the encrypted data, it can be a protracted process and at best, an annoyance.
  • Network requirements and settings: Prevent users from making changes to their network settings or installing additional network clients or services.
  • Access to services: Control users’ ability to access and add, remove, change, or control services.
  • Local and network resource access: Define the actions that users can take in connecting to and using local and network resources.
  • Environment settings: You can employ change control over a wide variety of settings that control the user’s working environment including the desktop, mapped drives, printers, and so on. Group policies give you an exceptional level of control over the user’s environment and therefore the types of tasks the user can and can’t perform.

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:
  • Group Policy Object (GPO) can be stored in the Active Directory or defined as a local policy object. In most cases, policies defined at the site, domain, or Organizational Unit (OU) level override local settings.
  • GPOs support security, enabling you to assign permissions to each GPO to provide not only change control over the policy object but also delegate administration of GPOs.
  • You can use security group membership to apply GPOs, providing an easy way to apply policies across the enterprise while offering simplified administration.
  • GPOs provide a high degree over security settings, serving as the primary means by which you apply security policies across Windows 2000 networks.
  • GPOs enable you to control Internet Explorer settings to control security zones and other security- and performance-related issues.
  • GPOs enable you to apply logon, logoff, startup, and shutdown scripts.
  • You can use GPOs for folder redirection, such as defining the user’s My Documents folder as being located on a network server for roaming access or to ensure backup of the user’s documents.

Conclusion
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. In upcoming Daily Drill Downs, I’ll show you how group policies work and how to implement them in your organization.
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.

Editor's Picks

Free Newsletters, In your Inbox