Use third-party products to fill in WSH's gaps
You just finished your first automated user management script. The script is great, but as soon as you distribute it, someone requests that you add support for Remote Access Service (RAS) permissions. This request is troubling because you developed the script using Visual Basic Script (VBScript) in Windows Scripting Host (WSH), a tool that doesn't support RAS permissions by default.
What do you do? If you followed my column throughout the past year, you
might look outside WSH for a solution. Many of my articles emphasized that
scripts are bits of syntax that glue together command-line utilities,
components, and any libraries, modules, or objects your scripting language
includes.
The fact that you used WSH to create your user management script implies that you also used Active Directory Services Interfaces (ADSI) because WSH doesn't include user management capabilities, per se. Therefore, you might begin your search for RAS permission capabilities in ADSI. Unfortunately, you won't find the functionality you're looking for because ADSI doesn't expose Windows NT's RAS settings. Next, you might look for a command-line utility that you could spawn or call from your script, but again you'll come up empty-handed. You might begin to think you've hit a dead end and the enhancement isn't possible.
However, you just need to find the right third-party component. As you
think about your RAS permissions problem, remember that WSH is a component
object model (COM) controller. If you can find a COM component that exposes NT's RAS permissions, you've solved your problem. As you've probably guessed, such a component exists.
The Component
NTAccess.RAS, which you can download from Zaks Solutions
(http://www.zaks.demon.co.uk/code/), is a third-party COM component that exposes NT's RAS configuration and permissions settings. Zaks Solutions developed NTAccess.RAS for use with Internet Information Server (IIS) and Active Server Pages (ASP). Because WSH is merely a repackaging of the COM-based ActiveX scripting engine in IIS and Internet Explorer (IE), you can leverage NTAccess.RAS in the WSH script you created for user management. Listing 1, page 194, contains a WSH script called RasPerms.vbs that uses NTAccess.RAS. I'll walk through RasPerms.vbs to show you how it works.
If you want to run RasPerms.vbs, download and register NTAccess.RAS.
Download the archive that contains the component from the developer's Web site, unzip the file, and place the component's .dll, nta_ras.dll, in your component directory. Then, use NT's regsvr32.exe utility to register the component. Type
D:\Components\NTAccess.RAS> regsvr32 nta_ras.dll
A message box will appear to let you know that you successfully registered the component. After you register the component, you're ready to use the script.
The Code
To start RasPerms.vbs, you type
D:\Scripts> wscript rasperms.vbs
then enter the arguments you want RasPerms.vbs to use. RasPerms.vbs
recognizes five command-line arguments in the format option=value (for options h, u, s, t, and n).
You must include a value for the u and h options. You use u to specify the username for which you want to modify permissions and h to specify the Uniform Naming Convention (UNC) host name of the server that holds the user's account. You can include the s option to specify whether the user has dial-up permissions. Set s to 0 to disable the user's RAS permissions; set s to 1 to enable the target user to use RAS. If you set s to 1, you can include the t option to specify NTAccess.RAS's CallBackType property, which tells RAS whether to call back a user who dials in. If you set t to 1, RAS doesn't call the user back. If you set t to 2, RAS calls the user back at a phone number you specify. If you set t to 4, RAS calls the user back at a phone number the user provides. If you set t to 2, you also need to include the n option on the RasPerms.vbs command line. Set n to the phone number you want RAS to use to call the user back.