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:

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:

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.

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:

 

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:

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:

 

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.

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

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:

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

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

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:

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:

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:

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.

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.

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

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

 

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

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

 

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!

A day in the life of a Forefront MVP…

So, I’m here in Seattle at the Microsoft MVP Summit to meet with the Forefront product group and other similar MVPs. This is a bit of an unusual post, as for a change this is not an article, or best practice discussion, just a simple brain dump of my current mindset.

These are some pretty smart people here who really seem keen to understand and learn what customers want from the Forefront product suite. A lot of information provided is under NDA, which makes it hard for me to share it with the ISA community at large, but there is some interesting stuff in the pipeline to put Microsoft in a very strong, if not unique, position within the IT security marketplace. It also reinforces my view that I need to expand my current ‘Edge’ skill set to include more of the Forefront products, especially the Microsoft “Stirling” offering.

This is my first time at the Summit, as I was only awarded my MVP in October, and this is the first chance I have had to meet with some of the other MVPs and community guys than I have come to know based upon their ‘online personalities’. This is both an exciting and humbling experience for me and the first real opportunity I have had to interact with Microsoft and other MVPs at this level…the experience has been very positive so far and I have tried to ask as many questions as possible to fuel future blog posts and articles.

I am still kind of jet lagged coming from the UK (an eight hour time zone difference to here) to Seattle. However, I am trying to think coherently and formulate questions to make the best of my time here. ‘Sleepless in Seattle’ is no longer just a film for me, but more of what happens when you keep waking up at 3am when your body clock is still on GMT time :)

So, enough rambling, the key question I ask is this; if you were to meet with the Forefront product group, what questions would you ask? I cannot guarantee to get answers (or provide them due to NDA restrictions) but I am curious to know how people perceive Microsoft in the Forefront area and also determine which messages as getting through to the community and which are not.

Now that Microsoft Forefront Threat Management Gateway (TMG) is public beta released, I am sure that people are starting to formulate ideas and opinions, yet it is still early enough within the product lifecycle to provide valuable feedback and ask “Why are you doing it like that…?” or “Why haven’t you added feature XYZ…?”

So, I am keen to hear you views, both positive and negative of course; either drop your comments here on my blog or drop me an email to the usual address.

Resource Guide for Microsoft Active Directory Communications and ISA Server Firewalls

Based upon my work with ISA Server for various implementations, I often have to create firewall policies that permit Active Directory communications to traverse different ISA Server networks.

I thought it would be useful to try and create a quick blog entry that captures some of the key information in order to provide a basic resource guide. This mainly includes the necessary protocol sets that are required for the two most common types of Active Directory communication, namely:

• Domain Member Communications (From Domain Members to Domain Controllers)
• Domain Controller Replication Communications (From Domain Controllers to Domain Controllers)

Please Note: For information on Active Directory communications when using forest trusts, please see my previous blog entry called Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts.

So, considering the first scenario:

Domain Member Communications – Required Protocols

• DNS (53/tcp and 53/udp)
• Kerberos-Adm (UDP) (749/udp)
• Kerberos-Sec (TCP) (88/tcp)
• Kerberos-Sec (UDP) (88/udp)
• LDAP (389/tcp)
• LDAP UDP (389/udp)
• LDAP GC (Global Catalog) (3268/tcp)
• Microsoft CIFS (TCP) (445/tcp)
• Microsoft CIFS (UDP) (445/udp)
• NTP (UDP) (123/udp)
• PING (ICMP Type 8)
• RPC (all interfaces) (135/tcp)

and the second scenario:

Domain Controller Replication Communications – Required Protocols

• DNS (53/tcp and 53/udp)
• Kerberos-Sec (TCP) (88/tcp)
• Kerberos-Sec (UDP) (88/udp)
• LDAP (389/tcp)
• LDAP (UDP) (389/udp)
• LDAPS (636/tcp)
• LDAP GC (Global Catalog) (3268/tcp)
• LDAPS GC (Global Catalog) (3269/tcp)
• Microsoft CIFS (TCP) (445/tcp)
• Microsoft CIFS (UDP) (445/udp)
• NetBios Datagram (138/udp)
• NetBios Name Service (137/udp)
• NetBios Session (139/tcp)
• NTP (UDP) (123/udp)
• PING (ICMP Type 8)
• RPC (all interfaces) (135/tcp)

Please Note: The protocol names defined above are based upon the default display names used in ISA Server, and they may be different for other firewalls. Respective udp/tcp ports are therefore provided in brackets for clarity.

Due to the default behaviour of the ISA Server RPC filter, you can simply use the in-built RPC (all interfaces) protocol and ISA Server will automatically handle the dynamic nature of the RPC protocol and RPC endpoint mapper requests. However, if you are using other firewalls, you many need to replace the RPC (All interfaces protocol with the following two protocols:

• RPC Endpoint Mapper (135/tcp)
• RPC Dynamic Ports (1024-65535/tcp)

Please Note: Alternatively, you may wish to define static port ranges for RPC, as discussed in the follow Microsoft knowledgebase article How to configure RPC dynamic port allocation to work with firewalls.

I have read that it is possible to remove some of the above “less desirable” protocols, Ping/ICMP for example. However, in my experience this can often lead to adverse effects in terms of performance; whereby delays can occur with authentication and Active Directory user/group/computer enumeration. I believe this is due to some form of protocol fallback where you have to wait for a denied protocol (Ping/ICMP for example) to timeout before an alternative protocol (LDAP Ping for example) is tried instead. Hence overall functionality is not impaired, but it is necessary to wait for timeouts to occur, which is not ideal unless absolutely necessary.

Finally, it is recommended to use route-based network relationships between all ISA networks that involve Active Directory communications, as this negates potential issues that can occur when using Network Address Translation (NAT).

A list of appropriate references is provided below for further bedtime reading :)

Active Directory focused:

How to configure a firewall for domains and trusts

Active Directory in Networks Segmented by Firewalls

Active Directory Replication over Firewalls

Domain and Forest Trust Tools and Settings

Service overview and network port requirements for the Windows Server system

Restricting Active Directory replication traffic and client RPC traffic to a specific port

Windows 2000 Resource Kit Tool: Rpccfg.exe (RPC Configuration Tool)

ISA Server focused:

Segmenting Networks with ISA 2004 – Filtering access to Domain Controllers

Allowing Intradomain Communications through the ISA Firewall (2004)

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

So, not exactly ground-breaking information, but hopefully handy for those looking for a concise list of Active Directory related protocols (with associated references) when defining ISA Server firewall policies.

Customising ISA Server 2006 HTML Forms - Part 2: Restructuring the Default RSA SecurID Form

Continuing on from Part 1 of this article series, this article extends the customisation process when using HTML Forms authentication specifically with RSA SecurID.

After using this form myself as an “end user” a feature of the default form stood out immediately in terms of usability:

When using the Collect additional delegation credentials in the form option, the RSA SecurID credentials are presented at the top of the form. Although this seems insignificant at first, this can lead to a frustrating experience for the user when the RSA tokencode is nearing expiry, as it is possible for the tokencode to change as you are typing your Active Directory credentials into the bottom section of the form. This can subsequently lead to authentication errors and annoyed users!

Therefore, this blog entry provides an overview of addressing this issue to provide, in my opinion and from customer feedback, a much better overall user experience.

A great feature of using HTML forms with RSA SecurID is the ability to combine both RSA credentials and Windows (Active Directory) credentials within a single form. The RSA credentials are used to validate the users identify and the Windows credentials are used for ISA Server authentication delegation to the published server. This provides a great user experience as users only see a single web form, where they enter all of their credentials in one place, followed by the published application. Simple, logical and easy to support.

This feature is enabled by configuring the Collect additional delegation credentials in the form setting on the Authentication tab of the web listener in question, as shown below:

However, due to the default form design, the primary authentication method, in this case RSA SecurID, is used as the first set of credentials requested by the form. Additional fields are then added below, in order to define the delegation credentials which need to be used. If you think about the processing logic behind the form, this layout actually makes total sense, however if you consider the user input logic, especially with a time sensitive password, things are not quite so logical.

The default layout (using the customisation features from Part 1) for the default ISA HTML form is shown below:

So, in order to make the form a little more user friendly we need to rearrange the credential fields into a more logical flow.

When using RADIUS OTP or RSA SecurID authentication validation methods, the form structure is defined within the usr_pwd_pcode.htm file located in the ISA\HTML folder as shown below:

Hence, this is the file that needs modifying. In Part 1, we discussed using the style sheets to apply changes for look and feel. However, as we are now looking at changing the actual form structure, we need to actually modify the HTML code which is a little more involved.

To best explain the process I have used a utility called Compare It! which allows you to compare (obviously!) two files side by side to look for changes that have been made. Hopefully this will provide a good step-by-step view of what elements need changing/deleting etc. and provide a good ‘before and after’ feel.

In the screenshots below, you will see two windows; the left window shows the original version of the file and the right window shows the modified version. For clarity, the differences are highlighted in light green.

To keep with good coding practice, you will also see that comments have been added to the modified version so I can track what has been changed.

Please Note: Before you begin editing the file, I would suggest you make a backup copy of the usr_pwd_pcode.htm file so you can restore the default form, if necessary.

So, let’s begin making changes!

Here’s a quick summary of what we plan to do:

• Remove the Internal Network Credentials section from the form completely.
• Move the Internal Network Credentials Password field under the username field, so that username and password are entered prior to the RSA SecurID passcode.
• Cleanup the form to remove the (commonly) unwanted option of Use a different user name.
• Cleanup the HTML code to remove unneeded JavaScript variables to prevent JavaScript errors in the browser.

The first thing we need to do is find the password field in the HTML code. The relevant code is shown in green in the following screenshots:

 

So, we need to cut and paste this code so that it appears after the username field as shown below:

 

Next we need to remove the horizontal line from above the Internal Network Credentials area. This is done by commenting out the following line:

 

Next we comment out the table that displays the Internal Network Credentials (show explanation) text and link:

Next we comment out the table that shows the unwanted Use a different user name check box:

Next we remove the normally hidden username field that appears after selecting the Use a different user name check box: 

Finally, we need to do some cleanup to remove unused variables which will cause JavaScript errors:

 

So we are finishing editing and the file can be save.

If all of that looked a little too painful, you can download a pre-edited version of the usr_pwd_pcode.htm from here which contains all the necessary changes discussed above.

In addition, you can also download a pre-edited version of the default Exchange HTML form with the same changes here (Note: you will need to rename the file from usr_pwd_pcode_owa.htm to usr_pwd_pcode.htm once downloaded).

So, with the changes saved and the Microsoft Firewall Service restarted, we now have the following customised HTML form:

Hopefully you will agree that this is a much cleaner looking form with a much better logical flow in terms of the user authentication experience.

As can be seen from the above screenshot, the default form fields have also been renamed to use more standard looking approach. This is simply achieved by modifying the L_Username_Text and L_Passcode_text strings in the strings.txt file, as covered in Part 1.

So, with the 'look and feel' elements covered, and some basic restructuring of the less intuitive default RSA forms, you should be able to get customising today - hope you enjoyed it!

Customising ISA Server 2006 HTML Forms - Part 1: Simple, Consistent Form Branding

Most people at one time or another want to utilise the HTML form customisation features of ISA Server 2006 when deploying solutions, in order to provide a branded experience for end users. In addition, people often wish to 'sanitise' the text located on the form to make the form appear as generic as possible, as opposed to 'Microsoft' or 'ISA Server' branded.

Although HTML form customisation is covered well in the Microsoft document titled Customizing HTML Forms in ISA Server 2006 I thought it may be useful to share my own thoughts, findings and procedures on HTML customisation through a series of blog articles.

This is the first part in the series and provides a walkthrough of how to provide a simple and consistent brand to HTML forms. As opposed to editing the .htm code itself (as described in the Microsoft article) the approach I use is less invasive and does not require any HTML code changes at all. This has the benefit of being easily transferable between deployments (which is important for my consultancy role) and also ensures that changes can easily be removed or applied to new HTML form directories, as and when necessary. The other key benefit of this approach is that all HTML form pages will inherit the customisations, as opposed to having to edit each individual .htm file in order provide users with consistent branding or the same 'look and feel'.

Please Note: I am assuming that you have read the Microsoft article detailed above and have a general understanding of the HTML form components, structure and terminology.

If we consider the default HTML forms provided out of the box with ISA Server 2006 as a starting point, we can get a better understanding of how to modify the general look and feel of the form.

Starting with the default ISA form, this can be seen below:




If we look at the HTML code for this form (located in the logon_* files) we can break the form down into the following two key graphical components (images):

<td colspan=3><img src="/CookieAuth.dll?GetPic?formdir=@@FORMDIR&image=lgntop.gif" alt=""></td>

<td colspan=3><img src="/CookieAuth.dll?GetPic?formdir=@@FORMDIR&image=lgnbottom.gif" alt=""></td>

These are indicated in the screenshot below, highlighted in orange:

As shown in the above screenshot, the HTML form header and footer are made up of the following image files:

• lgntop.gif
• lgnbottom.gif

In addition to these images, a default cascading style sheet is used to define background colour, text colours etc. This style sheet is called logon_style.css

Therefore, all of the above mentioned files can be seen below highlighted in the ISA HTML form directory:

With this knowledge in hand, the simplest and most flexible option to customise the form is to merely replace these default files with customised versions which contain the required branding changes. By replacing each of these default files with each of the following customised files, we should achieve a basic level of brand customisation.

Please Note: Don't forget to restart the Microsoft Firewall service for the file changes to take effect!

Resulting in the following customised ISA default form:


Applying the same approach to the default Exchange HTML form provides similar results. However, as the default Exchange HTML forms includes an additional image in the footer, we also need to update the following file:

• lgnexlogo.gif

Therefore, all of the above mentioned files can be seen below highlighted in the Exchange HTML form directory:

Resulting in the following customised Exchange form:

If required, my own pre-customised files (for both ISA and Exchange) which produce the above results can be downloaded from here:

• lgnbotton.gif
• lgnexlogo.gif
• logon_style.css

Obviously, the company logo will need to be added manually, ideally using a pixel size of 500 x 115 or a very similar size.

Once the 'look and feel' has been modified, we can begin looking at the strings.txt files in order to customise the default text on the HTML form.

Please Note: There are several copies of the strings.txt file and it is necessary to edit the correct files to see your corresponding changes. The section called Form Set Directories in the Microsoft Customizing HTML Forms in ISA Server 2006 article defined above provides more detail on this concept. In summary, you often need to edit both the strings.txt located within the HTML folders and the appropriate language specific strings.txt file located within the HTML\NLS\ folder.

