Mr. Script

Delegating Rights

You can give ordinary users NT and WMI administrative rights for routine tasks—to a degree.

• By Chris Brooke
• 05/01/2004

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 don’t have?

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.