Wednesday, 11 May 2011

TechNet Wiki: Forefront TMG/UAG Articles Published

I have spent some time recently converting a few of my more recent/popular blog posts into TechNet wiki articles. This has given me an opportunity to update the articles in some cases, but more importantly, allows the articles to become ‘community dynamic’ based upon changes, feedback and comments. I am hoping these articles will also have higher visibility as the TechNet Wiki content is highly optimised for search engines which means that people should find the content more easily and quicker.

At this time I have published the following articles:

Forefront UAG SP1 Endpoint Assessment Changes Impact Mobile Devices

Forefront UAG DirectAccess: Application Compatibility Table

Problems Accessing SharePoint 2007 RSS Feeds via Forefront UAG

Should I Place Forefront TMG at the Edge of My Network?

Recommended Network Adapter Configuration for Forefront TMG Standard Edition Servers

Recommended Network Adapter Configuration for Forefront TMG Enterprise Edition Servers

Recommended Network Adapter Configuration for Forefront UAG Servers

You can also search for articles I have written (or contributed to) using the following link:

Search TechNet Wiki for My Articles

Watch out for more Wiki articles in the near future…

Saturday, 19 December 2009

It’s been a while and what’s coming soon…

It has been a little while since my last blog post, but I wanted to post a quick message to say that I haven’t forgot about you guys!

Things have been very busy at my day job and I have a hard time in my personal life too, which has pretty much zapped all my spare “blog time” <sniff>

However, moving into the new year, I have some articles in the wings which may be of interest. As a quick teaser, these include:

  • ISA Server 2006 Health Check: Time for a Tune-Up?
  • The Path to DirectAccess – Part 1: Choosing the DA Solution
  • The Path to DirectAccess – Part 2: Thinking about IPv6
  • The Path to DirectAccess – Part 3: Putting it All Together
  • The Path to DirectAccess – Part 4: Extending DA with NAP
  • The Path to DirectAccess – Part 5: A Few Lessons Learnt
  • Using Forefront TMG with Multiple Data Centres
  • Using Forefront UAG with Multiple Data Centres

Since my last post, we now have both Forefront TMG 2010 RTM and Forefront UAG 2010 RTM; we are indeed now closer to the cutting edge than ever before with these important new releases…

Talking of which, that brings me nicely onto something else I have been planning for a while; my new blog site! With the recent product changes and my focus of specialisation, a blog site about ISA just isn’t good enough anymore. So, it’s time for a blog about Forefront Edge Solutions.

Therefore, my new blog site will be called: Closer to the Edge and will be available at the new address of http://blog.msedge.org.uk 

image

From now on, blog posts about TMG/UAG will be going onto Closer to the Edge. I then plan to maintain Me, Myself and ISA to host legacy content and avoid broken links from forum posts etc. There will probably be a period of coexistence where articles appear on both blogs, until I get the new blog into search engines and popular on the forums…

So, 2010 has already started early with both Forefront Edge products released; I hope to make the most of it with my new blog next year too!

Happy Christmas and a Happy New Year! :)

Thursday, 29 October 2009

Come and say hello at Tech-Ed Europe 2009 in Berlin!

I will be at Tech-Ed Europe 2009 in Berlin from the 9th-13th November.

You can find me at the Technical Learning Centre (TLC) on the Microsoft Forefront stand.

If you are attending, come and say hello; don't be shy! :)

TechEd_Europe_Blog_L_MVPs

Thursday, 1 October 2009

Microsoft Forefront MVP Award Continues…

Another year, another MVP award – yay! :)

Really, really pleased for the continued recognition, so thanks to all those involved…

This next year is going to be a pretty exciting place for Microsoft Forefront and I am very glad to be so involved in the journey…

Thanks

JJ

Tuesday, 8 September 2009

Group Policy Processing Errors on ISA Server and Fun with Large ICMP Packets

I recently came across an interesting problem on an ISA Server deployment which I thought might be useful to share.

In this particular deployment, the ISA Server array members were located in a DMZ behind an existing back firewall. Consequently, the back firewall separated ISA Server from internal infrastructure like Active Directory Domain Controllers, Exchange servers etc.

Please Note: Placement of ISA Server in an existing DMZ is a far from ideal deployment scenario, but unfortunately common when using ISA Server as a reverse proxy solution. In an ideal scenario, the ISA Server array members would be placed in parallel to the existing back firewall, or possibly dual-homed directly between the existing DMZ and the internal network. However, that is a discussion for another day ;)

In order to use the Kerberos Constrained Delegation (KCD) feature of ISA Server, it was necessary for these array members to be members of the internal Active Directory domain; the same domain as the published Exchange servers in fact. You can read more here on KCD here and here.

To support the necessary communications for Active Directory domain membership, the back firewall was configured to permit the necessary protocols from the array members to the Active Directory domain controllers. See my previous blog article here for details on the protocols required. 

I tested my web publishing rules and everything was working as expected from an ISA Server perspective. Time to go home? No, not quite :(

However, what did happen was that I started receiving Userenv application event log errors, specifically:

Event ID: 1054
Source: Userenv
Type: Error
Description:
Windows cannot obtain the domain controller name for your computer network. (The specified domain either does not exist or could not be contacted). Group Policy processing aborted.

At first I assumed that the back firewall had been configured incorrectly, but after validating the configuration using Ping and PortQry, I realised that this was not the case.

After a bit of investigation I came across the following Microsoft KB article which describes how to enable debug logging for Userenv:

How to enable user environment debug logging in retail builds of Windows (KB221833)

From looking at the userenv.log file generated using the above KB article, I could see the following errors when using the gpupdate /force command:

PingComputer: Second send failed with 11010

So, this started me thinking about Ping and the use of ICMP between the array members and the Active Directory Domain Controllers. If you refer back to my previous blog article here you will see that PING (ICMP Request -Type 8) is included within the required protocol list. Therefore, ICMP should not be blocked by firewall policy processing on the back firewall.

I confirmed this was not the case using a simple Ping command (which uses a default packet size of 32 bytes) from the array members to one of the Domain Controllers:

Ping <DC IP Address>

Result: Reply from <DC IP Address>: bytes=32 …

Therefore, we had successful ping replies.

More investigation led me to the follow Microsoft KB article:

How to troubleshoot Group Policy object processing failures that occur across multiple forests (KB910206)

Looking at Scenario 2 in this KB article seemed to pinpoint my exact symptoms. In particular, the following text intrigued me:

Group Policy processing stops if large fragmented ICMP packets are not allowed on the network because of slow link detection. When this occurs, Microsoft Windows XP does not detect a fast link or a slow link. Instead Windows XP fails out of Group Policy processing. Only a generic USERENV 1054 event is logged in the Application event log. This problem affects both computer and user policies.

This got me thinking that maybe the back firewall wasn’t blocking ICMP traffic, but was in fact blocking (or dropping) large or fragmented ICMP packets. A quick test using the –l Ping switch with a packet size of 2048 bytes (the default value used by Group Policy processing) confirmed that ICMP was in fact being blocked when using 2048 byte packet sizes:

Ping <DC IP Address> –l 2048

Result: Request timed out.

Lowering the packet size to 1024 made no difference, still blocked:

Ping <DC IP Address> –l 1024

Result: Request timed out.

Finally, lowering the packet size to 500 bytes resulted in successful replies:

Ping <DC IP Address> –l 500

Result: Reply from <DC IP Address>: bytes=500 …

The only real conclusion I could draw from this process of elimination was that the back firewall was configured to block ICMP packets above a certain size or fragmented ICMP packets; most likely packets above 512k. I assumed this was a security feature or some form of DOS protection on the back firewall, and a reasonable measure.

Disabling slow link detection as described in the above KB article (KB910206) didn’t appear to help though and I was still receiving event log errors. I don’t give up easily though!

So, I looked for a solution to reduce the actual ICMP packet sizes used in Group Policy processing. A bit more investigation resulted in the following Microsoft KB article:

Group Policies may not apply because of network ICMP policies (KB816045)

After creating the PingBufferSize registry key and setting this to a value of 500, I used the gpupdate /update command again, and this time I received a successful application event log entry of:

Event ID: 1704
Source: SceCli
Type: Information
Description:
Security policy in the Group policy objects has been applied successfully.

From that point on, the Userenv errors stopped occurring and Group Policy was applied successfully…case closed I think ;)