As described within the Microsoft article, strings are used to insert text entries into the resulting HTML forms. Of all of the strings available, I normally change the following key ones:

• L_WindowTitle_Text
• L_OWAWindowTitle_Text
• L_Copyright
• L_SecuredByISA

A quick overview of common changes is provided below:

The L_WindowTitle_Text and L_OWAWindowTitle_Text strings can be modified to change the text shown in the browser title bar, to make this company or application specific.

The L_Copyright string can be modified to change the text to reference the correct date/company and I often also use this field to add some form of legal disclaimer.

The entire Secured by Microsoft Internet Security and Acceleration Server text can be hidden by modifying this string to a single blank space e.g. " ".

These are just examples of some of the thing I do, but the strings.txt can be fully customised to meet your own personal requirements.

Bringing all this together, we now have a very clean looking form, customised and sanitised as required. The results can be seen for both ISA and Exchange below, with custom changes shown in red for clarity.

Sometimes, people also choose to modify the default Domain\user name: reference and replace this with a simpler Username: label, making it easier for users to understand when in a single domain environment.

This is very simple to achieve using the L_Username_Text string, as shown below:

Resulting in the following form:



So, as can be seen it is actually quite easy modify the default HTML forms to get a very personalised authentication form. The thing I like about this approach is that with the use of style sheet modifications combined with the use of existing image filenames, means that ALL elements of the form will inherit the same standardised 'look and feel' without requiring changes to individual .htm files. This approach also allows for the same changes to easily be applied to a new set of HTML forms, to another array member or they could be have modified by a third party or replaced as part of an ISA service pack or upgrade.

With the 'look and feel' elements covered, Part 2 of the series will show how to restructure some of the less intuitive default forms to provide a better user experience, most appropriately when using two-factor authentication solutions like RSA. More to follow...

UPDATE 05/01/09

A GUI based tool called FBA Editor has been written by Kay Sellenrode to help make some of the above described changes a little easier to achieve. The tool can be downloaded from here. Many thanks to Kay for providing the tool!

Resource Guide for Using Microsoft NLB with ISA Server 2006 Enterprise Edition

Of the many questions posted on ISA Server forums, a re-occurring subject that seems to cause confusion is that of using Microsoft Network Load Balancing (NLB) with ISA Server Enterprise Edition.

Please Note: As we are still (only just) in an ISA Server world and not a Forefront TMG one, the discussions here are based upon using a Windows Server 2003 platform for ISA Server, as opposed to Windows Server 2008. Therefore, all NLB discussions are relevant to this platform only, and do not cater for any enhancements that have been made in Windows Server 2008. More detail on these enhancements can be found here.

Based upon some gruelling questions on the forum recently and the result of asking Microsoft some direct questions, I thought it would be useful to try and create a blog entry that captures some of the key concepts, questions and answers in order to provide an overall resource guide. I am by no means an NLB guru, but hopefully I can summarise some of the common questions for ISA folk new to NLB, and provide my own personal slant on several NLB related issues.

Although not directly associated with NLB, the subject of intra-array communications is also covered within this article as NLB can have a direct impact on this service. Even when not using NLB, I would still personally recommend implementing a dedicated network interface card (NIC) into each array member. This will ensure that all intra-array communications are given sufficient bandwidth and contention ratios from a performance perspective, and probably more importantly, isolated from all other networks for the highest level of security for this type of 'private' communication. More on this later...

Rather than re-hashing a lot of already great documentation that has been provided by Microsoft (and others) it is useful to make reference to the following existing articles which provide some excellent information:

Network Load Balancing: Frequently Asked Questions for Windows 2000 and Windows Server 2003

Network Load Balancing: Security Best Practices for Windows 2000 and Windows Server 2003

Network Load Balancing Integration Concepts for Microsoft Internet Security and Acceleration (ISA) Server 2006

Network Load Balancing in ISA Server 2004 Enterprise Edition

Using NLB with ISA Server, Part 1: How Network Load Balancing Works

Using NLB with ISA Server Part 2: Layer 2 Fun with Unicast and Multicast Modes

Using NLB with ISA Server Part 3: Configuring NLB Array Parameters

One of the key aims of this article is to try and make some of the theory a little more understandable, hopefully adding my own experience with designing and deploying solutions that provide ISA Server high-availability. To give this article a FAQ like feel, I have provided the information as a series of common questions I have seen, and also the sort of questions I have asked myself whilst trying to get to grips with the technology.

Question 1: Do I need to use dedicated NICs in each ISA Server array member to allow for inter-host communication when using NLB?

This isn't quite a simple yes or no answer, so please bear with me! :)

If you are not running Windows Server 2003 SP1/SP2 and plan to use the default unicast NLB mode, then you will need dedicated NICs in each array member to support inter-host communications.

Historically (prior to Windows Server 2003 Service Pack 1 that is) it was necessary to implement dedicated NICs on each NLB enabled array member, as ISA Server only supported the use of unicast mode. This prerequisite arose because in Microsoft Windows Server 2003 NLB, network load-balanced hosts that operate in unicast mode cannot communicate with each other. This behaviour occurs because NLB makes the Media Access Control (MAC) address the same on array members. Therefore, the network redirector never actually sends any packets to the other NLB hosts. Consequently, without dedicated NICs, communication between array members was just not possible...

With the introduction of Windows Server 2003 SP1, support for communication between NLB nodes configured for unicast mode was added by way of a UnicastInterHostCommSupport registry value. This is discussed in more detail within the following knowledgebase article: Unicast NLB nodes cannot communicate over an NLB-enabled network adaptor in Windows Server 2003

If you are running any version of Windows Server 2003 (RTM/SP1/SP2) with multicast NLB, then you will not need dedicated NICs in each array member to support inter-host communications.

In addition to the changes in SP1, Microsoft now supports the use of multicast NLB with ISA Server 2006 Enterprise Edition as covered in the following knowledgebase article An update enables multicast operations for ISA Server integrated NLB. Although the necessary code update was provided as part of a hotfix package, this update is now included within ISA Server 2006 SP1 and therefore more commonly implemented as part of this update. Further information on enabling multicast mode can be found in one of my previous blog entries here.

Now, here's the rub! - considering all these changes, it would appear that it is no longer necessary to utilise dedicated NICs per array member for intra-array communications when enabling NLB if you choose the correct service pack level or NLB operational mode. However, its never that simple, as it is still recommended for performance and security reasons to utilise dedicated NICs, if you can, but this recommendation is for intra-array communications and not NLB. This recommendation is covered within the ISA Server 2006 Security Guide and confirmed in my recent questions to Microsoft.

Therefore, the use of NLB is actually irrelevant as you should be using dedicated NICs in each array member anyhow to satisfy the Microsoft recommended performance and security needs for intra-array communications. However, you may forego this advice (some do, some don't, mileages vary) so the above information could still be of use with specific relevance to NLB and is discussed for completeness.

Question 2: If using NLB unicast mode, what impact does this have on the ISA Server network connectivity design?

In unicast mode (the default ISA integrated NLB operational mode) NLB induces switch flooding, by design, in order that packets sent to the VIP address(es) is relayed to all the cluster hosts. Switch flooding is part of the NLB strategy of obtaining the best throughput for any specific load of client requests. However, if the NLB interfaces share the switch with other (noncluster) computers, switch flooding can add to the other computers' network overhead by including them in the flooding and consequently have a detrimental affect on network and/or server performance.

The obvious solution to solve this problem is to isolate the NLB hosts so that the inherent switch flooding mechanism only affects cluster nodes, as opposed to other noncluster computers on the same network (broadcast domain).This can be achieved by placing the NLB interfaces into their own LAN or virtual LAN, thereby creating an isolated network for NLB related communications.
One option to avoid flooding noncluster computers is to place a network hub between the switch and the NLB interfaces, and then disabling the MaskSourceMAC feature that is inherent to unicast mode. However, in reality this option provides a poor solution with obvious limitations. I can't believe Microsoft support still appears to tell people to do this :(

My personal preference is to create dedicated VLANs to isolate NLB enabled interfaces, as required. More detail on this area will be provided in Question 4.


Question 3: If using NLB multicast mode, what impact does this have on the ISA Server network connectivity design?

Although multicast is often used to remove unicast mode limitations like switch flooding, this operational mode can also cause switch flooding. As with unicast mode, this can be solved by placing the NLB interfaces into their own LAN or virtual LAN, thereby creating an isolated network across which to pass multicast traffic. If this is not possible, the switch ports to which the NLB enabled interfaces are attached can also be mapped to the NLB cluster MAC address via static entries in the Content-Addressable Memory (CAM) table of the switch. This ensures that the switch is aware of exactly which switch ports are 'NLB enabled' and hence eliminate the need to flood all ports.

If you have the network hardware to support it, the recommended design is to use the 'multicast with IGMP' operational mode and then configure appropriate network devices to support IGMP snooping. This combination aims to restrain multicast traffic when used in a switched network without the use of dedicated VLANs.

By default, a LAN switch floods multicast traffic within the broadcast domain, and this can consume a lot of bandwidth if many multicast servers are sending streams to the same segment. With IGMP snooping, the switch intercepts IGMP messages from the host itself and updates its MAC table accordingly. As discussed above, without snooping, it is necessary to manually configure multicast dynamic Content-Addressable Memory (CAM) entries in order to avoid flooding the subnet with multicast traffic. This is an administrative burden, however, and is not a dynamic solution like IGMP snooping. Consequently, multicast with IGMP is seen a much more elegant solution, assuming you have the network hardware to support it...

So, at first glance multicast appears solve some of the unicast limitations, but it also introduces new challenges that need to be considered. As discussed in more detail in Question 4, the key one being that some switches/routers cannot make the necessary ARP mapping and it is necessary to add a static ARP entries to solve common multicast related issues.


Question 4: What needs to be considered when connecting NLB enabled interfaces to Layer 2 and Layer 3 switches?

Layer 2 Switches

NLB is 'Layer 2 Switch aware' and assumes that NLB interfaces are connected to a Layer 2 device by default. This default configuration uses a feature called MaskSourceMAC to ensure that the switch is unable to learn the original source MAC address of each NLB host. This way, it cannot learn that the NLB traffic (the NLB cluster MAC address to be precise) should be associated with a specific individual switch port.

If we consider unicast mode first...

If the switch is unable to associate a MAC address with a particular port (because it has been masked) it will have to send the data to all switch ports; thereby ensuring that all NLB hosts can process the traffic.

If you look at the substitute source MAC address that is used, you will notice that they are similar to the original MAC address, but the first two fields are replaced as follows:

02-[Host ID including zero]-[Original MAC address values]

Consequently, a NLB host with a host ID of 3 and a MAC address of 00-19-BB-3C-29-08 has a substituted source MAC address of:

02-03-BB-3C-29-08

This actually makes spotting NLB enabled hosts pretty easy if looking at switches, routers or network tracing/sniffing software. Some good information NLB substitute MAC addresses is also available in Russ Kaufman's blog (a Microsoft HA MVP) found here.

If we next consider multicast mode...

When you mask the source MAC address, the ARP response from an NLB hosts has a substitute source MAC address in the Ethernet frame, but contains the correct NLB cluster MAC address in the ARP header. Some Layer 3 switches and routers are (not surprisingly!) confused by this type of response and cannot make this ARP mapping automatically. Hence, in this scenario it is necessary to create a static ARP entry on the affected switch/router which maps the NLB virtual IP address to the NLB cluster MAC address. This static ARP entry negates the network device from using address resolution protocol (ARP) to determine the virtual IP's MAC address, as it has already been defined statically.

Layer 3 Switches

As Layer 3 switches provide routing capabilities, it is important to configure these devices carefully to interoperate with Microsoft NLB. This can be achieved by creating VLANs that operate in Layer 2 mode and then connect NLB enabled interfaces to ports which are associated with this special 'Layer 2 mode' VLAN. Once configured this way, the VLAN will then function as discussed in the previous 'Layer 2 Switches' section (above).

Question 5: Why would you use NLB multicast mode as opposed to the default NLB unicast mode?

I have heard a few people say that they feel that Multicast mode is less problematic, but even so, I am not sure I would recommend multicast mode as the default deployment method, especially if you can easily satisfy the requirements for unicast mode. They key reason for this is the administrative overhead of needing to add static ARP entries for Layer 3 devices when using multicast NLB. In order to prevent network devices from associating VIPs with the MAC address of an individual node, this static ARP entry associates the VIP with the MAC address of the NLB cluster to ensure correct load balancing and failover operations. For a small network, these static ARP entries may be negligible, but I am not sure that this solution scales well if you have a complex network and/or utilise a large number of VIPs, as the entries will need to be made on multiple network devices and a static ARP entry is required for every individual VIP in use.

As discussed in Question 4 above, the use of multicast doesn't necessarily eliminate switch flooding, which is unhelpful when people move away from unicast specifically for this very reason.

I think a better way to answer the original question is to ask "What is wrong with using the default method of unicast mode?" If the answer this question is "Not sure..." or simply "Nothing..." then give unicast mode a try before you start thinking about enabling multicast mode! If you run into problems, multicast should hopefully be there to save the day, it's just important that you realise that this operational mode also has it's own limitations and complications that you need to consider...

Anyhow, onto some of the official answers:

Microsoft Answer: The reasons to use one method or another are mainly related to the switches and routers you use. From my experience I have seen many cases where customers need a specific method because they already have the network hardware which supports it and they do not want to spend more money on upgrading hardware.

And finally, my own view:

My Answer: If you cannot meet the recommended requirements of using the default unicast mode, or your existing switches/routers do not support it, or you just don't like unicast for some reason, multicast mode support in ISA now provides additional flexibility to solve problems that you may encounter with unicast mode in your organisation. To summarise, if unicast works for you, stick with it, if not, multicast is now achievable, and more importantly, a supported option, if and when needed!

Russ Kaufman also has some good information on this subject here.

Question 6: When using dedicated NICs for the intra-array communications, does this network connection also carry the NLB heartbeat traffic (Ethertype 0x886F packets) or does this still only occur on NLB enabled interfaces?

From what I have seen, the use dedicated NICs for intra-array communications seems to make people believe that this connection is also being used as the conduit for NLB heartbeat traffic. It sounds like this would make sense, but in reality, this is just not how NLB works.

A quick network sniff with NetMon or Wireshark on NLB enabled interfaces should also confirm this is the case...

Anyhow, onto some of the official answers:

Microsoft Answer 1: NLB heartbeats occur only over NLB enabled interfaces. That is an NLB fact, irrespective of ISA Server integrated NLB.

Microsoft Answer 2: AFAIK NLB does not allow exchanging heart beats through different NICs and even if it does, ISA definitely doesn’t configure NLB to utilise it.

And finally, my own view:

My Answer: Forget thinking about the intra-array connection as an 'NLB heartbeat' connection, it isn't! The dedicated intra-array connection is an isolated, secure network over which to pass messages between array members, these include:

• ADAM replication and ISA synchronisation with ADAM (only if the CSS role is installed on array members).


• ISA level heartbeat (over http) to determine availability of array members. This is done in order to correctly handle and forward CARP requests.


• CARP traffic, where one member forwards http request to another member for cache retrieval purposes.

Therefore, placing this type of communication on an isolated network sure makes sense to me! :)

