Mr. Script

Registry Rights

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

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.



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.

Table 1. Codes for all registry permissions that can be queried, along with codes for individual keys.
Root Key Code Access Permission Code
HKEY_CLASSES_ROOT &H80000000 KEY_QUERY_VALUE &H0001
HKEY_CURRENT_USER &H80000001 KEY_SET_VALUE &H0002
HKEY_LOCAL_MACHINE &H80000002 KEY_CREATE_SUB_KEY &H0004
HKEY_USERS &H80000003 KEY_ENUMERATE_SUB_KEYS &H0008
HKEY_CURRENT_CONFIG &H80000005 KEY_NOTIFY &H0010
HKEY_DYN_DATA** &H80000006 KEY_CREATE_LINK &H0020
DELETE &H00010000
READ_CONTROL &H00020000
WRITE_DAC &H00040000
**valid for Windows 95 and 98 only WRITE_OWNER &H00080000

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.

Regedit vs. Regedt32

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.

—Chris Brooke

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.

comments powered by Disqus
Most   Popular