The only thing left to do was to apply the registry change to all array members to ensure consistent Group Policy process across the entire array.

As normal, the problem was not actually caused by ISA Server, but by the surrounding network infrastructure. It might have been nice if the back firewall administrator had told me about this ICMP limitation from day one, but they likely didn't even know :)

Hope this helps someone else with a similar problem…

How to Clear the Change Tracking Log in ISA Server 2006 SP1

For reasons I won’t go into, I recently wanted to clear the Change Tracking log and remove all previous entries from the list. There appeared to be no obvious way to achieve this in the GUI(probably for good reason) but I wanted to share with the community how it can be achieved anyhow…

So, below we can see our example Change Tracking log full of entries we no longer need. This can be seen by looking at the Change Tracking tab under the Monitoring node:

changetracking1

Clearing the log then involves two simple steps…

Step 1: Modify Existing Change Tracking Limit

Below is a screenshot of the default Change Tracking configuration:

changetracking 

This needs to be reconfigured as follows:

For Standard Edition

  • In the console tree of ISA Server Management, expand Microsoft Internet Security and Acceleration Server 2006, expand the <Server Name> node, and then click Monitoring.
  • Select the Change Tracking tab.
  • From the Tasks tab, click Configure Change Tracking.
  • Change the default entries limit set from 1000 (the default) to 0. If you have a value different to 1000, change this to 0 anyhow.
  • Click OK to close the Change Tracking window.
  • Click the Apply button in the details pane to save the changes and update the configuration.

For Enterprise Edition

  • In the console tree of ISA Server Management, expand Microsoft Internet Security and Acceleration Server 2006. Right click the Enterprise node and select Properties.
  • Select the Change Tracking tab.
  • Change the default entries limit set from 1000 (the default) to 0. If you have a value different to 1000, change this to 0 anyway.
  • Click OK to close the Enterprise Properties window.
  • Click the Apply button in the details pane to save the changes and update the configuration.
Please Note: If you are using Enterprise Edition, you will need ISA Server Enterprise Administrator permissions to make the above changes.

We should then have:

changetracking2

Step 2: Restore Original Change Tracking Limit

In order to restore the original Change Tracking limit, we simply reverse the procedure defined above:

For Standard Edition

  • In the console tree of ISA Server Management, expand Microsoft Internet Security and Acceleration Server 2006, expand the <Server Name> node, and then click Monitoring.
  • Select the Change Tracking tab.
  • From the Tasks tab, click Configure Change Tracking.
  • Change the default entries limit set from 0 to 1000 (the default). If you previously had a value different to 1000, restore the original value.
  • Click OK to close the Change Tracking window.
  • Click the Apply button in the details pane to save the changes and update the configuration.

For Enterprise Edition

  • In the console tree of ISA Server Management, expand Microsoft Internet Security and Acceleration Server 2006. Right click the Enterprise node and select Properties.
  • Select the Change Tracking tab.
  • Change the default entries limit set from 0 to 1000 (the default). If you previously had a value different to 1000, restore the original value.
  • Click OK to close the Enterprise Properties window.
  • Click the Apply button in the details pane to save the changes and update the configuration.

We should then be back to the default Change Tracking configuration:

changetracking

If we now look at the Change Tracking tab under the Monitoring node we should see the following:

changetracking4

So, there we go, a nice blank change tracking log in two easy steps – simple! ;)

Please Note: For Enterprise edition, the above procedure assumes Change Tracking is enabled at the ISA Server enterprise level and will consequently clear all array-level Change Tracking logs at the same time. If you have change tracking enabled at the array-level only, and want to clear a single array Change Tracking log, this can be done by applying the same concept to the array object as opposed to the entire ISA Server enterprise.

If you prefer a command line approach as opposed to the GUI, it is also possible to clear the log using scripts as detailed here:

Change Tracking - Log Management via Scripts

It is also interesting to note that the upcoming new release of ISA Server, named Threat Management Gateway (TMG), will support an improved Change Tracking feature. Part of this update will include a dedicated API with a ClearLog function. Read more here:

Change Tracking in TMG

Hope this is useful…

Thursday, 13 August 2009

‘Error Code: 500 Internal Server Error. An internal error occurred. (1359)’ Error when Using ISA Server 2006 Web Farm Publishing

On a very similar theme to my last blog entry, this is another cryptic error I have seen quite a few times when using Web Farm publishing solutions. An example screenshot of the error is shown below:

Web Farm Unavailable

In my experience, this error is generated when a publishing rule is configured to use server farm publishing and all farm members are unavailable or unreachable.

If you look at the ISA Server alerts whilst receiving this error, you should notice a corresponding alert titled Web Farm Servers Unavailable with a description of: A Web publishing rule stopped forwarding requests to a Web farm because there are currently no servers in the Web farm that can accept requests.

So, easy when you correlate the browser error with the ISA alert, but again, not the most useful or informative error message for a user to receive…

Please Note: This error will only be shown after authentication; assuming you are following good security practices and pre-authenticating users at the ISA Server level, of course ;)

I hope this was useful…

‘106: The Web server is busy. Try again later.’ Error when Using RSA SecurID Enabled HTML Forms Authentication

I have come across this error quite a few times now and haven’t seen it officially documented (that I know of). Here is a screenshot of the error when using an Outlook Web Access publishing rule.

RSA SecurID Error

The error is pretty generic (read cryptic!) and doesn’t really explain the actual problem. You would assume from the error text that there is a problem with the published web server; from experience, that is not the problem at all!

In fact what this error should say is “Cannot connect to the RSA Authentication Manager server(s) at this time.” or something similar. In my experience, this error is often shown for one of two reasons.