Question 7: Can you explain the following statement from Technet? “When NLB is enabled, it synchronizes array members by using pure Ethernet protocol communication. This low-level traffic is not protected by ISA Server. To help secure that traffic, we strongly recommend that you place a Layer-3 router between the Internet and the NLB-enabled array. This Layer-3 router will not allow the low-level Ethernet protocol to pass, thereby helping protect the array from potentially malicious Ethernet traffic from the Internet that could disrupt the operation of NLB."

Before I got my head around which actual interfaces were used to exchange NLB heartbeat packets in a multi-homed scenario, I never really understood this statement, which I had come across several times.

Anyhow, onto some of the official answers:

Microsoft Answer 1: NLB heartbeats and any other NLB handshake communication are low level, ISA doesn’t see it. A malicious user who can access your interfaces can interfere with this handshake. By isolating the NLB enabled interfaces with a layer-3 router you prevent malicious traffic from interfering with NLB operation. This recommendation is not specific to ISA, the same recommendation is just as valid for something like an NLB enabled web server.

And finally, my own view:

My Answer: From Question 4, we now know that NLB heartbeats occur on the actual NLB enabled interfaces themselves, and subsequently this Technet statement makes sense, especially if read slowly :) (see further clarification in my next question).


Question 8: Does the use of the word 'Internet' in Question 7 above actually imply any potentially untrusted network? Consequently, should all NLB enabled interfaces be separated from untrusted networks using a Layer 3 device?

This seems an obvious follow on question, as the days of fearing the Internet as the only source of untrusted or malicious intent are very much over. Consequently, the concept of NLB interference is actually valid for any NLB enabled network.

Anyhow, onto some of the official answers:

Microsoft Answer 1: Yes. Any NLB enabled interface should be isolated from untrusted traffic to prevent malicious interference with NLB packets.

And finally, my own view:

My Answer: I think this Technet statement should possibly be reworded, as we cannot assume that the Internet is the only source of malicious attack and potentially all NLB enabled interfaces should be protected accordingly. At the simplest level, this could be achieved through the use of dedicated Layer 2 VLANs for each NLB enabled network, hosted on a Layer 3 switch, which is then configured to route between the VLANs as necessary.


Question 9: If I have installed the Configuration Storage Servers (CSS) role on my ISA Servers, will CSS functionality be impacted by enabling NLB?

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 10: I have enabled ISA integrated NLB using multicast mode. What do I need to consider to ensure client devices on remote networks separated by a firewall or router will function correctly?

As discussed in Questions 4/5 the use of multicast mode can introduce the need to add static ARP entries to routing devices (Layer 3) to ensure they are able to correctly utilise the NLB cluster MAC address as opposed to relying on the usual ARP response. The addition of static ARP entries varys between vendors, but a couple of examples that I am personally aware of are provided below:

For example, on a Cisco device, a static ARP entry can be added with the following syntax:

arp [NLB Virtual IP Address] [NLB Cluster MAC Address] ARPA

Whilst on a NetScreen device, a static ARP entry can be added with the following syntax:

set arp [NLB Virtual IP Address] [NLB Cluster MAC Address]


Question 11: Can you provide an example design which covers the key elements to consider for an ISA integrated NLB design?

This is not an easy question to answer, as many factors can affect the overall ISA Server high-availability design. However, I have provided an example architecture diagram below, upon which to highlight areas of consideration. This is by no means a full 'best practice' design but covers a lot of 'good practice' in my opinion.

The design is based upon a two-tier perimeter network that uses a two-node ISA Server Enterprise Edition array, in addition to a couple of hardware front/edge firewalls. The key role for the front firewall in this design is to offload processing of unwanted, 'noisy' traffic from the ISA Servers and also provide ISP fault tolerance as ISA Server 2006 is not able to provide this functionality at this time. I am not going to say much else about the overall architecture design, as this article is about NLB and not firewall/perimeter network design :)

Key NLB Design Features

• The use of Layer 3 switches throughout ensures that NLB interfaces are protected against malicious interference of NLB related packets as discussed in Questions 6/7.

• As per ISA Server best practice, only the external interfaces should be configured with a default gateway. Consequently, it is necessary to configure static routes on the ISA Server internal interfaces to allow communication with internal hosts which exists behind/outside of the PRIVISA VLAN. As the Layer 2 VLAN does not have any form of gateway address by default, it is necessary to provide some form of gateway so that appropriate static routes can be created on each array member. In terms of Cisco hardware, this is achieved using a feature called a Switch Virtual Interface (SVI). With this feature configured, each array member can then be configured to use this SVI IP address as the gateway IP address when defining 'route add' statements for communication with internal hosts and networks.

• The ISA Server primary VIP on the external interface is used by the front firewalls (Front FW) as the primary route for all inbound traffic. This ensures that all inbound traffic is load balanced across both array members and still available in the event that one of the array members fails.

• The ISA Server primary VIP on the internal interface is used by the core switches as the primary route for all outbound traffic. This ensures that all outbound traffic is load balanced across both array members and still available in the event that one of the array members fails.

• The ISA Server primary VIP on the DMZ interfaces is used by the hosts in those networks as the primary route for all outbound traffic. This ensures that all outbound traffic is load balanced across both array members and still available in the event that one of the array members fails.

• Each array member is connected to separate switches (denoted by SW1 and SW2 references) to ensure that a single switch failure will only result in the loss of a single array member, as opposed to the entire array. Furthermore, each array member is homed to the same switch for all interfaces, as the loss of a single interface will cause ISA to remove the array member from the NLB cluster as discussed in Question 13.

Question 12: Does using NLB prevent me from using other network technologies like NIC teaming and VLAN tagging?

Yes, unfortunately NLB and other network technologies like NIC teaming and VLAN tagging are often mutually exclusive.

Some vendors claim that NIC teaming and NLB are supported (HP for example) but only if multicast mode is used, as opposed to unicast. However, I have never been able to actually get this to work with ISA integrated NLB, even when ISA Server has been specifically configured to utilise multicast mode. My testing resulted in the same 'NLB cannot apply local configuration' errors with multicast mode as I experienced with unicast mode. If someone has this working, I would be very grateful to hear the solution!

Russ Kaufman provides a similar viewpoint here.


Question 13: When I disconnect any NLB enabled NIC, the entire array member is removed from the cluster and consequently no longer accepts connections - Is this normal?

I believe this behaviour is by design, as the loss of any NLB enabled interface results in the NLB service being stopped. This seems to be a sensible approach if you consider that fact that ISA Server has no understanding of which interfaces are critical and those that are expendable. In addition, it may be that traffic could enter the firewall on one interface but not be able to exit the firewall on a failed interface. Hence, in order to preserve a suitable state of stability and operational confidence, the entire array member is removed from the NLB cluster until the problem can be rectified.

Based upon this knowledge, this design feature therefore necessitates that the network architecture needs to be carefully considered and designed to work alongside ISA integrated NLB. For example, connecting all array members into a single switch would render the entire array inoperable in the event of switch failure. Therefore, a high-availability network design is also required, and ideally array members should be distributed across network hardware to ensure that failure of a network component only affects a single array member, or worst case scenario, a small subset of array members, as opposed to the entire array.

Right, I think that is a pretty good braindump for now, which hopefully answers a few of the most common questions I often come across. I hope this resource guide proves useful, and as always, please feel free to comment either way :)

Hardening SSL Cipher Strength and SSL Protocol Support on ISA Servers

There are many weird and wonderful ways that you can further harden your ISA Server installation over and above the level provided by the default install. This subject is covered in some detail in the Microsoft articles titled ISA Server 2006 Security Guide and ISA Server 2004 Security Hardening Guide. However, an advisory that seems to come up on a majority of security/penetration reports that I have seen when testing ISA Server deployments, is that of recommended minimum negotiable SSL cipher strengths and gratuitous SSL protocol support.

Microsoft have produced a very detailed knowledge base article called How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll (KB245030) that covers the overall concept of SSL security restrictions, but it is quite complicated in places, mainly due to the technical depth and detail provided. The aim of this blog post is to cover what I believe to be the two main mitigation areas that need to be employed; namely improving the SSL cipher strength to only support 128bit or above cipher suites, and ensuring that only recommended SSL protocols be used. Both of these changes eliminate any of the concerns with using cipher strengths below 128bit, or weaker SSL protocols, which are often flagged during security testing as providing an insufficient level of security for most environments. They also fix an ISA Server specific issue, discussed later.

It is worth noting that, if required, ISA Server can be configured to enforce 128bit encryption for web publishing rules which utilise HTTPS. An example of this is shown below:



Unfortunately, this does not prevent weaker SSL ciphers strengths from being negotiated with the operating system, which often leads to false positives during security testing. An understanding of why this occurs is provided in the following knowledge base article ISA Server 2006 and ISA Server 2004 do not reject weakly encrypted authentication requests for access to an SSL Web site after you configure ISA Server to require 128-bit encryption (KB937293)

What this option does do, however, is ensure that ISA will not pass any traffic that is not encrypted to this required 128bit level and consequently deny user access. In addition, this option does not provide any way to enforce the use of specific SSL protocols. It also doesn't enforce the minimum cipher strength if people forget to tick the box! :)

Based upon my understanding, ISA Server hands all SSL processing to the operating system; Schannel.dll to be precise. Therefore, if the operating system has been left at the default state, it will be possible to negotiate SSL connections using inappropriately weak cipher strengths.

With this view in mind, I decided to ensure that (where possible) all my ISA Server deployments would include a higher level of SSL cipher strength and limit SSL protocols (compared to the default state) to provide a more secure (hardened) platform when using ISA Server to host SSL connections. In addition, I wanted to ensure that security and penetration testing of implemented solutions wouldn't highlight potential false positives from SSL negotiation, and also ensure that if the customer was unaware of the 'Require 128bit encryption...' option you could still rely on the operating system to provide a level of protection to prevent the use of weak SSL security.

Using the KB article, I decided that I would prevent the operating system from accepting cipher suites below 128bit, therefore I was able to define the following standards:

• NULL: DISABLED
• DES 56/56: DISABLED
• RC2 40/128: DISABLED
• RC2 56/128: DISABLED
• RC2 128/128: ENABLED
• RC4 40/128: DISABLED
• RC4 56/128: DISABLED
• RC4 64/128: DISABLED
• RC4 128/128: ENABLED
• Triple DES 168/168: ENABLED

I also decided to standardise on the use of SSL 3.0 and TLS 1.0 only, therefore I was able to define the following standards:

• PCT 1.0 Client: DISABLED
• PCT 1.0 Server: DISABLED
• SSL 2.0 Client: DISABLED
• SSL 2.0 Server: DISABLED
• SSL 3.0 Client: ENABLED
• SSL 3.0 Server: ENABLED
• TLS 1.0 Client: ENABLED
• TLS 1.0 Server: ENABLED
  

To this end I was then able to create the following registry files:

RemoveWeakCiphers.reg


Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\NULL]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 128/128]"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 56/128]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128]"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 64/128]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168]"Enabled"=dword:ffffffff

RemoveWeakVersions.reg


Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]"Enabled"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]"Enabled"=dword:ffffffff
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]"Enabled"=dword:ffffffff

If required, copies of these registry files can be found here and here, respectively.

Once you have applied both of these registry files, the operating system will then meet the required cipher strengths and protocol support defined above.

Please Note: A reboot is necessary to apply the above registry changes and allow Schannel.dll to enforce the new standards.

Although I have aimed this blog post at ISA Server, the SSL hardening elements defined in this article are equally applicable to any system that supports or terminates SSL/TLS connections. Therefore, the registry files could just as equally be applied to a secure Internet facing web server to ensure suitable strong SSL cipher suites and protocols are employed.

As with all security measures and hardening, there is risk that these changes may impact functionality. For example if you have clients that are not able to support 128bit encryption or not configured to utilise SSL 3.0/TLS 1.0, connections from these clients will undoubtedly fail. A good example of this is Internet Explorer, which should ideally be configured as shown below:

It is also worth noting that these changes are not required on Windows Server 2008 platforms as the secure-by-default configuration has higher entry-level restrictions on cipher strength and protocol support. However, as the current version of ISA Server is not supported on Windows Server 2008, therefore the above standards are still very applicble to a vast majority of ISA Server deployments which utilise secure web publishing.

The end result is that you will have a more secure deployment of ISA Server and will also minimise (if not eradicate) the number of SSL related risks which commonly appear on security/penetration test reports for HTTPS based services. Both of which are pretty desirable in my opinion ;)

UPDATE 08/11/08

In addition to the use of registry files, I have found a great tool written by Marcello Gorlani called CipherControl. The tool provides a GUI utility for changing SCHANNEL parameters which is very useful!

I also wanted to add that once the appropriate Cipher strengths have been amended (using CipherControl or the above registry method) they can then be audited using Serversniff or SSL Digger to confirm the required configuration.

Enabling Network Load Balancing (NLB) Multicast Mode with ISA Server 2006 Enterprise Edition

I have seen a few questions on the ISA forums with regard to enabling support for Network Load Balancing (NLB) Multicast support on ISA Server 2006 Enterprise Edition. Although this seems like a relatively simple feature, there seems to be a bit of confusion about how best to enable the feature, what elements are actually required and where to find all of the associated information for the complete process.

Based upon my understanding and a recent need to enable this feature for a customer, I thought it may be useful to provide an overview of the procedure and try to encapsulate all of the required information in one single blog entry. An high-level overview of the procedure is provided below:

• Step 1: Disable Network Load Balancing Integration on the array (only necessary if NLB integration is already enabled)
• Step 2: Run RemoveAllNLBSetting.cmd on each array member, which is available as part of NLBclear.exe tool from here (only necessary if NLB integration is already enabled)
• Step 3: Ensure KB942639 or Service Pack 1 are installed on all Configuration Storage Servers and ISA array members (note the correct order of installation)
• Step 4: Run the KB938550 script on the primary Configuration Storage Server and configure the required NLB mode as necessary.
• Step 5: Enable Network Load Balancing Integration on the array.

