Booches.nl

VMware: upgrade VMware Tools and Virtual Hardware for Microsoft ISA array

Today I have been troubleshooting problems with a Microsoft ISA array. The array didn’t function anymore after moving the Configuration Storage Server and one array member from a VMware 3.5 environment to a VMware 4.0 environment. After moving the array member the VMware Tools were upgraded and also the Virtual Hardware was upgraded. After rebooting the moved array member the customer received multiple error messages, like duplicate IP addresses and users not able to access resource through the reverse proxy.

A Microsoft ISA array uses Network Load-Balancing and NLB was the cause of all problems. After upgrading the VMware Tools and the Virtual Hardware, NLB needs to be reconfigured. The complete configuration of NLB was lost. I reconfigured NLB (multicast with IGMP support) and the problem was resolved. The array members were functioning properly again.

Moving and upgrading the second array member resulted in the same problems with the same cause. Reconfiguring NLB on the second array member did the trick. So be careful when moving ISA array members with NLB configured from a VMware 3.5 to a VMware 4.0 environment, especially when upgrading VMware Tools and the Virtual Hardware.

Microsoft ISA publishing – it’s all in the “path”

I have installed multiple reverse proxy servers based on Microsoft ISA 2006. These reverse proxy servers are mainly deployed to publish services like Outlook WebAccess, PDA synchronization, SharePoint or regular websites. Services like Outlook WebAccess are published using secure session protected by SSL certificates. Microsoft ISA server uses “Listeners” to match and intercept traffic from public users.

I have seen multiple ISA publishing rules with only match traffic when the user enters the specific URL in the browser. Let’s take OWA as an example. When users would like to access OWA, they need to enter the following URL: https://webmail.booches.nl/owa. The base URL is webmail.booches.nl and users need to add /owa manually, because internally the Exchange server is configured with a virtual directory called owa. Sometimes I see Listeners configured for HTTP and HTTPS and all HTTP traffic is redirected to HTTPS.

Is this solution user-friendly? What happens when the users makes a typo and enters http://webmail.booches.nl/ower? I try to configure the publishing rules to be user-friendly and I always configure separate Listeners for HTTP and HTTPS traffic. When publishing OWA I configure 3 firewall policy rules.