Firstly, if you configure a web listener to use RSA SecurID authentication and you have not correctly installed the sdconf.rec file, then you will receive this error. As discussed in the documents referenced at the end of this blog entry, the sdconf.rec file needs to be placed in the %Program Files%\Microsoft ISA Server\sdconfig folder for correct operation.

Secondly, even with a correctly installed sdconf.rec file, you may still experience this error if the ISA Server is not able to connect to the RSA Authentication Manager servers defined within the sdconf.rec file. This is normally a pure communications or access issue between the ISA Server and the RSA Authentication Manager servers themselves.

Looking at the comment text in the HTML Forms strings.txt file, we can see the following statement:

ACE/Server is not responding error, we do not tell users about it, the administrator knows from the event log.

Consequently, it would appear that this error is purposefully generic for some reason. An obvious next step (well, to my thinking) is to modify the text to be a little more informative. However the error text string is located in the Microsoft ISA Server 2006 internal strings section of strings.txt which should not be edited, as recommended by Microsoft.

A good overview of the process to configure ISA Server with RSA SecurID authentication can be found in the following documents.

RSA Documents:

RSA SecurID Implementation Guide for ISA Server 2006

Microsoft Documents:

Authentication in ISA Server 2006

Walk-through for RSA SecurID Authentication for ISA Server 2006 - Part-1: RSA Authentication Manager Server Configuration

Walk-through for RSA SecurID Authentication for ISA Server 2006 - Part-2: ISA Array Members Preparation

Walk-through for RSA SecurID Authentication for ISA Server 2006 - Part-3: Configure ISA Authentication and Delegation 

So, easy when you know how, but again, not the most useful or informative error message for a user to receive…

I hope this was useful…

Monday, 13 July 2009

Requesting ISA Server Certificates from a Windows Server 2008 Certificate Authority

If you have deployed your own internal PKI solution based upon Microsoft Certificate Services, there are several scenarios where you may want to issue certificates to the ISA Server computer, or individual array members if you are using Enterprise Edition. These certificates might be for use with internal web listeners, VPN services or even to support system management applications like the System Center Configuration Manager (Native Mode) agent.

Due to the limitations imposed by the ISA Server RPC filter on certificate requests (because they use RPC DCOM which is blocked by ISA Server system policy by default) it is common place for certificates enrolment using the certificate services MMC or autoenrollment to fail on ISA Server computers. Therefore, submitting certificate requests via web enrolment has been a useful way to achieve this process directly from the ISA Server computers (or array members) themselves.

However, as discussed in KB922706 titled How to use Certificate Services Web enrollment pages together with Windows Vista or Windows Server 2008, several useful features have been deprecated when using Windows Server 2008 Active Directory Certificate Services web enrolment or Windows Server 2003 Certificate Services web enrolment with KB922706 installed.

The most notable (and relevant to this blog entry) of these changes is the lack of support for automatically installing a computer certificate in the local computer store via the web enrolment interface. This is discussed in the extract below:

The Windows Vista certificate enrolment client component has been enhanced over that of earlier versions of Windows. Some of the functionality that was formerly accessed by using Web pages is now included in the client component. Therefore, this functionality has been removed from the updated certificate enrolment Web pages. Functionality that has been removed includes the following:

  • Computer certificate enrolment: Administrative rights are required to request a computer certificate. In Windows Vista, Microsoft Internet Explorer does not use administrative rights to run. Therefore, the option to store a computer certificate in the computer store was removed from the Windows Server 2008 certificate enrolment pages.

The net result of this change is that it is no longer possible to request computer certificates and place them in the local computer certificate store using the web enrolment interface

Consequently, you need to consider an alternative way of requesting certificates. Although it is possible to use the MMC with the Certificates snap-in (as covered in Adrian’s blog here) many certificate template enrolment permissions are based upon a user security context, as opposed to a computer context. Hence you need to start changing enrolment permissions by adding computer object permissions, which is not always ideal.

The remainder of this article is therefore split into the following sections:

  • Preparing the Firewall Policy
  • Generate, Submit and Install the Certificate Request

So, here goes…

Preparing the Firewall Policy

Rather than re-invent the wheel, it makes more sense to point readers to an existing article which covers the process of defining a firewall policy which allows certificate requests from the ISA Server computer itself.

The required firewall policy changes are covered very well in the Certificate Enrollment Requires a Custom Protocol blog entry by Stefaan Pouseele. The remainder of this blog entry assumes that you have successfully completed the firewall policy changes as described above (or in a similar fashion with a slightly more open policy).

Generating the Certificate Request

Assuming we have the required firewall policy in place, we can now concentrate on the actual certificate enrolment process. In order to perform this, we need to use the command line tool called certreq.exe. The first step in using this tool is to create an input file to define the required certificate properties.

[NewRequest]
Subject = "CN=<your-certificate-common-name>"
MachineKeySet = True
KeyLength = 2048
KeySpec=1
[RequestAttributes]
CertificateTemplate = WebServer

At this point, it is probably useful to explain some of the above entries in the input file for clarity:

The Subject parameter is used to define the actual common name of the certificate. Depending on certificate use, this would normally be the actual name of the ISA Server computer or the name that will be entered into a web browser if considering a web published application. Choose an appropriate entry for the <your-certificate-common-name> placeholder shown in the example above.

The MachineKeySet parameter is used to when you need to create certificates that are owned by the machine and not a user. You must set this key to TRUE if you are creating requests for domain controllers, a Web server, or any other service that runs in the machine’s security context. Hence in our example this is set to true.

The KeyLength parameter is used to define the length of the public and private key. Ultimately, the key length has an impact on the security level of the certificate. A Windows Server 2008 Web Server certificate template has a default key length requirement of 2048 bits, however our Windows Server 2003 client will default to 1024 bits. Therefore, we need to define a KeyLength of 2048 to avoid receiving a The public key does not meet the minimum size required by the specified certificate template 0x80094811 error.

The KeySpec parameter is used to define that the private key uses both encryption and signing (which is a standard TLS requirement).

The CertificateTemplate parameter is used to instruct the CA as to which certificate template should be used in processing the certificate request. The name must be specified as the common name of the certificate template or the object identifier of the template, not the template display name. Hence in our example this is WebServer.

Submit the Certificate Request

Once the above text file has been created in notepad (or similar text editor) it should be saved. In our example I have used isaserver.inf

Once saved, the next step is to use certreq to transform this file from an input file to a specific certificate request file. This is achieved using the following command:

certreq –new isaserver.inf isaserver.req

With the request file created, we can then submit the request to the CA using the following command:

certreq –submit isaserver.req isaserver.cer

Please Note: Prior to submitting the certificate request, it is important to validate that the logged on user account has Read and Enroll certificate template permissions for the relevant certificate template. If not, these permissions must be added prior to submission. This whole process also assumes that the ISA Server computer is a member of the domain.

Once you have entered this command, you will be prompted to select the issuing CA in the Select Certification Authority dialog box. Select the relevant CA for your environment, and then click OK.

