Registry Rights

Changing the registry is a scary concept, but WMI makes it simple.

• By Chris Brooke
• June 01, 2003

“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.

GetRegPermissions.wsf
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 registry permissions

C:\cscript GetRegPermissions.wsf [/Target:computername]

name="Target"
helpstring="The name of the computer (optional)"
type="string"
required="false"
/>

(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.

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.

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.