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