When the certificate has been issued, you see a RequestId: <number> in the output results; this will be needed for the next step.

Please Note: If your certificate template is configured with the CA certificate manager approval option enabled, it will be necessary to approve the certificate request (identified by the RequestID) using the Certificate Authority snap-in, before continuing.

Install the Certificate Request

So, with the RequestID known, enter the following command:

certreq –retrieve <number> isaserver.cer

Finally, to install the certificate into the local computer certificate store, enter the following command:

certreq –accept isaserver.cer

The ISA Server computer is now provisioned with a certificate suitable for use on the web listener (and potentially other uses).

Please Note: If using ISA Server Enterprise Edition, it may be necessary to repeat the above process on all array members.

The above process is particularly useful when using a certificate template that has been configured with the Allow private key to be exported option disabled. In this scenario, the above process is ideal as it stores the certificate directly into the local computer certificate store, thereby negating the need for any form of export/import procedure. In addition, by changing the CertificateTemplate parameter in the certreq input file, it is also possible to request a different certificate use by defining a alternate template name.

So, there we go…hopefully this makes things a little easier and although the use of certreq looks a little daunting to those who haven’t used it before, it is actually quite simple in practice. This approach is also preferred by Microsoft, I believe ;)

Tuesday, 19 May 2009

Using the ADAM Sites Tool with ISA Server 2006 Enterprise Edition

After doing a little research for one of my previous articles, it became apparent that there was very little guidance on the use of the ADAM Sites Tool apart from the default Word document that is included within the AdamSitesPack.exe archive that is available from here.

Based upon the concepts involved, I think that a working example is probably the best way to provide an overview of the necessary steps involved. This will allow people to move away from the default single site topology used by ADAM when using ISA Server Enterprise Edition, and explore the potential for a more suitable multi-site topology.

Although there is nothing actually wrong with the default single site topology used by Enterprise Edition, it does assume that all Configuration Storage Servers are ‘well connected’. Consequently, it does not factor in network bandwidth, network connectivity or any geographical boundaries that may exist. Therefore, this ‘well connected’ model is not necessarily the most optimum solution, and can be potentially improved upon in many cases.

Using the example environment covered from my previous blog entry titled ISA Server 2006/2004 Configuration Storage Server Frequently Asked Questions we have the following:

image4

Key features of this Configuration Storage Server design include:

  • A single, global ISA enterprise is used across all locations. This enterprise contains three arrays; one for each data centre location.
  • Dedicated Configuration Storage servers are used in each data centre location.
  • Configuration Storage servers are located local to the array members themselves.
  • Alternate Configuration Storage servers are located at each data centre to provide fault tolerance in the event of primary Configuration Storage server failure.

So, assuming we have varying degrees of connectivity between the data centres, it may actually be more beneficial to configure each location as a dedicated ADAM site.

With separate sites, it is then possible to configure inter-site replication with appropriate costs and replication intervals to better control replication traffic. The aim of the new design is to reduce unnecessary replication and also minimise bandwidth usage for ISA enterprise replication traffic.

So, who do we go about achieving this then? Well, we need to perform four main tasks:

  • Create ADAM Sites
  • Create ADAM Site Links
  • Move Configuration Storage Servers
  • Replicate Configuration Changes

Create ADAM Sites

Firstly, we need to define the new sites. Generically this can be achieved using the following command:

adamsites site create <Site Name>

Please Note: For the purposes of this article, all commands are being entered on the same Configuration Storage Server, namely LONCSS1.

In our example, this would therefore be achieved using the following commands:

adamsites site create London

adamsites site create Miami           

adamsites site create Singapore

We can verify all sites have been created correctly using the following command:

adamsites sites

This command should produce the following text output:

Site: Default-First-Site-Name
There are six servers in this site.
    LONCSS1
    LONCSS2
    MIACSS1
    MIACSS2
    SINCSS1
    SINCSS2
Site: London
There are no servers in this site. 
Site: Miami
There are no servers in this site.
Site: Singapore
There are no servers in this site.

Create ADAM Site Links

Next, we then need to create the site links that connect sites together, along with defining suitable replication costs and replication interval values that are representative of our example environment. By connecting sites, Configuration Storage Servers at each site will be able to replicate ISA enterprise changes with each other.

Site links can be created using the following command:

adamsites sitelink create <Sitelink Name> <Count> <Site1> <Site 2> <Site N> <Replication Cost> <Replication Interval>

If we return to our example environment and consider the network topology shown below:

image

This diagram shows the network topology in terms of link speed and connectivity, and provides the key information needed for defining the correct site links and properties.

In order to calculate the replication cost, we can use the following formula referenced for Active Directory site link costs:

 

Replication cost = 1024 x 1/logbandwidth (in Kbps)

 

Using this formula and the figures shown in the above diagram, we can therefore derive the following cost values for each site link:

Site Link

Cost

London-Miami

255

London-Singapore

340

Miami-Singapore

378

If we then think about replication intervals; assuming we are happy to provide replication at least four times a day, we can set the replication interval to every six hours, or 360 minutes.

Based upon these values, we can therefore use the following commands to create the necessary site link objects:

adamsites sitelink create London-Miami 2 London Miami 255 360

adamsites sitelink create London-Singapore 2 London Singapore 340 360

adamsites sitelink create Miami-Singapore 2 Miami Singapore 378 360

We can verify all site links have been created correctly using the following command:

adamsites sitelinks

This command should produce the following text output:

Site Link: DEFAULTIPSITELINK
        Cost:100
        Replication Interval:180
        Description:CN=DEFAULTIPSITELINK
        Sites:
                Default-First-Site-Name
Site Link: London-Miami
        Cost: 255
        Replication Interval:360
        Description:CN=London-Miami
        Sites:
                Miami
                London
Site Link: London-Singapore
        Cost: 340
        Replication Interval:360
        Description:CN=London-Singapore
        Sites:
                Singapore
                London
Site Link: Miami-Singapore
        Cost: 378
        Replication Interval:360
        Description:CN=Miami-Singapore
        Sites:
                Singapore
                Miami

Move Configuration Storage Servers

With the necessary sites and site links created, the next step is to move the Configuration Storage Servers from the Default-First-Site-Name site to their respective new site locations.

Configuration Storage Servers can be moved using the following command:

adamsites moveserver <Configuration Storage Server Name> <Old Site> <New Site>

Therefore, for our example environment this is achieved using the following commands:

adamsites moveserver LONCSS1 Default-First-Site-Name London

adamsites moveserver LONCSS2 Default-First-Site-Name London

adamsites moveserver MIACSS1 Default-First-Site-Name Miami

adamsites moveserver MIACSS2 Default-First-Site-Name Miami

adamsites moveserver SINCSS1 Default-First-Site-Name Singapore

adamsites moveserver SINCSS2 Default-First-Site-Name Singapore

We can verify all Configuration Storage Servers have been moved correctly using the following command:

adamsites sites

This command should produce the following text output:

Site: London
There are two servers in this site.
    LONCSS1
    LONCSS2
