Ben’s Tech Blog

I’m in the process of decommissioning three NT4 domains as well as some legacy servers.  The domains had previously remained in place as we had some Windows NT 4.0 EIC telephony servers and an underlying Exchange 5.5 infrastructure that were dependant on them (EIC uses unified messaging).

I’m going to spread this post over more than one entry, the first part will cover the planning stage.

Planning

Identifying the domain’s dependencies

The first step in planning the project was to determine what was actually dependent on the domains.  Although I knew that the EIC and Exchange servers relied on the domains, there were some servers and service accounts that were still in use; these needed to be documented and assigned an action.  I created a MindManager map which listed each domain as a main topic, and each server within the domains as the immediate child topics.  Branching out from the servers was each service, server, or user group that was dependent on these servers.  I then used map markers to assign an action to each dependency.  This allowed me to start thinking about the order in which I could remove servers.  Naturally I can’t include the actual document for security reasons, so I’ve created a basic example of the dependencies mind map.  It contains enough detail to give you the general idea, but it’s far from complete.

Going through this exercise was very valuable; it’s something that I plan to do for each environment that I work in with in future.

Action Plan and Project Time Line

After creating the dependencies map, I created a Microsoft Project document.  The nice thing about Ms Project is that you can assign “predecessors” for each task.  This allowed me to translate what I had identified as dependencies in the mind map into an ordered list of tasks with predecessors.  For example, the server that hosts the EIC database cannot be decommissioned prior to the actual EIC server; therefore the task to decommission the EIC server became a predecessor of the task to decommission the EIC database server.  For each server to be decommissioned, I allocated a date for a final backup and to shut the server down.  I planned the actual hardware to be decommissioned several weeks after the server is shut down to leave enough time to back out.

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.

A good friend of mine, Todd, sent me a link to this document:

Service overview and network port requirements for the Windows Server system 

The first section of the article contains a list of the Windows Server and client services with their corresponding TCP/UDP port numbers, sorted by the service itself.    The Exchange Server and Outlook clients section is quite comprehensive, with related articles regarding the use of static ports and information about RPC over HTTP.

The second part of the article contains a summary table sorted by port number to make it easy to identify which services listen on a particular port.

A valuable article.

I created a new script today to force AD replication between a number of servers.  I’ve explained how the script works on the script page, check it out if you’re interested.

VBScript - Force AD Replication

Last night I got a phone call from an institute for deaf and blind children (I don’t recall the name).  The rep on the phone started by telling me about the cause and asked me if I’d be interested in buying some raffle tickets to be in the running to win a car; naturally the proceeds from the raffle go towards their cause.  Sure, I was quite happy to buy some tickets so the rep asked me for my credit card details.  Hmm.  

I explained that I wasn’t willing to give out my credit card details to him as he had called me and not vice verca, so there was no way to verify that he was in fact from the institute that he declared to be from.  He was a little puzzled and wasn’t sure what to do.  In the end he said that he was able to mail me some material and that I could purchase the tickets by filling out a form and posting it back.  

That’s the third time in the last few months that I’ve received a call that at some point during the conversation have been asked for sensitive information.  The other two phone calls where from Telstra. 

The first phone call from Telstra was in relation to an overdue bill - OK I usually pay my bills on time, I somehow missed one!  The rep called me, told me he was from Telstra and started by asking for my date of birth “for security reasons”.  I’ll admit that I was more suspicious of this call because he had a thick Indian accent, and I’ve watched too many documentaries about fraud from that region.  I told him that I wasn’t comfortable with giving out that information (again, because he’d called me) but he sounded surprised, and actually seemed a little shirty.  I asked him for a phone number that I could call back on, so he gave me a 1800 number.  I jumped on the Telstra website to see if I could match the phone number, but couldn’t find a match anywhere.  I tried the white pages with the same result. 

The company that I work for has a contract with Telstra, so I asked our rep if she could help me out and verify whether this call sounded legit or not.  She emailed me back and confirmed that yes, it was a legitimate phone number and that I should call back. 

My point here is that this is extremely bad practice.  Companies should not be calling their customers and expecting them to provide sensitive information.  By doing so, they are supporting “cold call fraud” as I will call it.  The documentaries that I referred to before (one was on the ABC, the other was a story on one of the current affairs shows) were reporting that this type of fraud is on the increase.  The only way to prevent it is to encourage the general population to be wary of calls like this.   

To draw a parallel, banks don’t email their customers and ask them to update their account details, and in response to recent phishing attempts, they have gone to considerable effort to educate their customers about these attacks.  Companies like Telstra should be taking the same approach to their outbound phone calls and should develop a standard protocol for calling their customers where sensitive information needs to be exchanged, for example, asking them to call a 1800 number (one that’s actually listed) before providing their details.

If you’re still interested, the other call from Telstra was a from a rep who wanted to “help me reduce my Telstra bill”.  He also started by asking for my date of birth to which I replied as before.  The rep got very frustrated and clearly missed my point.  He kept responding “but for security reasons I need your date of birth” to which I would reply “yes, but for security reasons I can’t give it to you… because I can’t be sure you are calling from Telstra”, to which he would reply “yes, I am calling from Telstra and I would like to help you save money” and so on and so on until I hung up.