1. 1. The first rule redirects all HTTP traffic (http://webmail.booches.nl/* to https://webmail.booches.nl/owa;
2. 2. The second rule intercepts all the OWA traffic (https://webmail.booches.nl/owa);
3. 3. The third rule redirects all HTTPS traffic (https://webmail.booches.nl/* to https://webmail.booches.nl/owa);

The first rule uses a Listener, which is configured for HTTP-only traffic and doesn’t use authentication. The firewall policy is intended for All Users and there is no authentication delegation.

	Action for HTTP and HTTPS redirect is to block the request and redirect the request to the correct URL for OWA
	The Listener for HTTP is configured without Authentication method and the rule is intended for All Users
	The public path contains /*

The second rule uses a Listener for HTTPS-only traffic and uses HTML Forms Authentication with LDAP, RADIUS or another authentication method. The associated firewall policy is intended for all Authenticated Users and uses authentication delegation based on Basic Authentication or Negotiate (NTLM / Kerberos) authentication.

	The Listener for HTTPs is configured with FBA as authentication method and the rule is intended for Authenticated Users. The authentication delegation is configured for Basic Authentication or Negotiate
	The public path configuration contains the appropriate Exchange virtual directories

The third firewall policy uses the same Listener as the second rule, but doesn’t use authentication delegation and is intended for all users. The configuration of the path, users and authentication delegation is the same as the first rule.

When you need to publish additional services, like ActiveSync or Outlook Anywhere, you have to add the specific publishing rules between the second and the third rule, so the redirection doesn’t mess up your publishing.

This setup is very user-friendly, at least that’s my opinion. The public user only needs to type the base URL (webmail.booches.nl) correct and he is always redirected to the OWA sign-in page. Service like ActiveSync or Outlook Anywhere are automatically configured to use the correct public path (/Microsoft-Server-ActiveSync or /rpc).

Problem running ISA en IAS on the same server

Today I had some problems running ISA 2004 en IAS on the same server. At the beginning the customer was running ISA 2000 and IAS on the same server without any problems. By incident, the customer was forced to upgrade his ISA. They had a 2004 license, so ISA 2004 it was.

I noticed that ISA 2004 puts a “Default ISA policy” with the highest priority in the remote access policies. The rule blocks all RADIUS requests, so I had to manually remove the access policy. After the removal everything was working fine again.

I had to change the configuration in the ISA server again and the “Default ISA policy” came back in IAS. So I had to delete the rule again. I also tried to change the priority of the rule, but the “Default ISA policy” gets the highest priority again after applying a change in ISA.

I cannot find anything specific about this problem on the internet, so maybe someone experienced this before and can provide me with an answer to disable this behavior.

ISA 2006 Link Translation

Web pages returned from a Web server published by a Microsoft® Internet Security and Acceleration (ISA) Server 2006 Web publishing rule may include links containing internal names of computers or Web sites and internal paths to Web content. Because external clients cannot resolve these internal names, these links will be broken unless the internal names are replaced by the public names of published Web sites. ISA Server includes a built-in Web filter named Link Translation Filter, which uses mappings to translate internal names in links on Web pages to publicly resolvable names. Each mapping translates an internal URL (or part of a URL) to a public equivalent. For example, a mapping can translate the internal URL http://team to the public URL https://www.team.contoso.com. Link translation mappings are stored in tables called link translation dictionaries.

Today I had a problem where the remote user wanted to request the following URL https://www.booches.nl/configuration/service.jsp. This URL isn’t allowed and needed to be redirected. ISA’s Link Translation was the solution for me. I configured the following Link Translation.

The following Link Translation rule translates the URL above in https://www.booches.nl/configuration/denied.html.

It works for me!!!

ISA 2006 Web Chaining

ISA Web Chaining rules define how traffic will be handled by the proxy server. Web request to specific destination can be handled in different ways by ISA:

1. Retrieve directly from the destination / internet;
2. Forward to an upstream proxy server;
3. Redirect the request to a specific server / web page;

The most popular use for Web Chaining is to chain branch office ISA firewalls with main office ISA firewalls. But also combining two ISP connections is a commonly used scenario for Web Chaining. I often use Web Chaining from ISA server with some kind of upstream proxy server. A lot of organizations use ISA as proxy server and some kind of dedicated appliance (maybe in DMZ environment) as content scanner.

With Web Chaining you can forward all request to the upstream proxy server, which will retrieve the specified destination from the internet. Specific website could have problems with being forwarded to the upstream server. I normally use Web Chaining to directly retrieve these website from the internet without being forwarded to the upstream proxy.

To create a Web Chaing Rule, open the ISA Management Console and navigate to Networks. In the center of the Management Console you will find a tab called Web Chaining. The default Web Chaining rule is configured to forward all request to an upstream proxy server.

The following screenshots tell you how to configure an additional Web Chaining rule to directly retrieve the destination (www.4ip.nl) from the internet.

	Start the creation of a Web Chaining rule by clicking on Task – Create new Web Chaining rule. This will start the New Web Chaining Rule Wizard. Enter a valid name for the newly created Web Chaining Rule.
	Select the destination to which this Web Chaining Rule will apply. I configured an URL set containing the URL: http://www.4ip.nl/*
	On the Request Action page, you configure how you want the Web requests to that particular destination routed by the ISA firewall. The default setting is to route the request directly to the destination Web site. This is exactly what I would like to accomplish. The last step is Finishing the New Web Chaining Rule Wizard.

The newly created Web Chaining Rule is placed above the Default Web Chaining rule in the Web Chaining tab. The rules are matched sequentially, so now all traffic matching the configured URL set will be retrieved directly from the internet. All other traffic will be forwarded to the upstream proxy server.