Site: Miami
There are two servers in this site.
    MIACSS1
    MIACSS2
Site: Singapore
There are two servers in this site.
    SINCSS1
    SINCSS2

Replicate Configuration Changes

Finally, it is necessary to replicate the configuration changes to all other Configuration Storage servers throughout the enterprise. Unfortunately, the ADAM Sites tool will not perform this replication task for you and requires the use of the repadmin utility.

Please Note: It is important to use the repadmin.exe utility that is located in the %WINDIR%\ADAM\ directory. It is therefore recommended to change the current directory to this directory prior to executing the above commands.

Generically this can be achieved using the following commands:

For intra-site replication:

repadmin /syncall <Configuration Storage Server Name>:<Configuration Storage Server Port Number>

For inter-site replication:

repadmin /replicate <Source Configuration Storage Server Name>:<Configuration Storage Server Port Number> <Destination Configuration Storage Server Name>:<Configuration Storage Server Port Number> CN=Configuration,CN=<GUID>

Assuming that the ADAM Sites Tool commands defined above have been entered on the LONCSS1 Configuration Storage Server, intra-site replication can be initiated using the following command:

repadmin /syncall LONCSS1:2171

The repadmin /syncall command should result in the following text output: 

CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

However, in order to cater for inter-site replication, we need use a slightly more complicated command which contains a globally unique identifier (GUID) which is unique to each ISA Server Enterprise deployment and forms part of something called the Naming Context. In order to obtain this GUID for your own environment, the following generic command can be used:

repadmin /showrepl <Configuration Storage Server Name>:<Configuration Storage Server Port Number>

Using LONCSS1 as an example, this will result in the following text output:

==== INBOUND NEIGHBORS ======================================

CN=Configuration,CN={GUID}
    London\LONCSS1$ISASTGCTRL via RPC

The placeholder define above as {GUID} will actually be a hexadecimal value similar to this: 999BC56F-C65E-4472-9EDE-215BD5515B61.

With this GUID known, we can now use the following command to initiate an inter-site replication from London to Miami:

repadmin /replicate loncss1:2171 miacss1:2171 CN=Configuration,CN={999BC56F-C65E-4472-9EDE-215BD5515B61}

and for inter-site replication from London to Singapore:

repadmin /replicate loncss1:2171 sincss1:2171 CN=Configuration,CN={999BC56F-C65E-4472-9EDE-215BD5515B61}

Each repadmin /replicate command should result in the following text output: 

Sync from <Source Configuration Storage Server Name>:2171 to <Destination Configuration Storage Server Name>:2171 completed successfully.

UPDATE: Many thanks to Pepito for providing clarification on the use of repadmin for ADAM inter-site replication.

With the inter-site replication completed, the final step is to initiate intra-site replication for Miami and Singapore to update the remaining Configuration Storage Servers. This can be achieved using the following commands:

repadmin /syncall MIACSS1:2171

repadmin /syncall SINCSS1:2171

Each repadmin /syncall command should result in the following text output: 

CALLBACK MESSAGE: SyncAll Finished.
SyncAll terminated with no errors.

With all the above commands completed successfully, we have now replicated changes to all six Configuration Storage Servers, in all three sites.

So, we now have a custom site link design which properly supports the network characteristics of the example environment and provides a more optimum ISA Server enterprise replication model. This new replication model now includes the use of of both intra-site and inter-site relationships, in addition to the use of customised costs and replication intervals that match the exact needs (and constraints) of the example environment.

I hope this working example proves useful for those looking at deploying ISA Server Enterprise Edition where the default single site model is not the preferred, or most optimum, solution.

Monday, 20 April 2009

ISA Server 2006/2004 Configuration Storage Server Frequently Asked Questions

Most of my ISA Server deployments seem to be based around Enterprise Edition nowadays, which is a good sign that more Enterprise customers are starting to see the benefits of ISA Server as an advanced application-layer firewall. As I use Enterprise Edition regularly, it is easy to forget that many of the concepts that I take for granted are actually quite new to people who are more in tune with ISA Server Standard Edition. The ISA Sever Enterprise Edition integrated NLB feature is a good example here and why I wrote the NLB resource guide provided here, as many people seemed to struggle with this particular area. Another area that has been raising a few questions on the forums lately is that of Configuration Storage server design and general concepts. A lot of the information available from Microsoft is provided as part of the ISA Server 2004 product documentation set, and hence is often missed by people looking at the ISA Server 2006 documentation. Very little has changed (if anything) in terms of Configuration Storage servers between the two versions, so all of this existing documentation is still hugely valid, yet often overlooked.

Please Note: Threat Management Gateway (TMG), the latest incarnation of ISA Server, is only just around the corner now. However, I think ISA Server 2006 will be around for some time yet (especially as it is the latest version of ISA Server to be Common Criteria certified) and hence a good understanding of the key concepts for this version will still be of value to many people.

As with the NLB Resource Guide, I have created this article in a ‘FAQ style’ as I think this is a good readability format (tell me if it’s not!) but which also allows me to answer forums posts with “…go read Question #” answers, where applicable.

Anyhow, let’s get started!

Question 1: What is a Configuration Storage server?

A Configuration Storage server is used to store the configuration data for the ISA enterprise, which includes array data for all arrays within the ISA enterprise. The Configuration Storage server uses Active Directory Application Mode (ADAM) as the technology of choice for this data storage.

There can be multiple Configuration Storage servers in the enterprise, each holding an exact replica of the enterprise configuration, which also includes all array data.

Array members communicate with the Configuration Storage server to get up-to-date configuration information. Each ISA Server array member has a local copy of its configuration that is a replica of the configuration stored on the CS role – this replica is stored locally in the registry as a local ‘cached copy’.

Each array points to a specific primary Configuration Storage server from where it gets the latest configuration. You can also specify an alternate Configuration Storage server, which is used when case the primary Configuration Storage server in unavailable for any reason.

It should be noted that the Configuration Storage server doesn't provide any other services apart from storage (and replication) of the enterprise configuration data. It is sometimes thought that the Configuration Storage server provides some form of authentication service (similar to Microsoft IAS) but this is not the case. It’s an important role in the architecture, but ultimately, quite a simple one! :)

Please Note: It is not possible ‘connect’ different ISA enterprises in the same way that you can with Active Directory forest trusts. Consequently, the enterprise boundary needs to be considered to ensure that the entire system can be managed from a single management console; this is one of the primary reasons for choosing Enterprise Edition after all. In reality, it is sometimes actually beneficial to have separate enterprises. Due to their inherent isolation, they obviously present a good security boundary, so can be useful when organisation wish to completely separate the administration model or locate the array members in a highly-secure environment – for example, maybe the solution will be deployed into a hosted environment and managed by a third party…

Question 2: How many Configuration Storage servers should I install?

There are many things to consider when planning how many Configuration Storage servers are required, like:

  • How many do I need?
  • Where should they be located?
  • How should they be configured?

