Managing Windows networks using Script - Part 11: Other script tricks

Managing Windows networks using Script - Part 11: Other script tricks Picture 1   Part 1: Basic concepts
Managing Windows networks using Script - Part 11: Other script tricks Picture 2   Part 2: Complete the script
Managing Windows networks using Script - Part 11: Other script tricks Picture 3   Part 3: Understanding WMI
Managing Windows networks using Script - Part 11: Other script tricks Picture 4 Part 4: Use Win32_NetworkAdapterConfiguration
Managing Windows networks using Script - Part 11: Other script tricks Picture 5 Part 5: Overcoming challenges
Managing Windows networks using Script - Part 11: Other script tricks Picture 6 Part 6: The first steps for remote scripting
Managing Windows networks using Script - Part 11: Other script tricks Picture 7 Part 7: Troubleshooting errors
Managing Windows networks using Script - Part 11: Other script tricks Picture 8 Part 8: Remote script error handling with Network Monitor 3.0
Managing Windows networks using Script - Part 11: Other script tricks Picture 9 Part 9: Understanding remote control scenarios
Managing Windows networks using Script - Part 11: Other script tricks Picture 10 Part 10: Tricks of remote control scenarios

Mitch Tulloch

In the previous part of this series we learned two tricks for remote control scenarios. In the previous section we saw two more script tips. The first tip, remote scripting tricks from a reader, a second tip, a real world example is used to show how to use the Windows Management Instrumentation Command-line (WMIC).

Tip 1: Trick 'runas' but with encryption

The first scenario scenario was submitted by reader Steven Beard from England. Steve offers a completely different way to call the 'runas' command from within the script and this can be useful in business environments. Listen to what Steve said:

I have used vb scripts for years to administer my Windows domain but have never understood all about WMI but just what I really needed. Although the final part of your interest in the runas function is great, I use it in many different ways, as you can see below:

Set WshShell = CreateObject ("Wscript.Shell")
Set WshEnv = WshShell.Environment ("PRocess")
WshShell.Run "runas.exe / user:" & "domainuser" & "" & Chr (34) & "cscript c: PCQuery.vbs" & Chr (34)
Wscript.Sleep 800
WshShell.AppActivate WshEnv ("SystemRoot") & "system32runas.exe"
Wscript.Sleep 200
WshShell.SendKeys "PASSWORD" & "~"
Wscript.Sleep 500
Set WshShell = Nothing
Set WshEn = Nothing

Basically, I hide all scripts that need administrative rights in the above scenario using runas, then wait and use sendkeys to send the password.

This is the same problem that the script is passed to you by another reader. Sent passwords are not encrypted across the network, which is why I write this email.

I use the encoder script (basically run the script via encoder and hash tables with multiple encryption algorithms), then end up with a .vbe file instead of .vbs.

I guarantee it can still be cracked but still better than not encrypted.

Tip 2: Query for local administrators with WMIC

This second trick will be based on real life issues. A reader contacted us asking a simple question: how can you list local administrator accounts on remote computers? The scenario is that readers have multiple Windows XP workstations, machines are the start of a group, and users have local administrative rights on those computers (ie their local accounts are members of Local admin group on these computers). The network has finally been migrated to an Active Directory domain and users are given new accounts as members of the Domain Users global group. Then, one day the administrator was told that the user seemed to have more privileges than what he had assigned and that he had discovered that the old local administrator accounts were not detected from His workstation, he has logged in with a local admin account when the domain user account does not allow him to have sufficient control on the workstation. Administrators recognize this can be a serious problem when (a) it interferes with the company's security policy and (b) allows users to log on to their workstations as administrators. Members, which means they can simply handle their workstations when local administrators can do almost anything on their machines, however this can lead to high support costs. than.

Now to make it a little more complicated, the attached Administrators local group on the workstation are renamed to something and the attached Administrator local user account is renamed. The second workstation test found that the attached local administrator group and local user account were also renamed on this computer, however, they were renamed differently from the first workstation. ! Really a complex headache! Resolving this is like it requires logging into the workstations and digging for all local users and groups on each computer to determine which local user account is local administrator. on that machine, or look for other to determine this information. Could be a script?

You can solve it by script, but instead of doing that, try to do something else and use the Windows Management Instrumentation Command-line (WMIC). WMIC is basically a tool (a command interpreter) that allows querying WMI information directly from the command line instead of having to do it inside a script. WMIC can be used in two ways: interactive (giving a command at a certain time at the command window) or in files.

