http://www.mcpmag.com/members/current/col3body.asp
Practical Policies
System policies allow you to focus on productivity and streamline downtime
on your network. This guide shares the basics.
Today isn’t your usual NT administration day. In addition to upgrading
hardware and software, and managing users, you’ve just learned that Bob,
everyone’s favorite hack, has distributed a polar bear screensaver that
whacks your Windows NT, 98, and 95 machines. If only you’d implemented
system policies before that polar bear—or Bob—invaded your network.
Some Basics
System policies are rules that control what users are allowed to do on
Windows machines. Because policies are based on registry templates , you
have complete control over everything from the Display applet to what
programs users are allowed to run. You can literally lock your network
down tighter than a rusted screw.
Profiles are an excellent way to control how users’ environments look and
feel (see “Profiles vs. Policies”). However, policies are the way to
control what users are allowed to do. For policies to work with Windows 95
and 98, profiles must be enabled through the Passwords applet in Control
Panel. Profiles are enabled by default in Windows NT.
In this article:
* Exclusively Online: Get Your Hands Dirty with
System Policies
* Profiles vs. Policies
* Exclusively Online: "A Brief Nightmare"
Policies can also manage some profile-like settings. You can assign screen
colors, wallpaper, and custom icons for your users. In addition, you can
create custom program folders, start-up folders, and entire start menus
for your users, and then take away their privilege to change any of it.
If your network is like most networks throughout the world, you’ve got a
collage of different operating systems. NT Workstation 4.0, Windows 95,
and its successor, Windows 98, all have unique registries and, therefore,
their own unique templates and policy editors. You can’t create a policy
for NT with the Windows 95 System Policy Editor and vice versa. The
mechanics of the policy editors are basically the same; however, the
differences warrant a brief discussion.
Figure 1. When a policy is first created in NT’s System Policy Editor,
there are two icons: default computer and default user. Changes made to
these default accounts affect all users and computers.
Windows 95 and 98’s System Policy Editor, if it has been installed, is
found in the System Tools folder under Accessories. If it hasn’t been
installed, you’ll need to add it through Control Panel’s Add-Remove
Programs applet. Also, each Windows machine requires group policy support
to use group policies. You can add group policy support through the
Add-Remove Programs applet as well.
Windows 95 and 98 policies can be stored locally or on a server. The
default value is that the policy file is stored on a server, either the
PDC’s Netlogon share or on a NetWare server in the Sys\public directory.
To create a local policy, you’d need to update the local computer
account’s Network\Remote Update section through the policy editor to
reflect that the policy is local instead of on a server.
Be certain to enable load balancing on the default computer’s network
section; otherwise, all 95 and 98 machines will only accept their policy
from the Primary Domain Controller (PDC), even if a Backup Domain
Controller (BDC) has validated their logon request.
Figure 2. The Group Priority dialog allows you to designate how settings
will be decided when they conflict for a user who belongs to multiple
groups.
Neither Windows 95 nor 98 requires a user to logon to the system—a simple
Esc key clears the logon dialog box. With this in mind, policies saved on
a remote server can be ignored by not logging onto the network. Because NT
requires a logon to use the machine, policies will always be enforced on
Windows NT.
NT’s System Policy Editor is accessed through Programs\Administrative
Tools. If the System Policy Editor hasn’t been installed, run the
SETUP.BAT file from the NT Server CD-ROM’s clients\svrtools\winnt
directory.
The Template Approach
Because each operating system has an entirely different registry and
policies are nothing more than cookie cutters of the registry, each OS
will require its own policy editor to create effective policies for users
of those machines. If you’re participating in a domain environment,
however, save each policy file in the Netlogon share on your PDC, which is
%systemroot%\system32\Repl\import\scripts.
Name the Windows NT policy file Ntconfig.pol and the Windows 95 or 98
policy file config.pol. The policy file is based on a template of the
registry. The template exposes variables of the registry and allows you to
configure these settings for each user, group, or computer included within
the policy file.
By default, the Windows NT policy editor loads the templates WINNT.ADM and
COMMON.ADM. These cover the major components of the registry for Windows
NT. If you need to create some obscure setting not included within these
templates, you can create your own.
Figure 3. The “Triangle of Terror” gives you a simple mechanism for
visualizing how a user’s settings will override each other.
To create a policy, open the System Policy Editor. On the Registry menu,
select New. Two icons, Default computer and Default user, represent a
default policy file. Changes made to these default accounts affect all
users and computers, so, as a rule, only make general changes to these
accounts. If you decide to make some very broad, sweeping policies based
on these accounts, be certain to add the Domain Admins group with a policy
that unlocks all of the features you’re applying on the default user
account; otherwise, whatever policy you make will affect the
Administrator account as well.
To create specific policies, add one of three types of accounts: user,
group, or computer. A user account determines explicit settings for an
individual user, such as Bob and his screensavers. A group account would
control settings for a group of users, such as the salesreps. A computer
account is ideal for a computer used by many different individuals
throughout the day, such as a computer on a manufacturer’s shop floor or
in a library setting. No matter who logs onto the computer, be it the CEO
or the janitor, the computer policy makes the machine look and act the
same for each individual.
When you’ve created a computer policy, be aware that the first time you
logon from a machine specified with a computer policy you won’t see the
policy enforced; this is because you have just downloaded the policy to
the local registry. The next time you log onto to this computer, the
policy will be enforced because the settings are now in place in the
registry.
Exclusively Online: Get Your Hands Dirty with System Policies
If you’d like to get your hands dirty and create some system policies
go with this article, you’ll need the following ingredients:
* 1 Windows NT server acting as a domain controller.
* Administrative rights in the domain.
* 1 or 2 NT Workstation PCs configured to log onto the domain
* A share on the PDC called Accounts with read rights for Users.
1. Inside the shared folder, accounts create the following subfolders:
Sales, Executives, Finance, Marketing, Developers, and Managers.
2. Add a different bitmap image in each of the subfolders created
above. These bitmaps will become the wallpaper for users in these groups.
3. Add three or four shortcuts to the subfolders created above.
4. The shortcuts will serve as each group’s start menu.
* The following user accounts: Bob, Sally, Jane, Sarah, Mike,
Tom, Bill, Laura, Henry, and Rosemary.
* The following global groups with these users as members:
+ Sales—Bob, Sally, Jane
+ Executives—Julie, Mike, Sarah
+ Finance—Bill, Henry, Laura
+ Marketing—Mike, Sarah, Tom
+ Developers—Bob, Rosemary, Sally
+ Managers—Henry, Jane, Rosemary, Sarah
1. Log onto your domain controller as Administrator and open the System
Policy Editor.
2. Click on the new policy file button to begin the policy creation.
3. Click on the add group button and add the Sales, Executives, Finance,
Marketing, Developers, and Managers groups to your policy file.
4. Set the following variables for each group:
[see original article for full table]
5. From the Options menu choose group priority. Arrange the groups in
this order, top to bottom:
* Managers
* Executives
* Sales
* Finance
* Marketing
* Developers
6. Save the policy file as NTCONFIG.POL in the
%systemroot%\system32\repl\import\scripts directory.
7. Log onto your NT Workstation as each user and test their policies.
—Joseph Phillips
Policy Priorities
Group policies affect all users within a given group, for instance, the
Sales group. But what if a user is a member of more than one group where
different policies exist for each—or even multiple groups like Staff,
Sales, Accountants, and Managers?
Within the System Policy Editor it’s imperative that you designate the
group priority from the options menu. Group priority determines in what
order group policy settings are processed. (See Figure 2.) The groups
highest in the list will override settings for groups lower in this list.
For instance, we could create a policy in which the Sales group couldn’t
change the screensaver, whereas the Managers group could. In our group
processing order we list Managers at the top of the list and then Sales.
Jane, the Sales Manager, is a member of both groups. Jane would be able to
change the screensaver because the Managers group allows her to make that
simple change.
Figure 4. In the creation of policies, note the three switches. A gray box
means to ignore the setting for this account; a check box means to enforce
it; and a clear box means to remove it from the registry settings
altogether.
Albeit, that was an easy comparison; but imagine an environment where
users are members of multiple groups. You would have to create what I call
in my NT classes, “the Triangle of Terror.”
Here’s how it works: Imagine a triangle. At the top, situate the group
that has the most access to events, or the least restrictive policy. Next,
list the group with the second amount of freedom, and so on down this
pyramid. If you’ve done this successfully, after some trial and error,
you’ll have discovered your processing order. Members of groups at the top
of this list will override settings if they’re also members of groups
lower in the list. This will always work, even if a user is a member of
20 different groups within your policy file.
Profiles vs. Policies
At first glance, policies are easy to confuse with user profiles. Profiles
contain all user-specific settings, such as shortcuts, desktop items,
colors, and even the start menu. In Windows NT, profile settings are
stored in NTUSER.DAT, while Windows 98 and 95 store their user profiles in
USER.DAT. When a user logs onto the machine, his or her profile is loaded
into the user portion of the registry.
There are three types of profiles: local, roaming, and mandatory.
Local profiles, as the name implies, are stored locally on the computer.
Windows 95 and 98 save their profiles in the windows\profiles directory,
while NT saves its profiles in the %systemroot%\system32\profiles
directory.
Roaming profiles are identified through User Manager for Domains on the
profile tab for each user account. To use roaming profiles, create a
network share—typically the Profiles directory—and then on the profile
button for each user account identify the profile path as the UNC name
with the %username% switch. For example, if you shared out the profile
directory on a server called Bach, your UNC profile path for each user
would be:
\\Bach\profiles\%username%
The %username% switch creates a folder with that user’s name. Windows 95
and 98 machines store their roaming profiles in each user’s home folder.
Roaming profiles are updated at the server each time a user logs off the
network. As the user logs onto various computers, the profile is
downloaded to each machine and the desktop is built. Each time the user
logs off the network, the roaming profile is updated to the server based
on a time stamp.
A problem with roaming profiles is that a user could log onto a machine
that’s configured with the wrong time. When that user logs off of the
machine, the changes made to his or her profile could be discarded because
the time of the machine he or she logged onto was older than the timestamp
currently on the roaming profile at the server.
To eliminate this problem, create a time server, typically the server that
stores the roaming profiles, by including this line in your users’ logon
scripts:
net time \\timeserver /set /yes
Now when your users log onto the domain, their machines will always be in
sync with the server’s time.
Mandatory profiles require users to use the default values in the profile
created for them. Mandatory profiles don’t prohibit users from making
changes to the profile while they’re logged on, such as deleting icons; it
only refuses to save the changes made by the users.
Many companies use mandatory profiles to cut down on troubleshooting calls
such as, “I just deleted all the shortcuts on my desktop. Now what?” With
mandatory profiles, the caller could just log out and log back on.
To create a mandatory profile for a group of users—for example, the global
Sales group—log on as a Sales user and create the profile as it should be
for all Sales users. Next, as an Administrator, through the System applet,
copy the profile to a central, shared folder and give the Sales group
permission to use the profile. Select the Sales accounts through User
Manager for Domains and identify their account to use the profile you
created and shared out in the centralized folder. Finally, change the
NTUSER.DAT file to NTUSER.MAN so sales reps can’t make changes to the
profile you’ve created.
—Joseph Phillips
One Against the Many
In most environments, you’ll want to work with group policies instead of
user policies. After all, who wants to edit each individual user’s policy?
However, there will be those pesky people, like Bob, our favorite hack,
who require a little extra attention. For those folks we’ll create
individual user policies. Even if Bob is a member of several groups, he’ll
get a user policy that affects just him.
User policies are applied to individual users. If no user policy exists
then group policies are applied in the group priority order. Finally,
computer policies are applied and will override variables for both group
and user policies.
As you’re creating policies you’ll discover that the selection boxes are
actually three different switches. The first switch is just a gray box.
This means that this registry setting is ignored for this account. The
second switch is a checked box; this means to enforce this variable in the
registry. The last switch, a clear box, is to clear out the registry
settings.
Generating Productivity
Your environment may not allow you to set up policies, because the staff
wants to be able to browse the entire network, change their network
settings, and edit the registry. But if you can overcome that and
implement strong policies, you’ll be generating productivity for yourself
and for the company.
As a Microsoft Certified Professional, policies allow you to focus on
productivity, streamline downtime on your network, and invest more time
with things that really matter—like finding cool polar bear screensavers
that work well with NT.
Exclusively Online: A Brief Nightmare
A friend of mine, who asked to remain anonymous, was toying with computer
policies at a client’s site. He created a logon message that was less than
politically correct for his colleagues. After a few laughs, he deleted the
NTCONFIG.POL from the Netlogon share. Because it was a computer policy,
however, the changes were actually already made at each machine where the
policy had been downloaded. Much to the client’s chagrin, the logon
message continued to appear. After four days of complaints from users
where the computer policy had been downloaded, he went through each
registry and removed the logon message manually.
What my buddy could have done was clear the check mark for the logon
message in the original NTCONFIG.POL file, which would have wiped out the
logon message from each machine the next time the policy was downloaded.
Or he could have created a new policy file and cleared the checkmark to
wipe out the logon message for each computer that currently had the
message downloaded.
-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: Repent Security Incorporated [www.repsec.com]
Received on Sat Nov 21 11:38:32 1998