These include elements like network speed, need for reliability, and the number of ISA Server array members that will connected to the Configuration Storage server. As a single Configuration Storage server is able to support approximately 40 array members, this is not normally a major design driver in all but the largest of deployments.

In a highly-connected network, the number of Configuration Storage servers is normally determined by the number of arrays and the required level of fault tolerance for each array. Just like a domain controller, the Configuration Storage server should ideally be located in close proximity to the array members to minimise network traffic and potential connectivity issues.

In order to implement Enterprise Edition, you need at least one Configuration Storage server; however in order to provide redundancy for this vital role, it is recommended to use a minimum of two servers. This ensures that in the event of failure of the primary Configuration Storage server, it will still be possible to manage the enterprise using an alternate Configuration Storage server.

Please Note: The use of two, or more, Configuration Storage servers assumes that they are domain joined (this is covered in more detail in Question 14).

If you only plan to deploy a single array within the enterprise, it would not normally be necessary to deploy more than two Configuration Storage servers, as it is only possible to define primary and alternate Configuration Storage servers (e.g. two in total) for a single array. The exception to this would be some form of warm-standby Configuration Storage server (or servers) that could be located at a secondary location in the event of a disaster recovery scenario.   

Question 3: Where should the Configuration Storage server be installed?

This question is often debated, but the best recommendation is to install the Configuration Storage server role on dedicated member servers.

Yes, you can co-locate the role onto existing servers, or even install it on the actual array members themselves, but you should only really do this if you are happy to accept the associated risks of co-location (this is covered in more detail in Question 5) or you cannot use dedicated servers due to budget/cost constraints. 

In high-security deployments I have sometimes installed the Configuration Storage server on dedicated servers in their own ISA Server protected network (an ISA perimeter network, or DMZ, if you will). This ensures that all connectivity to the Configuration Storage server is protected by the ISA Server array itself (even from “trusted” internal networks) and provides a good threat mitigation model for such vital servers.

Deployment considerations are also discussed in the topic Configuration Storage Server Deployment Guidelines in this document.

Question 4: So, what does a typical Configuration Storage design look like then?

Well, there is never anything “typical” in the world of IT, but lets try and pick a suitable multi-site example environment.

Consider an organisation with three data centres located globally, let’s say London, Miami and Singapore. All three data centres are connected by fast private network links using MPLS. Let’s assume ISA Server will be deployed at all three data centres as an edge application-layer firewall. A likely design for this environment is shown below:

image 

Key features of this design include:

  • A single, global ISA enterprise is used across all locations. This enterprise contains three arrays; one for each data centre location.
  • Dedicated Configuration Storage servers are used in each data centre location.
  • Configuration Storage servers are located local to the array members themselves.
  • Both primary and alternate Configuration Storage servers are located at each data centre to provide fault tolerance in the event of Configuration Storage server failure.

Assuming that London is the primary data centre and hardware cost constraints limited the solution to single dedicated servers in the other data centres, it would also be feasible to configure the Miami and Singapore arrays to define the alternate Configuration Storage servers as LONCSS1 and LONCSS2, respectively. This provides an improved level of fault tolerance for Miami and Singapore through the use of failover to remotely located Configuration Storage servers. Consequently, the design could look like this:

image

The first model provides a better availability model, but this ‘diluted’ model is still viable and would save the cost of two additional servers. However, there is obviously a stronger dependency on the intra-data centre network connectivity with this model, which may need consideration…

Question 5: What issues do I need to consider if I install the Configuration Storage server role on array members when using NLB?

Installation of the Configuration Storage server on array members is a supported configuration, but often not recommended, as discussed in Question 4. When using this deployment model with multi-homed array members and NLB, it is recommended to make changes to ensure correct and stable operation of the Configuration Storage server. These changes are discussed within Question 9 of my NLB FAQ which can be found here. A quick synopsis is provided below:

Yes, if you are using Windows based authentication for intra-array credentials.
In the event that the CSS role has been installed on the actual array members (although this is not recommended as best practice) it is necessary to make several changes before NLB can be enabled on any of the array networks. These changes are necessary due to the use of Kerberos based authentication between array members and the CSS role which necessitates the use of correct Service Principal Names (SPNs). If these SPN changes are not made, a request to connect from an array member to the Configuration Storage server may fail.
The required configuration to regain normal operation is provided in the Multiple Network Adapters and NLB section of this document Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration (ISA) Server 2006

Question 6: What happens when the primary Configuration Storage server is not available?

By default, each array member polls its current Configuration Storage server for configuration changes every 15 seconds (the default polling time). If the primary Configuration Storage server is unavailable for 30 minutes (the default fallback delay), the array member switches to the alternate Configuration Storage server (assuming one has been defined).

After using the alternate Configuration Storage server for six hours (the default primary testing delay), the array member periodically tests for connectivity with the primary Configuration Storage server. After the primary Configuration Storage server is continuously available for 10 minutes (the default primary stabilisation time), the array member then switches back to the primary.

This entire process is completely automated and transparent, hence you will normally only be aware of it happening if you attempt to use the ISA Management console connecting to the failed Configuration Storage server or look at the alerts tab regularly (of course you do!). For those with SCOM/MOM, you should also receive alerts via the SCOM/MOM console if you are using the ISA Server management pack; assuming you are not using ISA Server 2006 Service Pack 1 that is, because this broke the SCOM management pack…poor show guys :(

Question 7: What happens when both the primary and alternate Configuration Storage servers are not available?

If both the primary and the alternate Configuration Storage servers fail, the ISA Server Management console will not provide access to any ISA Server functionality, because it requires a connection to a working Configuration Storage server. At the same time, the ISA Server array members will continue to provide firewall, VPN, and proxy services based on the last known configuration that was received from the Configuration Storage server. However, you will not be able to monitor or change any configuration until at least one of the Configuration Storage servers is restored, or until you connect the computer running ISA Server services and the ISA Management console to a different (working) Configuration Storage server in the enterprise.

The key takeaway here is that everything carries on working even when all Configuration Storage servers are unavailable; it’s just that the firewall nodes become temporarily unmanageable from the enterprise. Therefore, they are still diligently protecting your network, if not manageable, which is a good thing ;) 

Question 8: Is it possible to modify the default timeout values for Configuration Storage server failover, fallback and stabilisation?

Yes, this is possible, but not via the ISA Management console. In order to amend the default values, it is necessary to apply changes using a custom VBS script provided by Microsoft.

It is possible to change the following parameters via the script, with the key parameters defined below:

  • FallbackDelay: This property gets or sets the time (in minutes) after which an array member will start using the other Configuration Storage server when the current Configuration Storage server is unavailable. Its default value is 30 minutes, and its range of permissible values is from 1 through 99,999.
  • PrimaryTestingDelay: This property gets or sets the time (in minutes) after which an array member will start testing for connectivity with the primary Configuration Storage server when using the alternate Configuration Storage server. Its default value is 360 minutes (6 hours), and its range of permissible values is from 1 through 99,999.
  • PrimaryStabilizationDelay: This property gets or sets the time (in minutes) during which the primary Configuration Storage server must be continuously available before an array member will reconnect to it. Its default value is 10 minutes, and its range of permissible values is from 1 through 99,999.