Use interactive WMIC

For example, consider that the attached local administrator group and local user account are not renamed on the system. If this is the case, you can use interactive WMIC to display a list of local administrators by opening a command prompt and typing the following command:

C: Documents and Settingsmyself> wm path win32_groupuser where (groupcomponent = "win32_group.name =" administrators ", domain ="% computername% "")
GroupComponent ??????????????????? ???????? PartComponent
win32_group.domain = "XP191", name = "administrators"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "Administrator"
win32_group.domain = "XP191", name = "administrators"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "sjones" ????
win32_group.domain = "XP191", name = "administrators"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "gsmith" ???????
win32_group.domain = "XP191", name = "administrators"?XP191rootcimv2: Win32_Group.Domain = "TEST", Domain Admins "Name ="

See the second column, we can see that the local admin group on this computer has 3 user accounts with it: administrator, sjones and gsmith. In addition, the global domain administrator group is a member of the local administrative group on this system.

What is the local administrative group attached to the system now renamed? Running the above command will result in the following:

C: Documents and Settingsmyself>wm path win32_groupuser where (groupcomponent = "win32_group.name =" administrators ", domain ="% computername% "")
No Instance (s) Available.

Why is the order broken? Obviously because the name of the group exists has been queried by the hard code in the command. But if the attached local administrator group is renamed, how can you determine its new name? The simple answer is that what this group can be named is still the same as the old one on the outside. Or it is another way, it is the security identifier (SID) that remains unchanged and is still S-1-5-32-544 (you can see more here for a list of SIDs).

So what can we define the name of the group if we know its SID? We can reuse WMIC again, like this:

C: Documents and Settingsmyself>wmic group where (sid = "S-1-5-32-544" and localaccount = true) get name
Name
JustAnotherGroup

So the administrative group attached to this system is renamed JustAnotherGroup!

Either way we now know the name of this group, we can use WMIC to query its members:

C: Documents and Settingsmyself>wmic path win32_groupuser where (groupcomponent = "win32_group.name =" justanothergroup ", domain ="% computername% "")
GroupComponent PartComponent
win32_group.domain = "XP191", name = "justanothergroup" XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "JustAnotherUser"
win32_group.domain = "XP191", name = "justanothergroup" XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "sjones"
win32_group.domain = "XP191", name = "justanothergroup" XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "gsmith"
win32_group.domain = "XP191", name = "justanothergroup" XP191rootcimv2: Win32_Group.Domain = "TEST", Domain Adm "" Domain Admins "

And we can see from the command that there are 3 local administrators on this computer: sjones, gsmith and JustAnotherUser. Obviously the global domain admin group is a member of JustAnotherGroup.

Use WMIC in Batch files

Conversely, if we don't want to log in to the workstation and run the above WMIC commands, how do we do it? WMIC can be run on remote computers using the / node: ' switch, which is provided so that you can enable Remote Administration on the target computers (you can do this by How to use Group Policy as explained in section 6). So admit that you've done that, open a command prompt on our central server (domain controller) and give two WMIC-like commands, but this time the remote control is called XP191. First, we get the name of the local administrative group attached to the remote computer.

C: Documents and SettingsAdministrator>wmic / node: "xp191" group where (sid = "S-1-5-32-544" and localaccount = true) get name
Name
JustAnotherGroup

Now we use this result to get the list of team members:

C: Documents and SettingsAdministrator> wmic / node: "xp191" path win32_groupuser where (groupcomponent = "win32_group.name =" justanothergroup ", domain =" xp191 "")
GroupComponent ????????????????????????????? PartComponent
win32_group.domain = "xp191", name = "justanothergroup"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "JustAnotherAccount"
win32_group.domain = "xp191", name = "justanothergroup"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "sjones"
win32_group.domain = "xp191", name = "justanothergroup"? XP191rootcimv2: Win32_UserAccount.Domain = "XP191", Name = "gsmith"
win32_group.domain = "xp191", name = "justanothergroup"?XP191rootcimv2: Win32_Group.Domain = "TEST", Domain Admins "Name ="

The results are as expected. From this point, you can easily write a simple file to query all workstations on the network and save the results in a text file for later analysis.

Conclude

WMIC is indeed interesting, but sometimes it is difficult to understand. We will study its use in the next sections.

Managing Windows networks using Script - Part 11: Other script tricks Picture 11 Part 12: Properties of the WMI class
Managing Windows networks using Script - Part 11: Other script tricks Picture 12 Part 13: The script returns all values