For the Windows environment, it's an often overlooked and always underutilized truism that nearly everything an administrator can do inside a management console or GUI utility he or she can also accomplish at the command line. Likewise, the same is true when using any of a variety of Windows scripting tools. For the purposes of this tip, we'll focus on the kinds of "canned tools" that scripts can create to help automate (or at least speed up) typical security-related administrative tasks.
In addition to the use of .bat files (or their compiled .com counterparts), Windows itself includes the Windows Script Host (often abbreviated as WSH). Copious information about this utility is available in built-in Help files with versions of Windows since NT 4.0, and is also readily available through
If a general description of what's possible isn't enough to inflame your interests, please visit the excellent Web site that belongs to serverGuys.com. For example, you'll find demonstrations of the following scripts there:
List all objects in a domain
List objects of specified type in a domain
Enumerate group members (Windows NT groups)
Enumerate users not in group (Windows NT groups)
Create new user account
Unlock user account
Query account disabled status
Set account disabled
Query User Must Change Password status
Query Password Never Expires status
Query Login Script status
Set Login script
Set User Password
The site also offer scripts for the web management interface (WMI) that provide access to reporting functions and process controls.
It doesn't take a rocket scientist to realize that by using query scripts to interrogate specific Registry or directory-services settings, then acting within scripts on the values that such queries return, it's possible to build powerful flexible script routines to manage lots of routine security administration, especially as it pertains to user management. Thus, one could use scripts to create and maintain user accounts, investigate and alter group memberships (or group composition), manage logon scripts, and much, much more. Given the frequency with which such activities typically take place, scripting makes sense because of the efficiencies it can introduce -- it's nearly always faster to run a well-crafted script than it is to drive the GUI interface by hand. Just make sure you test in a lab situation before deploying scripts on production servers!
A word of warning where scripts are concerned: First, although administrative privileges will normally be required to execute these scripts, it's wise to keep them in a secure directory and restrict access to its contents. That's to prevent them from being used by the unauthorized, but also to prevent their contents from unwanted inspection. Sometimes scripts will contain plain-text account names and passwords you wouldn't want to expose publicly. Be sure to limit access to that directory (and consider encrypting its contents).
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
This was first published in August 2002