In the previous article in this series, we looked at two remote scripting tricks, one from a helpful reader and the other from the recently published Windows Vista Resource Kit. In this article we're going to look at two more scripting tips. First, another remote scripting trick from another of our readers. And second, a real-world example showing how to use the Windows Management Instrumentation Command-line (WMIC).
Trick #1: Another "runas" trick, but with encryption
The first scripting trick was submitted by reader Steven Beard from the UK. Steve offers another take on how to invoke the "runas" command from within a script and how this can be useful in enterprise environments. Let's listen to what Steve has to say:
Hi, I have been a very keen reader of all your articles and have found your vb scripting section very interesting. I have been using vb script for many years to administer my windows domain but have never really understood WMI enough, only really to get what I need.
However your last article regarding the runas function was very good, I also use this but in a very different way, see below:
Set WshShell = CreateObject("Wscript.Shell")
Set WshEnv = WshShell.Environment("PRocess")
WshShell.Run "runas.exe /user:" & "domain\user" & " " & Chr(34) & "cscript c:\PCQuery.vbs" & Chr(34)
WshShell.AppActivate WshEnv("SystemRoot") & "\system32\runas.exe"
WshShell.SendKeys "PASSWORD" & "~"
Set WshShell = Nothing
Set WshEn = Nothing
Basically, I wrap all my scripts that need admin rights up in the script above which uses runas and then waits and uses sendkeys to send the password.
This has the same issue as the script passed to you by your other reader. The passwords are sent unencrypted across the network, which brings me to the reason why I am writing this mail.
I use the script encoder which basically runs the script through the encoder and hashes it with its encryption algorithm, you then end up with a .vbe instead of a .vbs file.
I am sure this is very crackable but better than clear text.
I just thought that this would be a very interesting little tool to your readers.
Keep up the great work and I look forward to your next article.
Trick #2: Querying for local administrators using WMIC
For my second trick, I'll use VBScript to pull a rabbit out of a hat. Just kidding!
The second tip will be based on a real-life problem. A reader contacted me once with what seemed like a simple question: How can you list any local administrator accounts on a remote machine?
The scenario was that the reader had several dozen Windows XP workstations that were originally part of a workgroup, and users had local admin privileges on these machines (i.e. their local user accounts were members of the local Administrators group on the machines). Eventually the network was migrated over to an Active Directory domain, and users were given new user accounts that were members of the Domain Users global group.
One day, the administrator noticed that a user seemed to have more privileges than she had been assigned, and he discovered that the old local admin accounts had not been deleted from her workstation and she was logging on using one of these local admin accounts when her domain user account didn't give her enough control over her workstation. The administrator realized this could be a serious issue since (a) it violated company security policy and (b) allowing users to log on to their workstations as admins could lead to higher support costs i.e. they might screw something up on their workstation since local admins can do virtually anything on their machines.
Now to make it even more complicated, the built-in Administrators local group on her workstation had been renamed to something else, and the built-in Administrator local user account had also been renamed. Checking a second workstation revealed that the built-in Administrators local group and Administrator local user account have both been renamed on this machine also, but they've been renamed differently than on the first workstation! What a headache!
Resolving this looks like it's going to either involve logging on to every workstation and digging through all the local users and groups on each machine to determine which local user accounts are local admins on that machine, or try and find another way of determining this information. Maybe a script?
Well, you could script a solution to this problem, but instead of doing that, let's try something different and use the Windows Management Instrumentation Command-line (WMIC) instead. WMIC is basically a tool (actually a command interpreter) that let's you query WMI information directly from the command line instead of having to do it from within a script. WMIC can be used in two ways: interactively (issuing one command at a time at the command prompt) or in batch files.
Using WMIC interactively
For example, let's say the built-in Administrators local group and Administrator local user account haven't been renamed on the system. If this is the case, you can use WMIC interactively to display a list of all members of the built-in Administrators local group by opening a command prompt and typing the following command:
Looking at the second column, we can see that the Administrators local group on this machine has three user accounts belonging to it: Administrator, sjones and gsmith. In addition, the Domain Admins global group is a member of the Administrators local group on this system.
Now what if the built-in Administrators local group on the system has been renamed? Running the above command now gives the following result:
C:\Documents and Settings\myself>wmic path win32_groupuser where (groupcomponent="win32_group.name=\"administrators\",domain=\"%computername%\"")
No Instance(s) Available.
Why did the command fail? Obviously because the name of the group being queried for is hard-coded into the command. But if the built-in Administrators local group has been renamed, how can we determine its new name? The simple answer is that whatever this group may have been renamed to, it's still the same old group under the hood. In other words, it's security identifier (SID) hasn't changed and must still be S-1-5-32-544 (see KB 243330 for a list of well-known SIDs).
So how can we determine what the name of a group is if we know it's SID? Well, we can use WMIC again, like this:
C:\Documents and Settings\myself>wmic group where (sid = "S-1-5-32-544" and localaccount = true) get name
Aha! The built-in Administrators group on this system has been renamed to JustAnotherGroup! A very clever and yet ultimately futile attempt at security through obscurity, no? Heh!
Anyway, now that we know the name of this group, we can use WMIC to query for its members:
And we can see from the command output that there are three local admins on this machine: sjones, gsmith, and JustAnotherUser. And of course the Domain Admins global group is a member of JustAnotherGroup as well.Using WMIC in Batch Files
So far this works great, except that we don't want to have to log on to every workstation and run these two WMIC commands. Can we do all this from some central location? Sure! WMIC can be run against remote computers by using the /node:"<computername>" switch, provided you've enabled the Remote Administration exception on the targeted machines (you can do this using Group Policy as explained in part 6 of this series of articles). So assuming you've done that, let's open a command prompt on our central server (our domain controller) and issue the same two WMIC commands, but this time against a remote workstation named XP191. First we'll get the name of the built-in Administrators local group on the remote machine:
C:\Documents and Settings\Administrator>wmic /node:"xp191" group where (sid = "S-1-5-32-544" and localaccount = true) get name
Now we'll use this result to get a list of the membership of this group:
The results are just as we expect. From this point, it's easy to write a simple batch file that queries all the workstations on your network and saves the result in a text file you can analyze later.
WMIC is fun, but sometimes mysterious. We'll learn more about using it in future articles in this series. Meanwhile, got any scripting tips or tricks to share with other readers? Email me at firstname.lastname@example.org and I'll try and include them in a future article in this series.
About the author:
Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the Microsoft Encyclopedia of Networking (Microsoft Press), the Microsoft Encyclopedia of Security (Microsoft Press), Windows Server Hacks (O'Reilly), Windows Server 2003 in a Nutshell (O'Reilly), Windows 2000 Administration in a Nutshell (O'Reilly), and IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his website: www.mtit.com.
WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
This was first published in August 2008