In order to enable the multicast feature on an array, all ISA Servers need to be running the hotfix included in KB942639 or have installed Service Pack 1. Until this update, ISA Server was only supported in unicast mode, which is not always an ideal mode for certain network environments. A better understanding of the different NLB modes can be found in the NLB FAQ along with the dependences and implications of enabling multicast mode in routed network environments.

However, installation of the updated ISA binaries is not enough, as you also need to extend the Active Directory Application Mode (ADAM) schema to support the new feature attributes. Luckily this process is fully automated in the scripts provided by Microsoft in KB938550. These same scripts are also used to enable the required NLB mode as required; namely Unicast (the default mode), Multicast or Multicast with IGMP. For convenience, a copy of the necessary scripts can also be found here as from what I can tell, these scripts are not included with Service Pack 1 and have to be obtained separately from Microsoft.

If you have multiple Configuration Storage Servers (CSS) in your ISA Enterprise, before running the script (called KB938550.wsf) it is necessary to determine which CSS is holding the Schema Master FSMO role. In general, this will be the first CSS installed into the ISA Enterprise, but this may not always be the case if the environment has been changed or subject to some form of disaster recovery. In order to determine which server holds this FSMO role, Jim Harrison has written a great script available here which does the job perfectly! Even if the environment is quite standard, it is probably worth using this script anyhow, just to ensure you are on the applying the changes to the Schema Master (see update section at end of the article for more information).

Once you have determined the correct CSS server, you can then follow the instructions included in KB938550 to extend the ADAM schema and enable the required NLB mode. Note that the script will need to be run on each array if you have multiple arrays and multiple ISA Servers. The basic syntax for this script is:

cscript kb938550.wsf /array:<ArrayName> /nlb:<NLB Mode> /net1:<ISA Network 1> /net2:<ISA Network 2> ... /netX:<ISA Network X>

where net1, net2 ... netX represents the ISA Server networks that require reconfiguration.

For a standard two-NIC ISA Server array, the example command line syntax would be:

cscript kb938550.wsf /array:MyArray /nlb:multicast /net1:Internal /net2:External

An example of the correct syntax and the associated output is shown below:

A similar output can be seen below for enabling 'Multicast with IGMP' mode, which also shows the script extending the Configuration Storage schema:

In the event that you need to return our example two-NIC ISA Server back to the default unicast NLB mode, the following syntax would be used:

cscript kb938550.wsf /array:MyArray /nlb:unicast /net1:Internal /net2:External

An important part of the process to consider, especially for distributed deployments, is to wait for the changes to fully replicate between CSS roles throughout the environment before continuing onto subsequent steps in the procedure.

Please Note: It is also interesting to note that the use of NLB multicast mode still does not appear to allow ISA Server to support vendor based NIC teaming, contrary to information provided by most hardware vendors. From my own experience, this appears to be the case with HP NIC teaming software/drivers and likely with other vendors too. I think this is more to do with the ISA Server specific implementation of NLB, as opposed to NLB itself; however, I cannot be totally sure of this.

As discussed within the NLB FAQ, the use of multicast NLB will probably require the use of static ARP entries on routers and other Layer 3 devices throughout the network environment to map the NLB cluster MAC address to each of the NLB virtual IP addresses, and hence provide correct NLB load balancing and failover functionality. This is a final important step in the overall high availability ISA Server configuration and is often missed by many ISA Server firewall admins that are not familiar with NLB.

On Cisco network devices, I believe the correct syntax for adding static ARP entries is:

arp <NLB Virtual IP Address 1> <NLB Cluster MAC Address> arpa
arp <NLB Virtual IP Address 2> <NLB Cluster MAC Address> arpa
...
arp <NLB Virtual IP Address X> <NLB Cluster MAC Address> arpa

So, I hope this blog entry has made things a little clearer, and if nothing else provides all the necessary information in one place for easy access.

UPDATE 05/01/09

I have been informed that the latest version of the kb938550.wsf script automatically determines which CSS holds the FSMO Master role, in addition to the other schema changes - this is handy, so thanks Microsoft!

Publishing Exchange 2007 Services with ISA Server 2006 – Creating the Publishing Rule for Outlook Web Access Including Document Access

Moving on from my existing article which covered Outlook Anywhere, this blog post covers Exchange 2007 Outlook Web Access (OWA) specifically including the Document Access feature.

Publishing Exchange 2007 OWA is one of the simpler Exchange 2007 services and is quite similar to traditional publishing for Exchange 2003. This area is also covered in some detail on the TechNet site here. Although OWA is covered in some detail by Microsoft, I had struggled to find information on the amendments that need to be made to allow the OWA Document Access feature to function correctly when the Client Access Server is published with ISA Server 2006. Based on several deployments, I had found that the Document Access feature did not work correctly and I was only able to access local shares on the Exchange CAS itself - this is not very useful unless you decided to make your CAS a File Server too! :)

The Document Access feature of OWA allows users to connect to Windows File Shares and Windows SharePoint Services via the OWA interface. It also allows users to open documents that are referenced or 'linked to' in emails that are read using the OWA interface. This seems like a pretty cool feature to me and hence I was keen to try and resolve any issues to enable access for my own production environment, in addition to providing the solution to customers.

The blog entry is focused on how to configure ISA and Active Directory to enable the Document Access feature and doesn't provide in-depth information on the actual Document Access feature of Exchange 2007, or how it should be configured within the Exchange 2007 Management Console. A few key elements are covered, but the Exchange 2007 documentation available here should be used for a more detailed view.

For completeness, I have also included a walkthrough for publishing OWA as this makes things flow a little better. I am going to reuse my example architecture from the previous Outlook Anywhere article. This is shown below:




The only difference with this model is the inclusion of a file server called FILE01; in all other aspects the environment is still covered by the summary information provided in my previous blog posted here. This file server contains shares that we would like to access via OWA. I have used a file server for this example (as this is the simplest example) and from what I can tell negates the need for complicated Kerberos delegation configuration in the same way as is needed for Windows SharePoint Services. I have yet to test Document Access to SharePoint, as I would normall provide access to these environments using some form of independent SharePoint publishing, as opposed to using the OWA interface.

The key to getting Document Access working (from what I could tell anyhow!) is to think about how the communication process works and then consider authentication during this process. Based upon trying to achieve the best security solution possible and normally having to cater for co-existence with Exchange 2003, I have always used Negotiate (Kerberos/NTLM) delegation as described in Appendix D of the Publishing Exchange 2007 with ISA Server 2006 document available here. I have yet to test whether Document Access works correctly when using Basic delegation, I would guess not, but I am not really sure in all honesty. The first thing that got me thinking about the approach detailed in this blog post was the following statement from Appendix D of the above document "To take advantage of the new Exchange 2007 features that require Negotiate authentication delegation...". Turning this around, it seems to imply that you should be using Negotiate authentication if you want to enable advanced Exchange 2007 features, maybe like Document Access for example???. Negotiate is actually a great choice for delegation, as it basically provides a fallback to NTLM if the necessary Kerberos configuration has not been completed on the published servers. However, if you get everything right with the Kerberos configuration on published servers, I see no reason why you couldn't actually change this to specifically utilise Kerberos constrained delegation (as opposed to Negotiate) if you are confident that fallback to NTLM is not actually required.

Please Note: It is important to understand that we are talking about delegation here and not authentication; ISA Server is not currently able to provide fallback to NTLM for authentication, only during the delegation process.

So, back to thinking about communication and authentication flows! The key difference with Document Access is that we are now involving a third (or maybe more) entity into the environment that is not actually being published by ISA Server. Instead, the Client Access Server is connecting to the file server, on the users behalf, in order to render the file share view and contents within the OWA interface. This is a common scenario and is often called a 'double hop problem' which is covered well here by Arunjeet Singh (Knowledgecast). Hence I figured that if I wanted to get Document Access to work, I would need the Client Access Server to be able to not only validate my credentials, but also be able to forward them onto the file server so that it was able to determine what access rights to shares/files I should be given, if any. As discussed in my previous blog post for Outlook Anywhere, this is something that the NTLM authentication scheme just cannot do and the Exchange CAS essentially becomes the 'man-in-the-middle' even if ISA Server is correctly configured to utilise Kerberos constrained delegation. With all this information in hand, I now realised that solving the problem involved ensuring that the Exchange CAS could delegate my credentials to the file server using Kerberos, in exactly the same way as ISA Server does.

So, hopefully we are all still on the same page :) and the following diagram shows an overview of the delegation model that needs to be defined:

I have already covered configuring ISA Server to be trusted for delegation to the Exchange CAS in my previous blog post here, so we now simply need to extend this model and configure the Exchange CAS to be trusted for delegation to the file server. A key element of successfully using KCD is ensuring that the correct Service Principal Names (SPNs) are defined and used. Rather than creating new SPNs, it makes sense to me to utilise the built-in SPNs that are created by default. Hence, this example makes use of the default SPN created for the file server. As we are accessing file services on the file server, this means that we are specifically talking about the CIFS SPN. In our example solution (as shown above) the default system generated SPN for the file server is cifs/file01.internal.msfirewall.org.uk so we will use this in our configuration.

This can be achieved using Active Directory Users and Computers. Firstly, find the computer object for the Exchange CAS and select Properties. Click on the Delegation tab. Select the option for Trust this computer for delegation to specified service only, then select Use any authentication protocol. Finally, click the Add button and browse for the file server computer object (FILE01 in our example). On the list of available SPNs defined for FILE01, select the entry for cifs/file01.

Once configured, you should see the following:

If you tick the Expanded option, you will actually see that both NetBIOS and FQDN are listed as shown below:

So, with the above configuration, we have configured the Exchange CAS to be trusted for delegation of credentials, but only to the file server, and only for the CIFS service, hence the term constrained.

Please Note: Active Directory will need to be running at Windows 2003 native functional level (or greater) in order to see the Delegation tab. Also, all computer objects will need to be in the same Active Directory domain for KCD to function (even with ISA Server 2006 SP1).

With delegation in place, we now need to ensure that the Document Access feature has been enabled on the Exchange CAS. As I discussed previously, this is not a complete guide, but covers the basics of enabling Document Access for Remote File Servers.

Using the Exchange Management Console, enable Document Access; this is available from the Properties page of the Outlook Web Access tab on the Server Configuration, Client Access node.

From the OWA (Default Web Site) page, select the Authentication tab and ensure that Integrated Windows authentication option is enabled.

Select the Public Computer File Access tab

Ensure the Enable direct file access option is enabled if you wish to enable access from public computers. This option is based upon the user selection chosen on the HTML form during the Forms Based Authentication logon process.

Ensure the Windows File Shares option is enabled as a minimum for our example.

Select the Private Computer File Access tab

Ensure the Enable direct file access option is enabled if you wish to enable access from private computers. This option is based upon the user selection chosen on the HTML form during the Forms Based Authentication logon process.

Ensure the Windows File Shares option is enabled as a minimum for our example.

Select the Remote File Servers tab

Click the Allow List button and enter the host names of required remote file servers. In our example this is just FILE01. Click OK to save.

Please Note: I would recommend that you ensure that the Unknown Servers option is configured for Block mode as a security measure. This ensures that only servers specifically defined within the allow list will be accessible.

Click the Configure button and enter the domain suffix for internal sites. In our example this is internal.msfirewall.org.uk. Click OK to save.

The Exchange 2007 CAS is now configured, Active Directory delegation is enabled and hopefully we have an understanding of the solution approach and proposed authentication elements. So, lets start configuring ISA!

From within the ISA Server Management Console, select the Publish Exchange Web Client Access wizard.

Enter a suitable publishing rule name like Publish Exchange 2007 OWA

Define the Exchange Version as Exchange Server 2007 and select Outlook Web Access.

Select Publish a single web site or load balancer

Select Use SSL to connect to the published Web server or server farm

Define the Internal site name as email.msfirewall.org.uk. Select the Use computer name or IP address to connect to the published server option and enter cas01.internal.msfirewall.org.uk into the Computer name or IP address field.

Enter email.msfirewall.org.uk into the public name field.

On the Select Web Listener page, click New and define a suitable name for the listener like Exchange Listener (Internet FBA).

Select Require SSL secured connections with clients

Enable the External network listener and click on Select IP Addresses to define a unique IP address for the listener.

Click Select Certificate and select the appropriate certificate from the list

Please Note: This step assumes that you have already purchased and installed certificates into the Local Computer certificate store on the ISA Server.

On the Authentication Settings page, select HTML Form Authentication and Windows (Active Directory).

Click Next and then Finish.

With the web listener created, click Next to continue.

On the Authentication Delegation page, select Negotiate (Kerberos/NTLM) and enter http/cas01.internal.msfirewall.org.uk into the SPN field.

Click Next

Click Finish to complete the rule wizard.

You should now see the rule defined in the firewall policy.

To make life a little easier for users, I generally enable HTTP to HTTPS redirection on the HTTPS listeners.

I also tend to enforce 128-bit (high) encryption for HTTPS traffic.


Looking at the Paths tab, we can clearly see all of the virtual directories used by Exchange OWA.