Additional information (and the actual script) can be found in the following Microsoft article:

Setting Configuration Storage Server Delay Times

Please Note: Although this article references ISA Server 2004, it is still appropriate for ISA Server 2006.

I always struggle to find this document (yeah I’m useless with bookmarks!) and many people have never even seen it from what I can tell, so I think it is useful to mention it here. 

Question 9: How do I secure (harden) my Configuration Storage server?

Depending upon your chosen Configuration Storage server deployment method, your mileage may vary here. For obvious reasons, it is easiest to secure the server when it is deployed on a dedicated member server that provides no other role or service. The easiest (and most Microsoft supportable) approach is to use the Security Configuration Wizard available as part of Windows Server 2003 Service Pack 1. With an SCW update specifically for ISA Server 2006 applied (from here) the SCW tool is able to understand and define a specific server role based upon the Configuration Storage server function, and consequently configure the dependent services and Windows firewall configuration as necessary for that role.

If the Configuration Storage server is co-located on an existing member server which provide additional server roles, or on the actual array members themselves, then this will need to be factored into the SCW application process.  

Before getting SCW whipped up, it is also important to consider the placement of the server within the network. For example, a Configuration Storage server that is located within an ISA protected network (a dedicated ISA perimeter network maybe) is already isolated against many attacks, subsequently the benefits provided by SCW (or a similar host hardening process) are only going to provide marginal benefit. I not saying you shouldn’t do it as part of an overall defence in depth strategy, but it’s security exposure is already greatly reduced anyhow. However, if the server is placed on an ‘internal’ network that could be potentially dangerous (like a University campus network for example!) then hardening measures will be much more important.

A good starting place when looking at security measures for the Configuration Storage server role is the ISA Server 2006 Security Guide available from here.

Please Note: If there is enough interest, I can probably do a walkthrough article on using SCW for a Configuration Storage server, but it is relatively straightforward to be honest, assuming you know how to drive the SCW tool itself.

Question 10: How do I minimise replication traffic between Configuration Storage servers in the same ISA Server enterprise?

In a highly-connected environment, replication between Configuration Storage servers is often negligible and often best left unchanged. By default, all Configuration servers are installed into as single site; namely the default ADAM site called Default-First-Site-Name. Consequently, there is an assumption that all replication will occur over well connected networks within minimal need to consider bandwidth utilisation and hence aim to optimise traffic flow biased for speed.

However, in certain scenarios, it may be useful to consider the use of ADAM sites and an inter-site replication model (rather than the default intra-site model) for ISA enterprise data. This can be accomplished by creating custom ADAM sites and assigning Configuration Storage servers to individual sites in order to distinguish between different parts of the network. To achieve this, you can use the Adam Sites Tool (AdamSites.exe) available from here to create and configure ADAM sites.

At a high level, this process involves:

  • Use the AdamSites.exe tool to create a site.
  • Use the AdamSites.exe tool to create a site link to connect this site to other sites in the ADAM deployment.
  • Use the AdamSites.exe tool to move the Configuration Storage server to the new site.

So, considering our example detailed in Question 4, this would likely involve a site topology as follows:

image 

The ADAM Sites tool and process is not documented as well as it could be IMHO, and would benefit from a good working example. Hence, I have provided a basic walkthrough (using the example environment above) in my blog article available here.

Please Note: The design of ADAM sites and Configuration Storage servers is analogous to Active Directory sites and domain controllers. Hence a similar design and approach can often be considered if you have a good working knowledge of Active Directory.

Question 11: Why does the ISA Management Console fail to automatically reconnect to the alternate Configuration Storage server?

Unlike the firewall service, the ISA Server Management console is configured to reference a specific Configuration Storage server. Hence in the event that this server is not available, it is necessary to manually reconfigure the console to use an alternate Configuration Storage server. 

Question 12: What hardware specification is required for the Configuration Storage server?

In general, the Configuration Storage server does not require a particularly powerful server. An entry level server with a single core 2GHz+ processor and 1 GB RAM is normally sufficient to support approximately 40 array members; hence this often fulfils most requirements.

In my experience, there are no real disk subsystem requirements apart from the sensible use of data redundancy with something like RAID1.

Virtualise me? :) The Configuration Storage server is also an ideal candidate for virtualisation if you run VMware ESX or Microsoft Hyper-V virtualised environments. It’s virtual resources overhead is normally pretty low too.

Question 13: What should I do if my Configuration Storage server is stolen?

The Configuration Storage server and each array member contain encrypted, confidential information about the other array members and about the ISA Server enterprise. The array member also has a private/pubic key pair that is used to decrypt the information. For this reason, if a Configuration Storage server (or an array member for that matter) confidential information about all the array members is potentially at risk. The key items to consider include:

  • Modify all confidential information on all the other array members. Confidential information includes user credential passwords (for example, used for logging on to a computer running SQL Server), Remote Authentication Dial-In User Service (RADIUS) shared secrets, or preshared Internet Protocol security (IPSec) keys.
  • Revoke any certificates that were installed on the stolen server. These certificates can be certificates that were installed on array members for Web publishing or site-to-site VPN authentication etc.
  • In addition, when a Configuration Storage server is stolen and there is a replica Configuration Storage server configured, the stolen Configuration Storage server should be removed from the ADAM server configuration as a replica set using the RepAdmin tool.

Question 14: Should my Configuration Storage server be domain joined?

This is another often debated question and closely linked to a similar question of “Should my ISA Server array members be domain joined?”. Tom Shinder does a great job of covering the key reasons for domain joining ISA Server here which includes consideration of the Configuration Storage server role too. To summarise the key issues specifically related to Configuration Storage servers:

  • When deployed in workgroup mode, it is only possible to implement a single Configuration Storage. This architecture obviously provides a poor level for fault tolerance. The Configuration Storage servers provide a vital role in the ISA Server Enterprise architecture and subsequently need to be designed to provide fault tolerance in the event of server failure.
  • When deployed in workgroup mode, it requires the use of local accounts which are unmanaged; often with non-expiring passwords :(
  • When deployed in workgroup mode, server certificates are required on Configuration Storage servers and an associated PKI trust model needs to be in place. This is often much harder (for most ISA admins) to achieve than it sounds ;)

Please Note: Workgroup mode is the name given to a non-domain joined deployment.

Consequently, I would recommend that all Configuration Storage servers are domain joined at all times and this is my personally preferred deployment model.

Question 15: What should I consider if my Configuration Storage server is installed on an Active Directory Domain Controller?

Although not ideal, it is possible in certain scenarios to deploy a Configuration Storage server on a Domain Controller role.  Although installation of ISA Server array members on a Domain Controller is not supported, installation of the Configuration Storage server role is supported. In this scenario, it is necessary to consider the following aspects:

  • Configure the Configuration Storage server service (ISASTGCTRL) to run under the context of a dedicated service account which has user level permissions.
  • Amend Domain Controller object permissions to allow SCP registration. This greatly reduces event log noise (Event ID: 2537) from failed SCP registrations.
  • Amend Domain Controller objects to provide Generate Security Audits permission. This again greatly reduces event log noise (Event ID: 2521) of failed auditing alerts.

