Tuesday, 2 December 2008

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:

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!

Wednesday, 26 November 2008

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 :)

Friday, 24 October 2008

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.

Tuesday, 26 August 2008

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!

Friday, 1 August 2008

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 normally 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