Ben’s Tech Blog

I have added a script that I created last week to search for text in Outlook message attachments.

VBScript - Search Outlook Message attachments

Summary: To force Outlook to resolve a name from the Contacts folder instead or the GAL, add ‘(e’ after the name that you want to resolve.

If you’re using Outlook in a corporate environment, you will most likely use two address books: the global address list (GAL) and your Outlook contacts.  The order in which these are searched when performing a ‘Check Names’ is determined by the order specified in your profile.  In Outlook 2003, you can modify the order by opening the address book and clicking on Tools, then Options.  You will be presented with the following dialog box, and can use the arrows to the right of the lower box to change the order of the address books.

In most cases you will specify the GAL as the first entry and your Contacts as the second entry as most users send a greater volume of emails internally than externally.The problem however is that if you want perform a check names for an external recipient and you have a large GAL, chances are the name is going to resolve to one or more names in the GAL and not the recipient in your Contacts folder.  A while back I discovered a little trick to overcome this.  The display name of recipients in your Contacts folder is suffixed with ‘(email)’, so all you need to do to ensure that the name that you enter will resolve against your Contacts folder instead of your GAL is to include ‘(E’ after the name.  For example, if you have a recipient called John Black in the GAL, and a recipient called John White in your contacts folder, typing ‘John (e’ and performing a ‘check names’ will force Outlook to resolve the name to John White from your Contacts folder, because the ‘(e’ doesn’t exist in the display name for John Black in the GAL.

This trick regularly saves me time so I thought I’d share it with you

I passed 70-294 today (Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure) with a score of 966, which I’m happy with.  Next up is 70-284 (Implementing and Managing Microsoft Exchange Server 2003).  Although I’m going to have a break for a week or so, I’ve imported the 70-284 objectives into MindManager so that I’m ready to jump into it; you can grab the map from here:

70-284 Objectives Mind Map 

In my opinion, the biggest shortfall of the Group Policy Editor is the inability to search for the group policy setting that you’re after.  In a lot of cases I know that a setting exists but I find myself navigating through the structure to find it.  Recently I discovered a better way.

The Group Policy Settings Reference is an Excel spreadsheet available for download from the Microsoft website.  It lists the majority of the settings that are available when creating a GPO including the newer settings released with Windows Server 2003 SP1.  The settings that it doesn’t include, according to the overview, are “settings that exist outside of the Security Settings extension (scecli.dll), such as Wireless Network extension, Public Key Policies, or Software Restriction Policies.”

Once you download the spreadsheet it’s easy to use the Excel Find function to search for the setting that you’re looking for.  Although a search function would be handy in the actual Group Policy Editor, this spreadsheet almost makes up for it.

I’ve just started studying for the 70-294 MCSE exam (Planning, Implementing & Maintaining a Windows Server 2003 Active Directory Infrastructure).  I’m taking the same approach as I did for the 70-291 exam (that I passed last week) by  mapping out the exam objectives into MindManager and creating notes around that structure. 

I managed to copy, manipulate, and paste the objectives from here: http://www.microsoft.com/learning/exams/70-294.asp into mind manager.  I thought I’d post the map (without any notes) up here so that others can use the template to make notes against; after all, making your own notes is far more effective than reading someone elses.  You can download the map here: 70-294 Objectives Mind Map.

I’ve also posted an image of the map (click below).

The windows scripting host (WSH) allows administrators to execute scripts to automate administrative tasks, execute network login scripts and query systems for information - just to name just a few of it’s benefits.  I regularly write and run scripts; in fact I sometimes wonder how I got by before I ventured into the scripting realm.  The problem with the windows scripting host however is that it can be a launch-pad for malicious code.  Some administrators choose to disable the use of WSH on workstations and servers to prevent malicious code from executing.  While this makes a lot of sense from a security standpoint, it severely cripples your ability to automate admin tasks, and if you’re using vbscript based login scripts then you’re going to have a real problem. 

A far better approach is to use software restriction policies to dictate which scripts are permitted to run.  Software restriction polices are a new feature available in Windows Server 2003 and Windows XP that are set via Group Policy.  You’ll find the software restriction policy under Computer Configuration/Windows Settings/Security Settings/Software Restriction Policy. 

Software restriction policies are designed to control the execution of all executables, not just scripts.  There are 4 types of software restriction rules; I’m going to focus on the 3 that are beneficial to locking down the Windows scripting host.  To implement the rules, you simply create them in the Additional Rules folder.  Note that the folder already contains 4 default rules.

Path Rules:

Perhaps the simplest to implement, path rules let you either allow or disallow executables to run based on the path that they are launched from.  For example, you could disallow the execution of .vbs files (and the various extensions associated with script files) but permit those files that are in particular network share to run.

In this Example, you would create the following rules:

You could also use path rules to disallow vbscript files from running but allow them to run from your netlogon shares so that vbscript based login scripts could run:

Note that Microsoft’s recommendation is to avoid using environment variables where possible, as environment variables can be changed by the user to point to a different path.  If you choose not to use the %logonserver% environment variable you may want to consider using your domain controllers’ names instead. This may be cumbersome if you have a large number of DCs, but you do have the ability to use wildcards in path rules, so if all of you domain controllers where named DC1 - DC100 you could implement a policy similar to the following:

I’m comfortable in using the %logonserver% variable, and would be happy to use the first example in a production environment.

Hash Rules:

Hash rules have their advantages, however for locking down WSH they don’t provide too much flexibility.  Using a hash rule, you can allow or disallow the execution of files based on their content.  When you create a hash rule, a “hash” of the file is calculated.  Each time an executable is run, a hash of the file is compared with the hash stored in the policy.  In the case of locking down WSH, you could create a path rule to disallow all vbscript files, and then create a hash rule for each script that you want to allow.  While this may be suitable if you are using a single login script that rarely changes, or if you use only a handful of admin scripts that rarely change, it isn’t ideal for environments where scripts frequently change or like me you write new scripts every week.  The advantage to using hash rules over path rules though is that you can modify the filename and the hash will not change.  You can also run the script from any path;  as long as you don’t change the actual script itself you won’t need to modify the rule.

Example of hash rule to allow approved scripts:

Certificate Rules:

Certificate rules are an excellent way to lock down WSH to only allow approved scripts to run.  With a certificate rule, you import a digital certificate into a rule and then digitally sign each script that you want to approve with the same certificate.  The advantage to using certificate rules over path or hash rules is that the contents, path or filename of the script can change without preventing the approved script from running. 

The downside to using certificate rules is that you either need to purchase a digital certificate from a trusted public CA or install your own CA server and issue a certificate from there.  In both cases, the CA needs to be defined in the ‘Trusted Root Certification Authorities’ on your workstations and servers.

Importing the certificate

Once you have obtained a certificate to sign your scripts, you need to import the certificate into the rule.  This is fairly straight forward, you simply create the rule, then browse to the certificate file (*.cer, *.crt).

Signing Scripts

Strangely enough, you actually need to use a script to signs scripts.  The following is an example of a script that signs the C:\Scripts\script.vbs script with a certificate called Ben Christian.  The certificate must first be imported into the certificate store of the machine that you run the script on.

set objSigner = WScript.CreateObject(”Scripting.Signer”)
objSigner.SignFile “C:\Scripts\script.vbs”, “Ben Christian” 

Like the other rules, to implement a certificate rule to allow signed scripts to run, you would first create path rules to prevent the various script extensions from running.

Example of a certificate rule to allow approved scripts:

Using Certificate rules is probably the most secure way to lock down WSH with software restriction policy.  If certificate rules seem too cumbersome to implement, path rules are a good way to go.  In any case, implementing software restriction policies to lock down WSH on your client and server machines is better than doing nothing, and is an ideal balance between security and convenience.