These areas are covered in the excellent blog entry article here.

Question 16: What do I do if neither of my primary and alternate Configuration Storage servers are available and they are going to be offline for some time?

When faced with this scenario, it is often necessary to deploy a new configuration server and restore the entire enterprise configuration. However, as the array members cannot connect to a Configuration Storage server, it is not possible to update the array properties to define the replacement Configuration Storage server (a nice catch 22!). In order to solve this problem, it is possible to use a custom VBS script which is provided by Microsoft on the ISA Server CD. This script is called ChangeStorageServer.vbs and more information is available in the Configuration Storage Servers are Not Accessible section of this document.

Question 17: Where can I find more information on Configuration Storage server related deployment guidelines, troubleshooting and security?

The following handy documents (in addition to this FAQ, of course!) should help…

Deployment Guidelines for ISA Server 2004 Enterprise Edition

Troubleshooting Configuration Storage Servers in ISA Server 2004 Enterprise Edition

ISA Server 2006 Security Guide

Transferring Configuration Storage Server FSMO Roles

Right, I think that is a good array (excuse the pun!) of questions for now which hopefully should answer most of the common queries for people moving to ISA Server 2004/2006 Enterprise Edition for the first time.

Saturday, 4 April 2009

Important Update on the Expected Release Date of Threat Management Gateway (TMG)

I don’t often blog news information, but it was recently announced on the Forefront Front Team blog here that the next version of ISA Server, now named Threat Management Gateway (TMG), is planned for release in Q4 of this year (2009).

The blog post also provides more information on expected release dates of the upcoming Microsoft Forefront “Stirling” integrated security suite, which has been moved out to early 2010 to allow for better 3rd party interoperability and improved zero-day attack protection.

So, it looks like Christmas may come a little earlier this year for people who are eagerly awaiting the next incarnation of Microsoft ISA Server (like me!), and the benefits that the new version will bring to the security market…

Additional Forefront information can be found here: http://blogs.technet.com/forefront/default.aspx

Friday, 20 March 2009

Firewall/System Policy Documentation Tool for ISA Server 2004/2006 (ISAInfo2XLS Viewer)

A commonly revered part of any ISA Server installation is that of documenting the final solution, especially if this involves a complex firewall policy. After trying to document a few Enterprise Edition customer installations which contained several hundred firewall policy rules, it became apparent that we could do with some form of documentation utility or tool. This tool would aim to capture the key rule information and output this into a nice looking format and/or allow it to be stored electronically for future support purposes. 

Rather than create an application from scratch, it made sense to start with the ISAInfo tool, as this provides an XML output which contains all of the raw ISA Server configuration information, including firewall and system policy rules.

After a bit of internal brainstorming, we realised that developing a completely new application to translate data from the ISAinfo XML file into an appropriate format was going to take quite some time. Hence, we decided it would make more sense to modify the display format that is provided with the original ISAInfo Viewer (ISAInfo.hta) in order to manipulate the output. I say “we” here, but I really mean “he” as full kudos for the actual development work goes to one of my esteemed Silversands colleagues, David Hughes, who did the actual development work. I was merely responsible for the inspiration, testing and tea making :)

With this approach in mind, David looked at the default ISAInfo.hta viewer in order to understand what changes would be necessary. The ‘problem’ with the default ISAInfo viewer is that the results are formatted for readable screen output. Hence, if you copy and paste the data, it is not really in an ideal format and requires quite a bit of manipulation to achieve something satisfactory (if you paste it directly into Word for example).

Therefore, by modifying the display format into data that is more copy and paste friendly, like comma separate values (CSV), we greatly improve our chances of obtaining the information in a much more suitable form. The choice of CSV is also an ideal data format for importing into Excel, and this provides an excellent document format for the firewall/system policy rules data.   

So after amending the ISAInfo.hta as necessary, we now have a new ISAInfo viewer called ISAInfo2XLS.hta which outputs firewall and system policy information into an onscreen CSV format. Well, to be precise it’s actually a pipe character “|” separated value format really (PSV), but close enough! A copy of the customised viewer can be downloaded from here.

Please Note: The original ISAInfo.hta file is based upon version 1.0.2161.23 dated 19/07/2007 which is available as part of the ISAInfo.zip archive available from Jim Harrison’s www.isatools.org website here.

In order to understand the entire process of using the customised viewer, I have put together the following procedure with some sample screenshots and a quick walkthrough.

Generate the ISAInfo XML Output

Lets start with an example firewall policy as shown below. This contains a web publishing rule, a server publishing rule and an access rule:

fwdoc1

In order to dump the configuration information, we need to run the ISAInfo.js utility as shown below:

fwdoc2

One this has completed, we then have an XML output file which can be opened in the ISAInfo Viewer:

fwdoc3

After opening this XML file in the default ISAInfo viewer, we can see the example firewall policy rule details are shown in the right hand pane of the viewer:

fwdoc4

So, this is how things work with the default ISAInfo viewer.

Using the ISAInfo2XLS Viewer

Now, lets look at the display format when we use the ISAInfo2XLS viewer:

fwdoc5

As can be seen, the rule information is now provided onscreen in PSV format. If we highlight this text and copy and paste the data into a notepad text file, we get the following:

fwdoc8

If we now save this text file to a temporary location, we can open it using Excel. Excel with then automatically recognise the text file format and will run the Text Import Wizard.

Please Note: I am using Excel 2007 in my examples, but it should be a similar process with previous versions of Excel.

On Step 1 of the wizard, select the Delimited radio button as our data is in a separated, or delimited, format. Then click Next to continue to Step 2.

fwdoc9

On Step 2 of the wizard, select the Other tick box and enter a pipe character (the vertical line ‘|’ key to the left of the ‘z’ key on UK QWERTY keyboards). Then click Next to continue to Step 3.

fwdoc10

On Step 3 of the wizard, accept the defaults and select Finish.

fwdoc11

You should then see the imported firewall policy rules, as shown below:

fwdoc12 

After a bit of basic formatting we get the following result, which looks great!

fwdoc14

Repeating the above process with a set of System Policy rules results in a more complex, but equally impressive, spreadsheet:

fwdoc17 fwdoc18

So, there you go! You now have an Excel spreadsheet that contains all firewall or system policy rules, and the key top-level information for each rule.

I will be the first to admit that it’s not the slickest or most elegant tool in the world, but hopefully some of you will find it as useful as I have when it comes to documenting firewall and system policies – Enjoy!

UPDATE!

Based upon popular demand, please find an updated version of ISAInfo2XLS.hta now called ISAInfo2XLSv2.hta from here which has been tested with Windows 7, IE9 and Forefront TMG. Many thanks to Richard Knight for his efforts with this update!