Windows Tip Sheet

Lock Down Those Scripts!

Take care of this task throughout the company via this Active Directory trick.

"Lock down your scripting environment" is a big refrain with me. Anyone who's attending my scripting classes has heard me say it, and certainly anyone who reads anything I've written has seen it. Recently, though, I got a huge pile of e-mail telling me that it's just too darn difficult to run around to every machine in the company installing the registry hacks necessary to properly lock down the Windows Script Host. Yeah, you're right. Fortunately, there's Active Directory, which is more than willing to do it for you.

First, some background: The current version of WSH (that'd be 5.6, available from www.microsoft.com/scripting) obeys a cool registry key. Normally, WSH doesn't care if your scripts are digitally signed or not, because this key is set to zero. However, setting it to 1 or 2 makes WSH care: When WSH sees a script that hasn't been signed (and the signing certificate must have been issued by a certification authority that the local machine trusts), WSH either notifies the user and asks what to do (registry key set to 1) or refuses to run the script (set to 2). Asking the user is almost always the wrong answer, of course, because we all know they'll just say "run it anyway," so I prefer the second option.

As I mentioned, this all takes place in a registry key. Well, actually a couple of registry keys. On Windows 2000, just one key is involved: HKCU\Software\Microsoft\Windows Script Host\TrustPolicy, which is a REG_DWORD value. On Windows XP and Windows 2003, though, things are more complicated. Under HKLM\Software\Microsoft\Windows Script Host\ you'll find a value named UseWINSAFER, which is set to 1 by default. This forces WSH to obey Software Restriction Policy settings instead of the TrustPolicy key. Since nobody sets up Software Restriction Policies, setting TrustPolicy to 1 or 2 has no effect until you set the UseWINSAFER value to 0. There's another value on the HKLM side which tells WSH to ignore the HKCU settings and instead obey HKLM\Software\Microsoft\Windows Script Host\TrustPolicy.

And so on. It's definitely too painful to think about modifying all your client and server computers but, as I said, "Active Directory to the rescue!" I've made an ADM template, which you can import into a Group Policy object and use to push your preferred WSH security settings out to the world. You can download it from www.scriptinganswers.com/download/adm.zip. You'll need to modify the GPO editor's Filter options (from the View menu) to display more than just "managed policies," because these WSH policies aren't managed (they're referred to as preferences, not policies, and they remain permanent even if you un-assign the GPO). The template will let you assign all of the necessary registry keys, and a couple of other related ones, besides.

With the right WSH TrustPolicy setting in place, scripts will only run if they're signed. To get your scripts to run, simply sign them using a digital certificate that's trusted by local computers. This might be a certificate issued by a commercial CA like VeriSign or Thawte, or one issued from your internal corporate CA. Until virus authors begin signing their scripts—thus providing an identity trail back to them—your scripting environment will be safe and snug.

Micro Tip Sheet

Think you can lock down scripting by just deleting WScript.exe and CScript.exe? Be careful: Those files are under Windows File Protection (Win2K and newer) and can be copied back by the operating system during the next automatic file protection scan.

So maybe you can lock down scripting by disassociating "VBS," "JS," "WSH," and other filename extensions from WScript.exe and CScript.exe? That's a false sense of security: All an attacker has to do is execute "WScript.exe Anyfile.xxx" and the script (contained in "Anyfile.xxx") will happily execute.

Looking for a way to digitally sign scripts? Microsoft suggests writing a script to do it, which is kind of cool. You can also use PrimalScript (www.sapien.com), which has a built-in script-signing tool. In fact, the latest version can be configured to automatically sign scripts with a designated certificate every time you hit "Save," making script signing completely transparent.

More Resources
Microsoft Scripting Technologies: http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28001169

Windows Script Host documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/wsoriWindowsScriptHost.asp

My Windows scripting Web site: www.scriptinganswers.com

About the Author

With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform. He’s the author of more than 35 books, including Windows PowerShell: TFM, Windows Administrator’s Scripting Toolkit, VBScript WMI and ADSI Unleashed, PHP-Nuke Garage, Special Edition Using Commerce Server 2002, Definitive Guide to SQL Server Performance Optimization, and many more. Don is a top-rated and in-demand speaker and serves on the advisory board for TechMentor. He is an accomplished IT journalist with features and monthly columns in Microsoft TechNet Magazine, Redmond Magazine, and on Web sites such as TechTarget and MCPMag.com. Don is also a multiple-year recipient of Microsoft’s prestigious Most Valuable Professional (MVP) Award, and is the Editor-in-Chief for Realtime Publishers.

comments powered by Disqus

Reader Comments:

Thu, Feb 3, 2005 Dennett Sydney - Australia

G'day Don,

I agree, teriffic article - just what I was looking for. Followed your instructions and it works like a charm. Really useful ADM template as well.

Thanks very much...

Wed, Jun 30, 2004 Ron Kansas

Nice article Don...

We've talked about implementing this before... Excellent idea.

By the way, does anyone else think it's insane that you have to actually modify the filter to show settings that cannot be "fully managed"?? They may only be preferences (i.e. tattoing the registry), but they ARE being applied, and anything that's being APPLIED to objects should be shown by default.

I've had to show that settings to several junior admins over the years who were trying to understand and/or troubleshoot our GPOs.

Another one is the "Advanced Features" view in Active Directory Users and Computers. Pretty much anyone who's working in AD&C should be able to see ALL information by default, not just a subset. I'll create a custom mmc if I want to limit what people see.

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.