However some of these directories are only required for legacy users with Exchange 2003 mailboxes. If you have a pure Exchange 2007 environment, you only actually need the /OWA/* entry.

Please Note: If you need to provide a co-existence environment for both Exchange 2003 and Exchange 2007 users, you should follow the guidance provided in Appendix D of the Publishing Exchange 2007 with ISA Server 2006 article available from Microsoft here.

So, if we now login to our published OWA interface and click on the Documents button in the bottom left pane.

Click on the link for Open Location

Enter a UNC path to the required share as shown in the following example.

Please Note: For future reference, you may like to add the location to your favourites to negate having to enter UNC paths each time you need them.

You should now be able to see the share contents rendered in the right hand pane and you now have access to internal documents via OWA!

With successful access to a single file server, you should now be able to extend the solution to support additional file servers as required. Assuming internal SharePoint servers are configured to support Kerberos authentication, it should also be possible to access these resources in the same way.

Download this Article

Vista Problem Accessing Office Documents from SharePoint Document Libraries That Are Published Using ISA Server 2006

After recently upgrading my own work laptop to Windows Vista, I have been experiencing problems accessing Microsoft Office documents that are contained in SharePoint libraries which are published by ISA Server 2006. I have quite a lot of experience with SharePoint publishing and these problems appear to continue even when ISA Server is configured to utilise persistent cookies and all other ISA Server publishing configuration elements are correctly configured.

After quite a lot of investigation, it appears that a change has been made in Vista that alters the way that documents are accessed from SharePoint libraries. This change now utilises the Web Client service included with Vista (which acts as s WebDAV redirector). I think this is where the problem begins, as this service does not appear to support persistent cookies in the same way as other Office applications. Consequently, when trying to open Office applications you are now prompted to provide authentication details as ISA Server interperests the request as a new anonymous connection because the persistent cookie is not being used.

An example extract from the ISA Server logs is shown below:

After a bit of investigation of the ISA Server logs it can clearly be seen that this behaviour has changed for Vista machines compared to Windows XP; with the Web Client service enabled the ISA Server logs shows several denied entries for anonymous connections using a WebDAV client agent. Comparing the behaviour with my Windows XP SP2 virtual machine, documents are accessible seamlessly by way of the persistent cookies and the ISA Server logs show the standard Microsoft Office/12.0 client agent.

An example extract from the ISA Server logs is shown below:

At this time, the only way I can solve the problem is to stop the Web Client service on my Vista machine and add the SharePoint external URLs to my trusted sites. Upon doing this, I can open documents seamlessly (just like on my Windows XP SP2 VM) and the client agent in the ISA Server logs shows Microsoft Office/12.0 or Mircosoft Office Existence Discovery client agents as opposed to the WebDAV one.

Bizarrely enough, I have also found that if you cancel the password prompt the document will actually open. From looking at the ISA Server logs, it appears that when cancel is pressed the client falls back to the historic method and starts using the Microsoft Office/12.0 and Microsoft Office Existence Discovery client agents. This can be seen below:

However, with the Web Client service disabled, I can now no longer open a document in Read-only mode and then click the Edit Document link in the document information bar. This is not essential, as I can still open document in edit mode by using the Edit in Microsoft Word option from the document library interface, but this is potentially quite annoying for unknowing users.

I am not sure why the Web Client service is not able to consume the persistent cookies in the same way of Office applications, but until it can, I cannot see a clear way to provide a fully functional solution with Windows Vista. I could of course just tell people to click the cancel button when prompted are prompted for credentials, but this is not really an elegant solution! :)

Any ideas or suggestions, please comment!

Please Note: During my investigation I have tried the fix detailed in KB943280 but I have come to the conclusion that this fix is for a different problem although it appears to have similar symptoms.

Publishing Exchange 2007 Services with ISA Server 2006 – Creating the Publishing Rule for Outlook Anywhere with Transparent Windows Authentication

I originally planned to do a series of blog entries in article format to cover the entire concept of publishing Exchange 2007 services with ISA Server 2006. However, this is not an insignificant task and the more I have started putting content together, the more I have realised what a mammoth task it is!

Based upon demand from users over at the ISAserver.org forums, I have created this blog entry to accelerate the process and produce the articles a little out of sync, and without too much Exchange 2007 preamble. Exchange 2007 publishing is very different to Exchange 2003 publishing and introduces many new concepts that are important to understand before you even start creating your ISA Server firewall policy rules. Some of this article may seem a little confusing as it was written based upon the fact that I had already published the Outlook Web Access publishing guide and we would have a working setup in place with necessary SSL certificates and FQDNs already in place. Hopefully once both articles are available they will 'gel' a little better and remove any potential confusion!

Anyhow, enough waffle...this blog entry covers publishing Exchange 2007 Outlook Anywhere using ISA Server 2006, but the key differentiator being that we can achieve all of the following:

• Provide transparent authentication for external Outlook Anywhere users if they are logged into domain member computers with cached credentials. This means that the Outlook password prompt seen with Exchange 2003 will no longer be present.


• Provide ISA Server pre-authentication for all requests, thereby providing the ultimate level of protection for Exchange 2007 Client Access Servers.
  
• Provide access to advanced Exchange 2007 Outlook Anywhere features like Autodiscovery, Out of Office, Offline Address Book, Unified Messaging and the Auto Account Setup Wizard etc.

Before getting started on the ISA Server configuration, it is helpful to provide an example environment upon which to base the examples. The diagram below shows an overview of a relatively standard architecture for external remote access to Exchange.






A summary of the environment is provided below:

• A single ISA Server 2006 (pre-SP1) firewall named ISA2K6.


• A single Exchange 2007 Client Access Server named CAS01.
  
• Two SSL server certificates are installed on the ISA Server. These are issued from a public Certificate Authority (CA) each with unique common or subject names of email.msfirewall.org.uk and autodiscover.msfirewall.org.uk respectively.
  
• A single SSL server certificate is installed on the Exchange CAS which replaces the default self-signed certificate. This is issued from an internal CA and is a Subject Alternate Name (SAN) certificate (sometimes called a Unified Communications (UC) certificate). The common or subject name of this certificate is email.msfirewall.org.uk and the primary SAN entry is also email.msfirewall.org.uk. Additional SANs have been defined as per the diagram to cater for alternate access names used by internal clients.

• ISA Server is configured to trust the internal issuing CA that issued the Exchange CAS certificate and also trust any additional Root or Intermediate CAs, as necessary.


• The ISA Server and Exchange CAS are both members of the same Active Directory domain.

• SSL bridging is used to ensure all communications are encrypted across both the public and private networks.


• All clients are using Microsoft Outlook 2007.
  
• A dedicated FQDN is defined for Outlook Anywhere which resolves to a dedicated public IP address.

Please Note: In order to minimise potential problems with ISA Server 2006 pre-SP1, it is recommended to define the Exchange CAS certificate common name and first SAN as email.msfirewall.org.uk. This configuration will negate likely problems with ISA Server 2006 pre-SP1 from reading multiple SAN entries as discussed here. For the purposes of this article I have assumed that ISA Server is running the RTM pre-SP1 version and we would also be publishing access to Outlook Web Access using a URL of email.msfirewall.org.uk.

Although not covered in this article, it is possible to extend the simple approach defined above with the use of additional certificates to personalise external DNS names to specifically match each Exchange service. An overview of this architecture is shown below.

This configuration is not technically necessary, but it does provide a slightly more elegant solution and makes things a little bit more intuitive when looking at DNS names in Windows Mobile or Outlook configuration screens. However, apart from 'elegance', a solution comprising of two individual SSL server certificates is more than sufficient for a working configuration.

Please Note: In theory it is possible to use a single wildcard certificate for this scenario, but from my own testing I have found that the use of a wildcard certificate had an adverse effects on the Outlook Auto Account Setup wizard which I was unable to resolve (even after enabling the 'Set-OutlookProvider -identity EXPR -CertPrincipalName msstd:*.yourdomain.com' PowerShell command as defined here). We also need to consider that Windows Mobile 5 does not support wildcard certificates, so if you have a mixed Windows Mobile client base this will also cause issues. Based upon this, for the time being (and for this example solution) I have been cautious and used individual certificates for most of my deployments.

One of the challenging aspects of Outlook Anywhere publishing is how to achieve transparent authentication (e.g. not having to enter a password in Outlook when away from the office) and also ensure that all Outlook Anywhere connections are pre-authenticated by ISA Server. ISA Server pre-authentication is a vital part of any ISA Server deployment as this ensures no anonymous connections can ever reach the internal Exchange infrastructure.

In it's current form, ISA Server is not able to require Windows integrated authentication and then delegate credentials using NTLM delegation. This is based upon the fact that this authentication protocol is designed to use a challenge/response process and specifically prevent 'man-in-the-middle' attacks. As ISA Server is the 'man-in-the-middle' in a reverse proxy topology, this is just not possible to achieve. Therefore, in order to authenticate Outlook Anywhere connections using Windows authentication is it necessary to use Kerberos Constrained Delegation (KCD). ISA Server 2006 introduces support for Kerberos constrained delegation to enable published Web servers to authenticate users by Kerberos after their identity has been verified by ISA Server using a non-Kerberos authentication method. When used in this way, Kerberos constrained delegation eliminates the need for requiring users to provide credentials twice. For example, because it is unrealistic to perform Kerberos authentication over the Internet (no access to the KDC server), Windows authentication might be used for authenticating users at the ISA Server computer. After ISA Server verifies the user's identity, ISA Server cannot pass the Windows credentials provided by the user to a published server, but it can impersonate the user and obtain a Kerberos service ticket for authenticating the user (client) to a published Web server.

Based upon this approach, the following diagram shows an overview of the authentication elements used in our solution example.

A key element of successfully using KCD is ensuring that the correct Service Principal Names (SPNs) are defined and used. Rather than creating new SPNs, it makes sense to me to utilise the built-in SPNs that are created by default. Hence, this example makes use of the default SPN created for the Exchange CAS. As we are publishing web services on the Exchange CAS, this means that we are specifically talking about the HTTP SPN. In our example solution (as shown above) the default system generated SPN for the Exchange CAS is http/cas01.internal.msfirewall.org.uk so we will use this in our configuration.

In addition to thinking about SPNs, for KCD to function correctly it is also necessary to configure the ISA Server computer object in Active Directory and enable delegation. In order for the ISA Server to be trusted for delegation, it needs to be correctly defined. Furthermore, to ensure we provide a least privilege solution, we will use constrained delegation to ensure that we only trust ISA Server to delegate the appropriate service (HTTP in our example) and not all services (hence constrained).

This can be achieved using Active Directory Users and Computers. Firstly, find the computer object for the ISA Server and select Properties. Click on the Delegation tab. Select the option for Trust this computer for delegation to specified service only, then select Use any authentication protocol. Finally, click the Add button and browse for the Exchange CAS computer object (CAS01 in our example). On the list of available SPNs defined for CAS01, select the entry for http/cas01.

Once configured, you should see the following:

If you tick the Expanded option, you will actually see that both NetBIOS and FQDN are listed as shown below:

So, with the above configuration, we have configured ISA Server to be trusted for delegation of credentials, but only to the Exchange CAS, and only for the HTTP service, hence the term constrained.

Please Note: Active Directory will need to be running at Windows 2003 native functional level (or greater) in order to see the Delegation tab. Also, both computer objects will need to be in the same Active Directory domain for KCD to function (even with ISA Server 2006 SP1).

As Windows authentication and Forms Based Authentication (FBA) are mutually exclusive, it is not possible to use a single web listener for all Exchange 2007 publishing and achieve transparent authentication within Outlook Anywhere. Therefore, as part of this solution it is necessary to create a dedicated web listener that is used exclusively for Outlook Anywhere and associated services like Exchange Autodiscovery, EWS, OAB, UM etc. This is a bit of a shame, but an acceptable compromise in my opinion and likely to remain until ISA Server is able to perform fallback to NTLM. The introduction of a dedicated web listener for Outlook Anywhere also introduces the need for an additional public IP address.

Without going into specific details (more detail can be found here) the Outlook Anywhere client relies upon the Exchange 2007 Autodiscover service in order to determine where to find information about supplementary services like EWS, UM, and OAB. Therefore, within our solution we need to provide access to the Exchange 2007 autodiscover service located on the Exchange CAS. The Outlook Anywhere client is hard coded to look for the autodiscover services using the following URLs:

https://smtpdomain.tld/autodiscover/autodiscover.xml
https://autodiscover.smtpdomain.tld/autodiscover/autodiscover.xml.

In our example, these become:

https://msfirewall.org.uk/autodiscover/autodiscover.xml
https://autodiscover.msfirewall.org.uk/autodiscover/autodiscover.xml.

In reality, we only really need to consider the second of these URLs as this contains a specific hostname value which is more practical. Seeing as though this URL will always be required by the Outlook Anywhere client, it makes sense to me to reuse this URL as the Outlook RPC over HTTP(S) proxy definition URL. This ensures that a single URL and single SSL server certificate will be sufficient for all Outlook Anywhere functionality, including advanced features.

One of the critical steps in getting Outlook Anywhere to be fully function is to define external URLs for each Exchange service used by Outlook. This ensures that when Outlook is used externally (without access to Active Directory or the Exchange Service Connection Point) it will be able to determine the correct external URLs using the autodiscover process, as opposed to using the default internal URLs defined as part of the Exchange setup process. The default internal URLs will normally contain internal URLs of the form https://cas01.internal.msfirewall.org.uk which will probably not function externally.

At this time, I am not including specific details on configuring the Exchange CAS (as this is quite an in-depth subject!) but the following summary covers the key configuration steps:

Using the Exchange Management Console, enable Outlook Anywhere; define the external hostname as autodiscover.msfirewall.org.uk and client authentication method as NTLM authentication.

Using IIS Manager, ensure the following virtual directories have Integrated Windows authentication enabled:

• Autodiscover
• EWS
• OAB
• RPC
• Unified Messaging

Using the Exchange Management Shell, define Exchange Web Services (EWS), Offline Address Book (OAB) and Unified Messaging (UM) External URLs as follows:

EWS: https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

OAB: https://autodiscover.msfirewall.org.uk/oab

UM: https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

This can be achieved using the following PowerShell commands:

Set-WebServicesVirtualDirectory -Identity 'CAS01\EWS (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/ews/exchange.asmx

Set-OabVirtualDirectory -Identity 'CAS01\OAB (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/oab

Set-UMVirtualDirectory -Identity 'CAS01\UnifiedMessaging (Default Web Site)' -ExternalUrl https://autodiscover.msfirewall.org.uk/unifiedmessaging/service.asmx

Please Note: For completeness, I would recommend defining the External URL reference for all services (as shown above) even if they are not in use at the present time. This minimises the risk of forgetting they have not been configured when you try to access a new Exchange service and it doesn't work via Outlook Anywhere!

If the above means nothing to you then I suggest you start by reading the Exchange 2007 Autodiscover Service whitepaper here for a bit of background/bedtime reading...

The Exchange 2007 CAS is now configured, Active Directory delegation is enabled and hopefully we have an understanding of the solution approach and proposed authentication elements. So, let's start configuring ISA!

From within the ISA Server Management Console, select the Publish Exchange Web Client Access wizard.

Enter a suitable publishing rule name like Publish Exchange 2007 Outlook Anywhere

Define the Exchange Version as Exchange 2007, select Outlook Anywhere (RPC/HTTP(s)) and Publish additional folders on the Exchange Server for Outlook 2007 Clients.

Select Publish a single web site or load balancer

Define the Internal site name as email.msfirewall.org.uk. Select the Use computer name or IP address to conenct to the published server option and enter cas01.internal.msfirewall.org.uk into the Computer name or IP address field.

Please Note: Due to issues with ISA Server 2006 pre-SP1 and SAN certificates (discussed here) it has been necessary to use an internal site name that matched the actual subject name (or first SAN entry) of the SSL server certificate installed on the Exchange CAS (email.msfirewall.org.uk in our example) as opposed to using autodiscover.msfirewall.org.uk. However, this issue has been fixed in ISA Server 2006 SP1 so we could actually specify autodiscover.msfirewall.org.uk as this is listed in the SAN entries of the Exchange CAS certificate. However, with an ISA Server 2006 SP1 both FQDNs should work fine.

Enter autodiscover.msfirewall.org.uk into the public name field.

On the Select Web Listener page, click New and define a suitable name for the listener like Exchange Listener (Internet Integrated).



Select Require SSL secured connections with clients

Click Select Certificate and select the appropriate certificate from the list





Please Note: This step assumes that you have already purchased and installed certificates into the Local Computer certificate store on the ISA Server.

On the Authentication Settings page, select HTTP Authentication and Integrated.

Click Next and then Finish.

With the web listener created, click Next to continue.

On the Authentication Delegation page, select Kerberos constrained delegation and enter http/cas01.internal.msfirewall.org.uk into the SPN field.

Click Next



Click Finish to complete the rule wizard.

You should now see the rule defined in the firewall policy.



To make life a little easier for users, I generally enable HTTP to HTTPS redirection on the HTTPS listeners.


I also tend to enforce 128-bit (high) encryption for HTTPS traffic.

Looking at the Paths tab, we can clearly see all of the virtual directories used by Outlook Anywhere which should match the External URLs defined on the Exchange CAS earlier within this post.

So, with all this in place, all we need to do is configure Outlook with the appropriate settings. This can be done using the Auto Account Setup Wizard which is initiated from the Mail applet in Control Panel. The following diagrams show this process.

Looking at the Exchange Proxy settings (RPC/HTTP(s) settings) that have been configured by the wizard, you should see something like this:

So, you should now be able to start Outlook and successfully connect to Exchange 2007 without providing any credentials (assuming you are on a domain member computer and logged in with cached credentials).

Hopefully this blog entry has provided a good overview of the necessary elements required to publish Exchange 2007 via ISA Server with transparent authentication and ISA pre-authentication. Obviously, it does not cater for all scenarios (like wildcard certificates and ISA/CAS high availaiblity for example) but it should be relatively easy to adapt to your specific needs.

I hope to add more blog entries for publishing other Exchange 2007 services, the next probably being publishing Exchange 2007 Outlook Web Access specifically covering the Document Access feature, which is pretty cool for remote users!

Download this Article

Using ISA Server 2006 to Protect Active Directory One-Way Forest Trusts

An area that I get involved with my 'day job' quite a lot is protecting Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) extranets with ISA Server. Depeding on the customer needs, and security policy, this often results in an architecture design that includes a one-way Microsoft Active Directory forest trust. The key concept of this model is to solve two things; namely functionality and security.

So, lets look at functionality first - this is the 'forest trust' bit:

By using a forest trust we have a way for both internal and external users to share extranet resources. By its very nature, a forest trust is often popular because it ensures that internal users will be able to access extranet information transparently. By this we mean that users will be able to use their normal Windows credendials (that they are normally logged in with) to access extranet resources without the user even realising that this is occuring.

Next, lets look at security next - this is the 'one-way' bit:

Placing external users into an internal Active Directory environement, the 'Intranet forest', is never really a good idea, as the forest is the only real security boundary in Active Directory. Subsequently, a common solution is to create an 'Extranet forest' that is used to host external user credentials and create an isoltation point or segmented boundary from internal users. This makes the security people happy, and by way of a forest trust, this makes the users happy because it 'just works'. However, to make the security people even happier and to protect against account compomise in the Extranet forest, we ensure that the trust relationship between these two 'zones' is configured such that the Externet forest trusts the Intranet forest, but the Intranet forest DOES NOT trust the Extranet forest; hence the term 'one-way'. In this scenario, the Intranet forest would be termed 'Trusted' and the Extranet forest termed 'Trusting'.

So, what does this have to do with ISA then? Well, in addition to creating logical separation with forest boundaries, the model also normally includes some form of physical segmentation. This often results in the Extranet forest being placed into a perimeter network away from the internal network. In order to create this boundary and define the perimeter network, ISA Server is an ideal choice as the border firewall between these two security zones.

When you consider the communications that are required in order to support a forest trust, you will soon realise that you need a good application-layer firewall, ideally one that is able to inspect and control RPC traffic as this protocol is notoriously difficult to secure with most firewalls. If you combine this with the level of protection ISA Server can provide specifically for MOSS/WSS, it is not difficult to understand why ISA Server is often a key component in the overall security landscape for MOSS/WSS extranet solutions.

Obviously, I have over simplified things quite a bit and there are lots of other potential models (like the External Collaboration Toolkit for SharePoint for example) which could be used. However, a one-way forest trust model architetcure doesn't have to be just for extranets, they can pop up all over the place! You can also find a similar model in our old friend the Windows Server System Reference Architecture document set.

An overview of the architecture and concept being discussed is provided below:

So the the aim of this blog entry is to provide an overview of how to configure ISA Server to support this one-way forest trust architecture and define the necessary firewall policy rules and associated protocols to make it all work. This blog entry is by no means a 'ground up' walkthrough, but just gives a good overview of how ISA should be configured to allow for trust creation, validation and successful operation. In addition, I have tried to make my examples a little more generic by using a Web server, as opposed to SharePoint, but the overall concepts apply to lots of difference scenarios where a one-way forest trust is used across firewall boundaries.

One of the first things to realise with forest trusts is that they are not supported with Network Address Translation (NAT), hence your ISA Server will need a route relationship between the Extranet network and the Intranet network (or the other way around, as route relationships are bi-directional). Assuming this is in place, we now look at the necessary firewall policy rules to get it all working!

Like most security people, I like least privilege :-) Consequently, I will always create more firewall policy rules than are necessarily needed, just to ensure that we have sufficient granularity to provide a minimal set of communications by disabling certain rules that we don't need all the time.

A lot of the communications or protocols defined in this blog entry are based upon the following whitepaper and KB article. However, I found that these articles weren't clear enough in places and needed 'improving' based upon real-world findings from using ISA Server as part of the solution with customers.

As we have a route relationship between our networks, we gain little advantage of using ISA Server server publishing in this particluar example, and therefore all firewall policy rules are defined as access rules. The RPC filter is also one of the only application filters that works with access rules, so this makes the decision the correct one in my opinion.

Please Note: ISA Server SP1 now allows for RPC UUID filtering even when using access rules, which historically required server publishing to be used. With this change, RPC access rules are now as powerful as RPC server publishing rules, which is nice!. Consequently, it is possible to extend the current solution even further by defininig a specific list of UUIDs used for forest trusts. However, this is going to take a fair bit of testing, so I think I will leave it for a future blog post!

So, based upon the above, we can summarise the necessary firewall policies as follows:

• AD Forest Trust: Allow Access for Forest Trust Creation/Validation
• AD Forest Trust: Allow Access for Conditional DNS Forwarding
• AD Forest Trust: Allow Access for Kerberos Client Authentication
• AD Forest Trust: Allow Access for NTLM Client Authentication
• AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)
• AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)
• AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)
  

An overview of each rule is provided below:

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

This rules allows the necessary communication required to initially setup and validate the trust relationship. Once the trust has been established, this rule can be disabled unless it is necessary to recreate/revalidate the trust for troubleshooting purposes. Following a least privilege approach, this step is strongly recommeneded for day-to-day operations.

AD Forest Trust: Allow Access for Conditional DNS Forwarding

This rule allows DNS servers in the Extranet forest to communication with DNS servers in the Intranet forest (and vice sersa). This is a based upon the use of conditional DNS forwarding which is needed to provide underlying name resolution services between the two AD environments.

Please Note: This is one of the few examples where using server publishing would have some security benefit as this would allow ISA Server to inspect and filter DNS as necessary. However, for this example an access rule is used for simplicity.

AD Forest Trust: Allow Access for Kerberos Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using Kerberos authentication. If Kerberos is not required, this rule is not required and should be disabled in order to adhere to least privilege.

AD Forest Trust: Allow Access for NTLM Client Authentication

This rule allow clients from the Intranet forest to authenticate to systems in the Extranet forest using NTLM authentication. It is very likely that this rule will need to remain enabled continuously and cannot be disabled, even in the event of using Kerberos.

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

This rule is needed to allow resources in the Intranet forest to be defined or 'picked' from the Extranet-Web server(s) themselves. For example within MOSS the object picker would be used to define SharePoint security permissions to a user or group in the Intranet forest. Without this rule, it will not be possible to select resources from the Intranet forest. Ideally this rule should be disabled most of the time and only enabled when adminiistrative changes are required.

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

This rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the Extranet Domain Controllers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

Again, this rule is the same as the Extranet Web Servers rule, but allows the object picker to be used from the ISA Servers themselves. Depending on how the system will be administered, this rule may or may not be required. If this rule is not required, it should be disabled or deleted.

So, now that we know what firewall polices are required to map the key communications required for everthing to function, we now need to look at the required policy objects in more detail. Before approaching this, it is worthwhile defining a few elements of the example environement that will be used as part of firewall policies:

Extranet-Web => Computer object for the Web server located in the Extranet forest. This would be running MOSS 2007 in our SharePoint analogy.

Extranet-DC1 => Computer object for the First Domain Controller in the Extranet forest.

Extranet-DC2 => Computer object for the Second Domain Controller in the Extranet forest

Intranet-DC1 => Computer object for the First Domain Controller in the Intranet forest.

Intranet-DC2 => Computer object for the Second Domain Controller in the Intranet forest.

Extranet Domain Controllers => Computer set for the Extranet Domain Controller computers.

Extranet Web Servers => Computer set for the Extranet Web server computers.

Intranet Domain Controllers => Computer set for the Intranet Domain Controller computers.

Internal Clients => Computer set to represent Intranet machines that are allowed access to the Extranet Web Servers. In reality, this may be all Intranet clients.

Based upon the firewall polices discussed above, the following pictures show a more detailed view of the rules including the necessary source, destination and protocol definitions for each set of communications (click to enlagre the pictures)

AD Forest Trust: Allow Access for Forest Trust Creation/Validation

AD Forest Trust: Allow Access for Conditional DNS Forwarding

AD Forest Trust: Allow Access for Kerberos Client Authentication



AD Forest Trust: Allow Access for NTLM Client Authentication

AD Forest Trust: Allow Access for Object Picker (Extranet Web Servers)

AD Forest Trust: Allow Access for Object Picker (Extranet Domain Controllers)

AD Forest Trust: Allow Access for Object Picker (Extranet ISA Servers)

Please Note: Based upon real-world testing and experience it was necessary to add both UDP and TCP transports for some protocols in order to prevent the object picker from experiencing delays during Intranet resource browsing tasks. Without both transports, it often became quite painful to administer Intranet resources whilst waiting for components to timeout and use an alternative transport. It was also necessary to add the 'LDAP GC (Global Catalog)' to the object picker firewall policy rules for everything to function correctly, but this deosn't appear to be documented in any of the Microsoft documents I have seen.

So, that should be all you need to get the trust established and have a fully functioning one-way forest trust. With this platform in place, it is now possible to start using ISA Server web publishing to provide secure access to Extranet web services. If you got everything correct, users should be able to authenticate to ISA Server using either Intranet or Extranet forest credentials by way of the forest trust.

Publishing Certificate Revocation Lists with ISA Server 2006 - Part 2: Applying the HTTP Filter

Continuing on from Publishing Certificate Revocation Lists with ISA Server 2006 - Part 1: Creating the Publishing Rule this blog entry covers Part 2 which extends the existing publishing rule to include a more secure implementation of the HTTP filter configuration.

As discussed in a previous blog entry the use of the HTTP filter in this example introduces the concept of 'least privilige' to ensure that only the necessary HTTP protocol features are permitted by ISA Server in order to protect access to the CRLs located on the published web servers.

Using the example from Part 1 of this blog series, we can access the HTTP filter configuration by right-clicking on the Publish Certificate Revocation List rule and selecting the Configure HTTP option from the context menu.

Using the guidance provided in the Micorosft article titled HTTP Filtering in ISA Server 2004 it is possible to apply a Baseline Web Publishing HTTP Policy as a starting point. Once this policy has been applied, and tested, we can then modify additional HTTP parameters to further control/restrict the level of security provided by the filter.

The Baseline Web Publishing HTTP Policy provided by Microsoft in the above article is shown below in HTTP Policy XML format:

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="true" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="260" MaxQueryLength="4096"><Extensions AllowCondition="2"><Extension Value=".exe" Description=""/><Extension Value=".bat" Description=""/><Extension Value=".cmd" Description=""/><Extension Value=".com" Description=""/><Extension Value=".htw" Description=""/><Extension Value=".ida" Description=""/><Extension Value=".idq" Description=""/><Extension Value=".htr" Description=""/><Extension Value=".idc" Description=""/><Extension Value=".shtm" Description=""/><Extension Value=".shtml" Description=""/><Extension Value=".stm" Description=""/><Extension Value=".printer" Description=""/><Extension Value=".ini" Description=""/><Extension Value=".log" Description=""/><Extension Value=".pol" Description=""/><Extension Value=".dat" Description=""/></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="GET" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="POST" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures><Signature Name=".." Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/><Signature Name="./" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/><Signature Name="\" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/><Signature Name=":" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[:]" FormatIsText="true" Enabled="true"/><Signature Name="%" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/><Signature Name="&amp;" Description="" SearchInType="0" SearchInHeader="" From="1" To="100" Pattern="[&amp;]" FormatIsText="true" Enabled="true"/></DeniedSignatures></Configuration>

This can be applied in the same way as covered in the previous blog entry using the HTTPFilterConfig.vbs script.

Using the baseline policy as a starting point, this can be extended to further restrict the following General features:

• Block high bit characters
• Block responses containing Windows executable content

The resulting configuration is shown below:

Using the baseline policy as a starting point, this can be extended to further restrict the Methods to:

• GET

The resulting configuration is shown below:

Using the baseline policy as a starting point, this can be extended to further restrict Extensions to:

• .crl
• Block requests containing ambiguous extensions

The resulting configuration is shown below:

Using the baseline policy as a starting point, the default baseline list of blocked signatures can remain as shown below:

Based upon the parameters defined in the above HTTP filter parameters, it is therefore possible to define a HTTPFilterConfig XML policy as follows:

CRL HTTP Filter XML Policy

<Configuration BlockExecutables="true" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="true" AllowHighBitCharacters="false" BlockDotInPath="true" MaxLength="260" MaxQueryLength="4096"><Extensions AllowCondition="1"><Extension Value=".crl" Description=""/></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures><Signature Name=".." Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[..]" FormatIsText="true" Enabled="true"/><Signature Name="./" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[./]" FormatIsText="true" Enabled="true"/><Signature Name="\" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[\]" FormatIsText="true" Enabled="true"/><Signature Name=":" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[:]" FormatIsText="true" Enabled="true"/><Signature Name="%" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[%]" FormatIsText="true" Enabled="true"/><Signature Name="&amp;" Description="" SearchInType="0" SearchInHeader="HTTP_" From="1" To="100" Pattern="[&amp;]" FormatIsText="true" Enabled="true"/></DeniedSignatures></Configuration>

This can be applied as discussed in a previous blog entry using the HTTPFilterConfig.vbs script.

I hope you have enjoyed these two blog entries and have a better understanding of publishing and protecting CRL web servers with ISA Server.

Publishing Certificate Revocation Lists with ISA Server 2006 - Part 1: Creating the Publishing Rule

More and more applications are beginning to include some form of Public Key Infrastructure (PKI) requirements as part of the core infrastructure dependencies. Based upon this drive, more customers are now beginning to consider PKI as a core infrastructure component in the same way as services like Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) services. Therefore, having some form of PKI, or certificate service, is a growing need for most environments that I encounter. PKI is one those areas where it is perceived as a 'scary' technology area which contains a lot of new concepts for most people and a fair share of new acronyms to learn!

The aim of this blog entry is not to explain PKI concepts, but to provide detail about how to use ISA Server to protect one important aspect of any PKI implementation; namely external access to Certificate Revocation Lists (CRLs).

CRLs are a key foundation of most PKI implementations and serve a critical purpose of maintaining a list of all certificates that have been revoked. Unlike Active Directory, which is able to determine dynamically at logon point whether a user account has been disabled, a similar mechanism hadn't really existed in the PKI world until the introduction of the Online Certificate Status Protocol (OCSP), but this has not been available natively within Microsoft Certificate Services until Windows Server 2008.

The process of revoking a certificate is similar to disabling a user account, such that you are expressing that this entity is no longer trusted, and consequently cannot be used to authenticate, sign or be trusted for identification. In order for a user, client or application to validate that a certificate has not been revoked, and consequently is still a valid, trustworthy entity, it is necessary to contact an appropriate CRL to determine this.

Form an internal perspective, access to the CRLs is often overlooked as 'it just works', especially as most deployments will include some form of Active Directory integration which provide a CRL access method based upon LDAP. However, access to the CRL for Internet-connected systems is becoming increasingly more important.

Rather than re-invent the PKI wheel, I am going to rely on Microsoft's Windows Server System Reference Architecture (WSSRA) documentation to provide an excellent blueprint for a well designed PKI example that is based on Windows Server 2003 Certificate Services.

Looking at this design, it can be seen that access to CRLs for the 'Internet scenario' is fully supported and includes the following features:

• CRLs will be located on Web servers which are Internet facing.
• CRLs will be accessed using the HTTP retrieval protocol.
• CRLs will be accessed using an external URL of http://dp1.pki.contoso.com/pki

Please Note: To make things a little simpler for the purposes of this blog entry, and follow my own best practice, the URL used for CRLs will be changed to http://pki.msfirewall.org.uk/pki within the examples and walkthroughs.

So, based upon the above scenario we can now look at how to provide secure access to the CRL web servers using ISA Server. After all that talking, we can now get to the point of this blog entry, namely to provide an ISA Server web publishing walkthrough!

Using the ISA Server management console, select the Publish Web Sites task from the Firewall Policy Tasks pane.

Provide a suitable rule name, I have used Publish Certificate Revlocations Lists as shown below:

Select Allow

Select Publish a single Web site of load balancer. Alternativelly, if you plan to have several web servers hosting the CRLs select the Publish a server farm of load balanced Web servers option.

Select Use non-secured connections to connect to the published Web server or server farm

In the Internal site name field, enter the Fully Qualified Domain Name(FQDN) of the web server that hosts the CRLs. If this name is not fully resolveable by ISA Server, you will need to add the correct computer name or IP address in the second input field.

At this stage, leave the Path (optional) input field blank; we will amend this part of the rule later.

Enter the external FQDN which will be included within the CRL field of issued certificates. Using the WSSRA example, this would be dp1.pki.contoso.com, however in our example this is pki.msfirewall.org.uk

On the Select Web Listener page, click New...

Enter an appropraite name for the web listener. I have used CRL Listener (Internet Anonymous)

Select Do not require SSL secured connections with clients

Tick the External network and then click Select IP Addresses...

Please Note: If you are using a Single Network Adapter ISA Server (unihomed) you will need to select the Internal network object, as opposed to the External network object.

Select Specified IP addresses on the ISA Server computer in the selected network and then choose the appropriate available IP address followed by Add >

Select No Authentication from the drop down box.

Click Next when returned to the Select Web Listener page and ensure that the Web listener drop down box shows CRL Listener (Internet Anonymous) listener, or the alternate name used during creation.

Select No delegation, and client cannot authenticate directly

Click Next

Click Finish to complete the New Web Publishing Rule Wizard

Once complete, you should have a newly created rule in your Firewall Policy window.

Highlight the newly create rule and right-click to select Properties, followed by the Paths tab. As can be seen below, I have manully defined the Internal Path as /pki/* based upon the assumption that the pki virtual directory only contains CRL files.

However, if this is not the case, it is recommended to modify the paths entries to reference individual files, as opposed to all files in the pki virtual directory. An example of this is shown below using specific entries for the required CRL files.

Correcttion! - The internal path in the screenshot above should be /issuingca+.crl and not /issuingca.crl+. I will correct the screenshot in due course.

Both options will work equally as well, but in the event that the pki virtual directory contains files which you do not want to be published, then it is recommended to use specific file name entries to provide better security.

Once the paths entry has been defined, all that needs to be done is click OK and then apply the changes using the Apply button located above the firewall policy, to commit the new rule.

In order to test access to the CRLs, you can type the full CRL address directly into your web browser (e.g. http://pki.msfirewall.org.uk/pki/rootca.crl) and you should be prompted with an option to open or save the CRL file.

With a working rule in place, we will look at providing more advanced security in Part 2 with the addition of the HTTP filter, which I am quite keen on if you hadn't gathered by now!

HTTP Filter Settings for Microsoft Office SharePoint Server (MOSS) 2007

Following on from the HTTP Filter Settings for Microsoft Exchange Server 2007 blog entry it is possible to apply the same theory to other web-based applications. A common example for this is Microsoft Office SharePoint Server (MOSS) 2007 which can benefit from the same HTTP filter security advantages as Exchange 2007 when published behind ISA Server.

Again, by looking at the the policies defined within the default application optimisers of Microsoft Intelligent Application Gateway 2007 (which are supported) it is possible to determine that the following HTTP methods allow list should be sufficient for correct MOSS 2007 operation:

• PROPFIND
• OPTIONS
• HEAD
• POST
• GET

Based upon the parameters defined in the above allow list, it is therefore possible to define a HTTPFilterConfig XML policy as follows:

MOSS HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1">tion=""/><Verb Value="PROPFIND" Description=""/><Verb Value="OPTIONS" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="POST" Description=""/><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as MOSS2007Policy.xml or something similarly descriptive.

Once applied (using the same HTTPFilterConfig.vbs script as described previously) the HTTP filter configuration can be viewed by right-clicking on the respective firewall policy rule defined during the HTTPFilterConfig import and selecting the Configure HTTP option. If imported correctly, you should see the following:

HTTP Methods for MOSS 2007


Keep posted for further articles on troubleshooting the HTTP Filter, once it has been configured...

Using CMAK to Configure ISA Server VPN Clients - Part 2: Customising the CMAK Profile

Following on from Using CMAK to Configure ISA Server VPN Clients - Part 1: Creating the CMAK Profle this blog entry is part two of the series and will look at customising the profile to add some useful features, cater for a better user experience and improve security. This blog entry assumes that Part 1 has already been followed and the CMAK profile has been created.

In this entry I am going to discsuss the following CMAK profile customisations:

• Modify the intial connection screen to hide unwanted and insecure elements.
  
• Modify the support information to add a CMAK build number to aid versioning and troubleshooting.


• Modify the Windows client to add support for NAT traversal (NAT-T) and facilitate ISA Server VPN gateways behind NAT devices.


• Include custom login and logout scripts to provide VPN users with mapped drives whilst the VPN connection is active.

Although it is possible to use the CMAK wizard to make many different customisations, like adding graphics etc., these are pretty standard options and avaibale as part of the normal wizard driven process. The customisations defined in this blog entry are slightly more advanced, and in my opinion greatly improve the experience for frequent VPN users.

Modify the intial connection screen to hide unwanted and insecure elements

The connection screen can be modified by editing the [ShortSvcName].cms file located by default in the C:\Program Files\cmak\Profiles\[ShortSvcName] folder, where [ShortSVCName] is the File name parameter defined in part one of this blog series (ISAVPN in the screenshot examples).

Using our CMAK profile from Part one as an example, we need to edit the ISAVPN.cms file, as shown below:

For the scenario where we are using a simple Windows user name and passord, we will need to leave the default username, password and domain fields. However, it seems sensible to remove the Save password option to ensure that the user cannot select this feature. This is achieved by adding a HideRememberPassword=1 entry to the [Connection Manager] section of the ISAVPN.cms file as shown below:




Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.cms file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, the connections screen result is shown below without the Save password option.

For the scenario where we are using certificates, we will no longer need to display the default username and domain fields as this information is stored within the Univeral Principal Name (UPN) of the certificate. In addition, the Save password option is not relevant in this particular scenario. These modifications are achieved by adding/editing the following entries in the [Connection Manager] section of the ISAVPN.cms file, as shown below:

HideDomain=1
HidePassword=1
HideInternetPassword=1
HideUserName=1
HideInternetUsername=1

Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.cms file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, the connections screen result is shown below without the unnecessary fields.



Althouth not strictly necessary, in addition to the changes above, I also recommend modifying the default value for the ConnectionType entry in the [Connection Manager] section of the ISAVPN.cms file from 0 to 1 as shown below. This modification ensures that the connectoid will default to I am already connected to the Internet as oppsoed to Dial a phone number to connect option; which for a majority of cases is the correct option.

Modify the support information to add a CMAK build number to aid versioning and troubleshooting

This is a simple, yet effective, modification that allows you to determine the exact version of connectoid installed on a client machine. Over time, it is possible that the CMAK profile will be mofidied, or extended, to include new features, reflect infrastructure changes or simply fix problems. However, it is not always possible to ensure that all users are using the latest version of the CMAK profile, which can lead to inconsistent results between users. Consequently, by adding a CMAK build number to the Support Information field, this will allow users to provide this information, or assess whether they are running the latest profile themselves. I tend to use a build number that is a representation of the creation date e.g. 100508 would indicate a profile created on the 10th May 2008. An example of this modification is shown below using the Support Information page as part of the CMAK wizard.

Modify the Windows client to add support for NAT-T and facilitate ISA Server VPN gateways behind NAT devices

If your ISA VPN Server is located behind a NAT device, you may experience problems connecting the VPN as discussed in the following Microsoft KB articles:

L2TP/IPsec NAT-T update for Windows XP and Windows 2000 (KB926179)

How to configure an L2TP/IPsec server behind a NAT-T device in Windows Vista and in Windows Server 2008 (KB818043)

The common solution to both of these problems is to add a specific registry entry to the VPN client machine. These registry keys are:

For Vista:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSendRule

For Windows XP:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IPsec\AssumeUDPEncapsulationContextOnSendRule

Normally a value of 2 would be used for this entry to ensure the higest level of compatability for both NAT hidden client and servers.

Rather than having to add these registry entries manually, it makes much more sence to add these entries as part of the CMAK profile installation. This can be achieved by adding the following lines to the [Xnstall.AddReg.AllUsers] and [Xnstall.AddReg.Private] sections of the [ShortSvcName].inf file included as part of the profile.

"HKLM", "SYSTEM\CurrentControlSet\Services\IPSec", "AssumeUDPEncapsulationContextOnSendRule", 0x00010001,2

"HKLM", "SYSTEM\CurrentControlSet\Services\PolicyAgent", "AssumeUDPEncapsulationContextOnSendRule", 0x00010001,2

In our example, this will be ISAVPN.inf as shown below:

[Xnstall.AddReg.AllUsers] section of ISAVPN.inf

[Xnstall.AddReg.Private] section of ISAVPN.inf

Please Note: In order to add these registry keys, the user will require local administration rights or will need to utilise the Run As option when you install the CMAK profile.

As can be seen from the images above, I have added both Vista and Windows XP registry changes to the single ISAVPN.inf file, as I don't think it is possible to interpret the client OS and apply the appropriate entry automatically. This ensures that both operating system versions will have the correct registry entry, plus an unnecessary entry, which seems like an acceptable compromise to me.

Once these changes have been made, it is necessary to re-run the CMAK wizard without making any changes. This will re-read the manually modified ISAVPN.inf file and add the modifications to the self-extracting executable ISAVPN.exe. Once the updated connectoid has been installed, it is necessary to reboot the client machine for the registry changes to take affect.

Include custom login and logout scripts to provide VPN users with mapped drives whilst the VPN connection is active

The final customisation, and potentially the most visible to the VPN user, is to provide a login script which dynamically map drives once the VPN connection is active and removes them upon disconnetion.

The theory provided here can be used to run any script process and could easily be adapted to include more advanced features than mapping drives, as the concept will be the same.

This concept is based around the Custom Actions element of the CMAK wizard and is probably one of the most powerful elements of CMAK as it can be used to perform tasks (or actions) based upon VPN conditions like Pre-connect, Post-connect, Disconnect etc.

In my example we use the Post-connect condition to trigger a Run VPN Login Script task and the Disconnect condition to trigger a Run VPN Logout Script task, as shown below:

If we look a little closer at these tasks we can see that the each action includes Program to run and an Action type elements. As the files will be deployed by CMAK, the program path will need to be presented as a vairable-based service profile path as shown below:

It cannot be easily seen in the above, but the program path needs to be of the following format:

%APPDATA%\Microsoft\Network\Connections\Cm\[ShortSvcName]\[Program Filename]

In our ISAVPN example, this would threfore become:

%APPDATA%\Microsoft\Network\Connections\Cm\ISAVPN\VPNLogin.vbs

So with the configuration shown above, the VPNLogin.vbs file will be run once the VPN has been connected.

In a simar way for our second custom action:


In our ISAVPN example, this would therefore become:

%APPDATA%\Microsoft\Network\Connections\Cm\ISAVPN\VPNLogout.vbs

So with the configuration shown above, the VPNLogout.vbs file will be run once the VPN has been disconnected.

Please Note: It is worth noting that server names should ideally be included as Fully Qualified Domain Names (FQDNs) within the .vbs files to force DNS name resolution and avoid the use of WINS.

The only remaining element is to ensure that the actual VPNLogin.vbs and VPNLogout.vbs files are included within the Additional Files element of the CMAK wizard as shown below. However, this can also be achieved if you use the Include the custom action program with this service profile option in the custom actions images shown above.

I hope you have enjoyed these two blog entries and have discovered the power of CMAK! I will probably add more CMAK customisations in the future, as I develop new ones for customers.

HTTP Filter Settings for Microsoft Exchange Server 2007

One of the key benefits of ISA Server web publishing is the ability to use the HTTP filter to provide advanced security for web-based applications by defining very specific allow lists (whitelists) or deny lists (blacklists) for key HTTP elements like methods (verbs), extensions and signatures. This filter is very similar to the URLscan tool which was recommended for IIS, but it can be applied on a per-rule basis as opposed to per-system. The use of the HTTP filter in this example introduces the concept of 'least privilige' to ensure that only the necessary HTTP methods that are required by Exchnage 2007 are permitted.

With Exchange 2003, Microsoft released a whitepaper which provided specific details of how to use the HTTP filter for securing Exchange 2003 services like Outlook Web Access, RPC/HTTP, ActiveSync etc. However, since the release of Exchange 2007 this whitepaper does not appear to have been updated or a replacement published. As Microsoft has not provided this information in an official document, I have been wary to utilise the existing HTTP filter parameters for customer deployments, just in case they have an adverse effect on functionality.

However, by looking at the the policies defined within the default application optimisers of Microsoft Intelligent Application Gateway 2007 (which are supported) it is possible to determine that the following HTTP methods allow list should be sufficient for correct Exchange 2007 operation:

Outlook Web Access (OWA) - HTTP Methods Allow List

• BCOPY
• BDELETE
• BMOVE
• BPROPPATCH
• COPY
• DELETE
• GET
• HEAD
• LOCK
• MKCOL
• MOVE
• OPTIONS
• POLL
• POST
• PROPFIND
• PROPPATCH
• PUT
• SEARCH
• SUBSCRIBE

Exchange ActiveSync (EAS) - HTTP Methods Allow List

• OPTIONS
• POST
• GET

HTTPFilterConfig.vbs is a free script provided by Microsoft on the ISA Server CD, located in the \sdk\samples\admin folder. This script can be used to import HTTP filter settings from custom XML files and assign them to individual firewall policy rules. Once a HTTP filter settings XML file has been created, it can then be imported using the following syntax:

HTTPFilterConfig.vbs import RuleName HTTPPolicyXmlFileName.xml

Based upon the parameters defined in the above allow lists, it is therefore possible to define HTTPFilterConfig XML policies as follows:

OWA HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="BCOPY" Description=""/><Verb Value="BDELETE" Description=""/><Verb Value="BMOVE" Description=""/><Verb Value="BPROPPATCH" Description=""/><Verb Value="COPY" Description=""/><Verb Value="DELETE" Description=""/><Verb Value="GET" Description=""/><Verb Value="HEAD" Description=""/><Verb Value="LOCK" Description=""/><Verb Value="MKCOL" Description=""/><Verb Value="MOVE" Description=""/><Verb Value="OPTIONS" Description=""/><Verb Value="POLL" Description=""/><Verb Value="POST" Description=""/><Verb Value="PROPFIND" Description=""/><Verb Value="PROPPATCH" Description=""/><Verb Value="PUT" Description=""/><Verb Value="SEARCH" Description=""/><Verb Value="SUBSCRIBE" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as Exchange2007OWAPolicy.xml or something similarly descriptive.

EAS HTTP Filter XML Policy

<Configuration BlockExecutables="false" ViaHeaderAction="0" NewViaHeaderValue="" ServerHeaderAction="0" NewServerHeaderValue="" MaxRequestBodyLen="-1"><UrlValidation NormalizeBeforeScan="true" VerifyNormalization="false" AllowHighBitCharacters="true" BlockDotInPath="false" MaxLength="10240" MaxQueryLength="10240"><Extensions AllowCondition="0"></Extensions></UrlValidation><Verbs AllowCondition="1"><Verb Value="OPTIONS" Description=""/><Verb Value="POST" Description=""/><Verb Value="GET" Description=""/></Verbs><RequestHeaders/><ResponseHeaders/><DeniedSignatures></DeniedSignatures></Configuration>

You simply need to copy and paste the above text into notepad and save the file as Exchange2007EASPolicy.xml or something similarly descriptive.

Once applied, the HTTP filter configuration can be viewed by right-clicking on the respective firewall policy rule defined during the HTTPFilterConfig import and selecting the Configure HTTP option. If imported correctly, you should see the following:

HTTP Methods for OWA

HTTP Methods for EAS

Additional information on HTTP filtering which applies to both ISA Server 2004 and 2006 can be found here.

Keep posted for further articles on using the HTTP Filter for other applications like Microsoft Office SharePoint Server (MOSS) 2007 amongst others...

Using CMAK to Configure ISA Server VPN Clients - Part 1: Creating the CMAK Profile

Amongst the many benefits of using ISA Server as your VPN gateway, a key attribute is the fact that the VPN client software is built into Windows which negates the need to install any third-party VPN client. The VPN connection can easily be configured within Windows using the New Connection Wizard, however I have always preferred the more elegant solution of using the Connection Manager Administration Kit (CMAK). This is a free tool included with Windows Server 2003 which can be used to create a CMAK profile (connectoid) that contains all of the the VPN connection properties, including a whole heap of customisation to make life easier and more intuitive for for users.

This blog entry is the first of a two part series which provides a walkthrough of creating a CMAK profile which can be used for connecting to an ISA Server VPN gateway. Once the CMAK profile has been created, part two of the series will look at customising the profile to add some useful features, cater for a better user experience and improve security. The blog entry assumes that the VPN feature of ISA Server has already been enabled and the L2TP/IPSec protocol has been enabled.

CMAK can be installed using the Add or Remove Programs control panel applet and is included under the Add/Remove Windows Components, Management and Monitoring Tools component.

Please Note: I have omitted wizard steps that can remain at their default settings to reduce the number of screenshots. Steps that are not included below can simply be accepted using the Next button.

Once opened, the wizard begins as shown below:

On the Service and File Names page, enter the desired Service Name and File name (this is also called the Short Service Name):



On the VPN Entries page, click the Edit button:


Select the Security tab on the Edit Virtual Private Networking Entry window and then change the Security Settings drop down selection to Use advanced security settings:


Once selected, click Configure next to the Advanced security settings text.

If you are planning on using a simple authentication method comprising of a Windows user name and password, configure the Advanced Security Settings options as shown below.


These settings represent a baseline level of security for the VPN connection, but does not represent a high security or recommended deployment. In terms of authentication, many organisations require that VPN connections are subject to some form of two-factor authentication to mitigate the risks of static user names and passwords. In addition, although it is possible to choose the Only use Point to Point Tunneling Protocol (PPTP) option, I would no longer recommend using this method as many security/penetration tests now highlight PPTP as a poor VPN solution in terms of security. As we are using simple authentication, we are unlikely to be able to provide certificates for L2TP, so we need to use enable the Use a pre-shared key when using L2TP/IPSec option in this scenario.

If you are lucky enough to be able to provision certificates (due to the use of an internal Public Key Infrastructure (PKI) deployment perhaps) then the following Advanced Security Settings options are recommended as a more secure alternative to the above:


In this scenario, we are using certificates to enable user and machine authentication for the VPN connection, as this provides a much higher level of security. It is outside the scope of this entry to provide specific details of the necessary PKI infrastructure and certificates that are required, but if you would like to see these details, please leave comments and I will try and add more detail in future blog entries.

Please Note: In addition to these two options, it is also possible to integrate third-party authentication solution into CMAK. From personal experience, I have also used RSA SecurID which integrates well (after a little work!) to provide a seamless solution. More information on this option can be found here.

If you have chosen to define a pre-share key for L2TP/IPSec then the Pre-shared Key page will be displayed. Enter the required pre-share key into the Enter key field. In order to protect the key and ensure it is encrypted in the CMAK profile files, is it recommended to choose the Encrypt the pre-share key with a PIN option. Once enabled, this PIN will need to be entered by any user that wishes to install the CMAK profile (example of this later).

On the Phone Book page, deselect the Automatically download phone book updates as this is not required.

This final step of the completed wizard is shown below:

With the wizard completed, it is simply a matter of distributing the CMAK self-installing executable (defined in the path above) to users.

Once users receive the file, they can simply run the executable to receive the following prompt shown below. Click Yes to install the CMAK profile.

If you chose the Encrypt the pre-share key with a PIN option during the wizard, you will be asked to enter the PIN. Entering an incorrect PIN will cause the installation to terminate.

On the next step, I would recommend selecting the My use only option.

Once installed, a new Connection Manager pane will be shown within Network Connections (example shown below from Windows XP) which contains the new 'ISA Server VPN' VPN connectoid.

After successful installation, the VPN connection will also be initiated/connected and you will be presented with the following connection:


You will notice that the Save password option is enabled by default. For obvious reasons, this represents a security risk which we will cover in the next blog entry.

So, we now have a basic CMAK profile defined and the VPN connectoid has been installed which provides a good platform for part two of this blog series. In part two, we will look at customising the CMAK profile to include some advanced features, add support for ISA Server VPN gateways behind NAT devices and improve security by disabling features like the Save password option shown above...

Additional information on the Connection Manager Administration Kit (CMAK) can be found here.

Recommended Network Card Configuration for ISA Firewall Servers (Updated)

A common question about ISA Server configuration by people on the forums is:

How should I configure the network interfaces on my ISA Server?

A high-level overview of NIC configuration best practice is provided below:

• The network card name used within the operating system should be changed to closely match the associated ISA Server network name. This clarifies assignment and improves supportability.
• Only one network interface should be configured with a default gateway.
• Only one network interface should be defined with DNS servers.
• Unused or unnecessary bindings should be removed from all interface, where possible, to improve security. This is often termed ‘interface hardening’.
• The default bind order should be amended to define a specific customised order.

Based upon these best practices, the configuration shown below is the standard approach that I normally use as part of my usual ISA Server build process.

Multiple NIC Deployment - ISA Server Standard Edition

Rename NICs:

Rename all NICs to descriptive names that ideally match the ISA Server network names.

Internal Network
Anonymous Access Perimeter Network
Authenticated Access Perimeter Network
External Network
Etc.

By matching the names, this makes mapping networks between ISA Server and Windows much easier when troubleshooting…

Configure NICs:

Internal Network

Default Gateway should not be defined
DNS Servers should be defined
Register this connection’s address in DNS – Enabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Perimeter Network(s)

Default Gateway should not be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Disabled
NetBIOS over TCP/IP – Disabled
Show icon in notification area when connected – Enabled

External Network

Default Gateway should be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Disabled
NetBIOS over TCP/IP – Disabled
Show icon in notification area when connected - Enabled

Please Note: Disabling the 'File and Print Sharing for Microsoft Networks' binding on the ISA Server internal interface will prevent you from connecting to shares on the ISA Server computer, irrespective of ISA Server system policy or other custom rules that may allow it. This approach is recommended for better security, as your firewall should not be accessible as a file server!

Amend Bind Order:

Edit the bind order as follows:

Internal Network (Highest)
Perimeter Network(s)
…Others…
External Network (Lowest)

Multiple NIC Deployment - ISA Server Enterprise Edition

With ISA Server Enterprise Edition, it is recommended to add a dedicated Intra-Array NIC. Therefore, we need to consider this additional interface in our configuration.

Rename NICs:

Rename all NICs to descriptive names that ideally match the ISA Server network names.

Internal Network
Intra-Array Network
Anonymous Access Perimeter Network 
Authenticated Access Perimeter Network
External Network
Etc.

Configure NICs:

Internal Network

Default Gateway should not be defined
DNS Servers should be defined
Register this connection’s address in DNS – Enabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Intra-Array Network

Default Gateway should not be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Enabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Perimeter Network(s)

Default Gateway should not be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Disabled
NetBIOS over TCP/IP – Disabled
Show icon in notification area when connected – Enabled

External Network

Default Gateway should be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Disabled
NetBIOS over TCP/IP – Disabled
Show icon in notification area when connected – Enabled

Amend Bind Order:

Edit the network bind order as follows:

Internal Network (Highest)
Intra-Array Network
Perimeter Network(s)
…Others…
External Network (Lowest)

Single NIC Deployment – ISA Server Standard Edition

For a single NIC deployment, the following actions are recommended.

Rename NICs:

Rename all NICs to descriptive names that ideally match the ISA Server network names.

Internal Network

By matching the names, this makes mapping networks between ISA Server and Windows much easier when troubleshooting…

Configure NICs:

Internal Network

Default Gateway should be defined
DNS Servers should be defined
Register this connection’s address in DNS – Enabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Please Note: Disabling the 'File and Print Sharing for Microsoft Networks' binding on the ISA Server internal interface will prevent you from connecting to shares on the ISA Server computer, irrespective of ISA Server system policy or other custom rules that may allow it. This approach is recommended for better security, as your firewall should not be accessible as a file server!

Single NIC Deployment – ISA Server Enterprise Edition

For a single NIC deployment, the following actions are recommended.

Rename NICs:

Rename all NICs to descriptive names that ideally match the ISA Server network names.

Internal Network
Intra-Array Network

By matching the names, this makes mapping networks between ISA Server and Windows much easier when troubleshooting…

Configure NICs:

Internal Network

Default Gateway should be defined
DNS Servers should be defined
Register this connection’s address in DNS – Enabled
File and Print Sharing for Microsoft Networks – Disabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Intra-Array Network

Default Gateway should not be defined
DNS Servers should not be defined
Register this connection’s address in DNS – Disabled
File and Print Sharing for Microsoft Networks – Enabled
Client for Microsoft Networks – Enabled
NetBIOS over TCP/IP – Enabled
Show icon in notification area when connected – Enabled

Please Note: Disabling the 'File and Print Sharing for Microsoft Networks' binding on the ISA Server internal interface will prevent you from connecting to shares on the ISA Server computer, irrespective of ISA Server system policy or other custom rules that may allow it. This approach is recommended for better security, as your firewall should not be accessible as a file server!

Amend Bind Order:

Edit the network bind order as follows:

Internal Network (Highest)
Intra-Array Network

I hope this helps!