Changing the registry is a scary concept, but WMI makes it simple.
- By Chris Brooke
- June 01, 2003
Can you cite the standard warning all administrators give to underlings
prior to making (or even considering) changes to the registry?
“Changes to the Windows registry are dynamic. They take effect immediately. Errors may cause unpredictable behavior—including failure of the computer to boot—and may even cause the computer to self-destruct or, worse, cause your entire office network to crash—maybe even bring down the Internet! Before you edit the registry, get permission from your boss’ boss, your CEO, your significant other and the President of the United States. Be sure to back up the registry, your hard drive and every shared drive in the building, too. Have all of your original CDs ready because you will make a mistake and spend the rest of the weekend rebuilding the server! On second thought, let’s forget this registry editing business and catch a ballgame instead.”
Well, it goes something like that.
While you should always strive to heed the above warning, there are times
when editing the registry is inevitable. In such cases, it’s important to
ensure that only the appropriate people have the authority to make changes.
Because this is a column on scripting, I’m going to show you how to manage
these registry permissions using Windows Management Instrumentation (WMI).
This month’s topic was suggested by Terrence Sheridan of Fairfax, Virginia.
Just keep repeating the above warning over and over in your head as we go
along, and you should be fine.
First: The Bad News
The Standard Registry provider of WMI (StdRegProv) provides great flexibility
in creating registry keys and values and in setting those values. It doesn’t,
however, allow you to alter registry permissions. For that, you must continue
to use Regedt32.exe. Even so, it remains a valuable tool for determining
the permissions assigned to a particular user.
If You’ll Permit Me
The first thing you need to know about registry permissions is that they’re
a sort of cross between NTFS and share permissions. If you view the registry
keys as folders and the registry values as files, you’ll see what I mean.
You can only assign permissions to registry keys (folders), not to the
values (files) themselves. This is similar to share permissions. However,
you can inherit permissions from the parent key and pass permissions to
child keys. In this way, they resemble NTFS permissions. And like NTFS
permissions, they’re assigned default values that are pretty close to
what you need. Still, you may find yourself needing to check permissions
on servers or client machines. Following is a script that determines if
the current user has the particular rights specified in a query.
This script uses WMI to determine if the current user has the requested
registry permissions on the target machine (defaults to local machine)
This script displays
name of the computer (optional)"
(Download this script by Clicking
Here or by right-clicking that link, then choosing "Save
As..." from the context menu. Note that this script or any other
script may be falsely recognized as a virus when you download it.)
“You Have the Right to Remain…Authorized.”
As you can see, I’ve written the script in such a way to demonstrate the
primary activities of viewing permissions. All you have to do is substitute
the keys specified in the script with the appropriate keys you wish to
view. Alternatively, you can pass the key and permission values as arguments
to your script. Because the registry permissions are accessed as a bitmask,
you can add together the values of several permissions you wish to query.
Table 1 lists the codes for all the registry permissions you can query,
as well as the codes for the individual root keys. These are all set up
as constants in the script.
Codes for all registry permissions that can be queried, along with
codes for individual keys.
|**valid for Windows 95 and 98 only
Most of the script is simply setting up the constants for accessing the
registry. The real “meat” of the script takes place under REF:
1. The CheckAccess
method works differently from any function I’ve used to date. The method’s
return value actually indicates whether or not the query was successful,
not whether or not the user has the specified rights. You might, for example,
get this error when you’re trying to run a query on a key where you don’t
have the READ_CONTROL right. The information regarding rights is actually
passed back via one of my arguments. bHasRights
contains no value when I call the method—it’s there only as a placeholder
to receive a value back when the method completes. If you use the bitmask
to check several permissions at once (as I did), the failure of any single
permission will cause bHasRights to return a
“False.” Keep that in mind when you’re modifying this script for use in
your organization. You may want to check these values one at a time.
Windows NT and Windows 2000 provided
two separate registry editors: Regedit.exe and Regedt32.exe.
Each had its purpose. Regedt32 allowed configuring permissions
but didn’t allow searching based on the data a
value contained. Regedit, on the other hand, allowed
searching based upon the data stored in a value but
didn’t allow editing permissions. Windows XP contains
both Regedit and Regedt32 executables, but both point
to the same process: Regedit.exe. XP’s registry
editor gives us the best of both worlds: a Windows Explorer-like
interface that allows enhanced searching along with
the ability to manage registry permissions. So, even
though you technically can launch Regedit under XP and
manage permissions, whenever I refer to the registry
editor that allows permissions changes, I call it Regedt32.
Because Terrence got me on the subject of the registry, I’ll continue the
topic next month with a look at a cool Microsoft component that opens up
a whole new world in registry scripting.