You can give ordinary users NT and WMI administrative rights for routine tasks—to a degree.
Over the last few months, we’ve been discussing a variety of security-related
topics. We’ve placed a particular emphasis on using Windows Management
Instrumentation (WMI) to accomplish these tasks. However, I’ve always
assumed that the scripts would be run by administrators such as yourselves.
Proceeding under that assumption simplifies things tremendously. If only
admins are running these scripts, I don’t have to worry about permissions.
I can assume that you have the appropriate NT permissions to perform the
task, as well as adequate WMI permissions. But what if you have a script
that you need users to run—one that requires a level of authority they
That was the question I received from Salvatore Cagliari, a regular reader of this column. He wrote: “I’m facing a problem with delegation of management rights with WMI scripting. A group of users without administrative rights must be able to run VBS scripts to perform various tasks [such as] start/stop services, etc.”
He went on to say that he’d assigned the appropriate NT permissions/user rights to allow the users to start and stop the services, but the script still failed.
The good news is that you can, indeed, give a user the appropriate WMI
permissions to run the script. The better news is that you maintain strict
control over exactly what you allow them to do. In other words, it’s not
an “all or nothing” scenario. You don’t have to give them the master key
to your house. You can give them keys to specific rooms instead. The bad
news is that you have to manage permissions in two separate places. When
you think about it, though, this isn’t really bad news at all. Maintaining
multiple layers of security is actually a good thing.
Peeling the Onion
The first layer of security is the one that confronts us all: NT user
rights. As administrators, we have (big, booming voice, lots of reverb…)
all the power in the universe! We’ve become accustomed to wielding this
power. If we ever encounter a Permission Denied message, it causes the
hair on the backs of our necks to stand up as we become filled with (righteous?)
indignation. “What do you mean I don’t have permission? I am permission!”
Users, on the other hand, get these messages all the time. In order to
allow them to run a WMI script to do something like the above-mentioned
starting/ stopping a service, we must first ensure that they have the
appropriate NT permissions.
The second layer is WMI itself. We must give the users specific rights to access WMI namespaces. And because WMI itself is big and complex, assigning these rights requires a certain degree of finesse. After all, we only want to enable them to perform the task we’re delegating to them—nothing more. Fortunately for us, Microsoft has a tool that makes this process as easy as configuring NTFS permissions: the WMI Control.
For Windows 2000/XP/2003 machines, you run wmimgmt.msc. This opens the
Microsoft Management Console (MMC) with the WMI Control loaded. The WMI
Control doesn’t really interact with the MMC like it should. To use it,
you must either click the Properties button or right-click the WMI Control
item in the treeview and select Properties. This opens the actual WMI
Control application (see Figure 1). If you have NT 4.0 machines (or need
to allow access to Windows 9x/ME machines), you need to run wbemcntl.exe.
|Figure 1. Use the WMI Control to allow access
to specific namespaces.
For the purposes of this exercise, we’re going to deal with assigning
permissions to ROOT/CIMV2. This is because the CIMV2 namespace holds the
Win32_Service object we need for starting and stopping services. Besides,
almost every WMI script we’ve ever written in this column has used the
CIMV2 namespace. In the WMI Control app, under the Security tab, highlight
CIMV2 and press the Security button. Figure 2 shows the security dialog.
This should look familiar. It’s exactly like the NTFS permissions dialog,
the only difference being the listed permissions. Again, because we’re
trying to enable users to stop and start services remotely, the permission
we need to assign is Remote Access. Using the Security dialog, we simply
add the user or group Remote Access to CIMV2 and all subfolders.
|Figure 2. You can assign permission to users
or groups to access WMI.
Theory vs. Practice
While my solution is great for Salvatore, there’s no doubt many of you
are scratching your heads wondering why any admin would ever give this
kind of power to ordinary users. Well, let’s step back and look at the
big picture. Years ago, one of my servers was a test box on which we had
a select group of users working. Periodically (as was often the case with
NT back then), it needed a reboot in order to work properly. If I was
away from my desk solving some other problem, my users were dead in the
water until I came back and rebooted the server. Just think of the headaches
I could have saved if users were given the ability to reboot it remotely
simply by running a script.
If you think about it honestly, I’m sure you’ll find lots of occasions
where delegating routine tasks could make life simpler. With WMI and NT
permissions working together, security need not suffer.
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to firstname.lastname@example.org.