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

ISDN Backup – still alive?

Nowadays everybody wants redundancy within their network, especially when using remote sites. Customers are using multiple ISP’s for redundancy and/or configure BGP solutions. In the old days (hear me talking with my 27 years) ISDN was often used for backup purposes and I still use it sometimes as redundancy mechanism. Everybody knows that bandwidth is the main limitation for ISDN connections, but for emergency purposes or for low-bandwidth applications, ISDN could be the ideal backup mechanism.

Lets take a look at the scenario, where two networks (HQ and branch office) are connected by an IP VPN connection. This connection is the primary channel for communication between the HQ and the branch office. The IP VPN connection is terminated by a Cisco router or something comparable. Both locations also have a backup connection based on ISDN technology. The ISDN connection is also terminated on a Cisco router. You can also terminate both connections on the same router, but to increase the availability you should use separate routers. The IP VPN is preferred over the secondary ISDN connection. Both routers within the same location are configured with HSRP and the IP VPN router is the active gateway for its LAN.

The failover from the primary to the secondary connection should be performed automatically. This requires at least the configuration of a routing protocol. Since I often use Cisco routers, I would configure EIGRP as routing protocol to exchange routing information. You could also choose to use OSPF. Choosing EIGRP or OSPF as the preferred routing protocol could be worth a blog post on its own.

To form an adjacency between to routers, both routers need to be neighbors of each other. I normally configure a GRE tunnel between the two IP VPN routers, so they become “directly connected”. Both IP VPN routers can now exchange routing information. Next I would configure the dial-up connection. Mostly all traffic is directed from the branch office to the HQ, so the branch office would dial the HQ.

The ISDN router could participate in the EIGRP process. If you do so you need to exclude the EIGRP packet from the ISDN interesting traffic to prevent the ISDN connection from dialing to the HQ. There are more choices to make, like letting the ISDN routers form adjacencies when the ISDN connection is active. You can also use floating static routes on the ISDN routers and redistribute these routes into the routing protocol. You can tweak the HSRP operation by using HSRP tracking to promote the ISDN router to the active default gateway, when the IP VPN connection is unavailable.

In my opinion ISDN connections could still be a very valid way to provide a backup connection between two network locations. What is your opinion about this technology?

RSA AM 7.1SP3 Token Delivery

Using two-factor authentication is common when publishing remote services to the internet with components like Citrix NetScaler or Juniper SA appliances. RSA is a well-known provider of two-factor authentication mechanism.

Beginning with RSA Authentication Manager 7.1 people have the ability to use the On-Demand feature. This feature enables the delivery of token codes via SMS or e-mail. When using this feature you had to publish the RSA Self-Service website to the internet, so users can request a token code. The RSA Self-Service website is displayed below.

The procedure for opening a extra website to request an On-Demand token is difficult to understand for many people and increases the risk of problems and errors during the authentication process.

This behavior is changed in RSA AM 7.1SP3. With SP3 the Authentication Agent has possibility to generate the On-Demand token request on behalf of the user. The procedure to login to the Authenticaton Agent is:

1. 1. Browse to the portal website
2. 2. Enter your user credentials (username + password)
3. 3. Enter only the token PIN code
4. 4. The Authentication Agent generates the On-Demand token request and redirects the user to a website to enter the On-Demand token code
5. 5. The user waits for the delivery of the token via SMS or e-mail
6. 6. The user enters the On-Demand token code on the Authentication Agents website
7. 7. The Authentication Agent validates the token code and displays the web portal

This way the delivery of token codes is less prone to problems and errors during the authentication process. I personally like this new feature.

Citrix NetScaler: Protocol Driver Error

Today I have been troubleshooting a Citrix NetScaler configuration, where some clients received the Protocol Driver Error message when executing a published application. This error message is mostly related to a wrong configuration of the Security Ticket Authorities (STA’s). I spent a lot of time troubleshooting this issue and focused on the STA configuration. I have been deleting, adding and modifying multiple STA’s to the configuration of the NetScaler without any luck. I checked the configuration of the firewall, but this wasn’t the problem either.

I decided to go back to basic and just added one STA to the Virtual Server and the STA service group used by the Web Interface. I was able to login with that STA server, but after a while I wasn’t able to login and received the Protocol Driver Error again.

While browsing through the NetScaler I noticed one thing. Every time I wasn’t able to login, there were 5 concurrent users already connected with the NetScaler. I did some more research on the internet and found the following article.

Reading the article, tells me that, by default, only 5 concurrent ICA sessions are possible through the NetScaler. I checked the license and the customer has a license for 50 SSL VPN connections, like shown below:

> show license
License status:
Web Logging: YES
Surge Protection: NO
Load Balancing: YES
Content Switching: YES
Cache Redirection: NO
Sure Connect: NO
Compression Control: NO
Delta Compression: NO
Priority Queuing: NO
SSL Offloading: YES
Global Server Load Balancing: NO
GSLB Proximity: NO
Http DoS Protection: NO
Dynamic Routing: YES
Content Filtering: YES
Integrated Caching: NO
SSL VPN: YES  (Maximum users = 50)
AAA: NO
OSPF Routing: NO
RIP Routing: NO
BGP Routing: NO
Rewrite: YES
IPv6 protocol translation: YES
Application Firewall: NO
Responder: YES
HTML Injection: NO
NetScaler Push: NO

I increased the default value to 50 with the following command:

> set aaa parameter -maxAAAUsers 50

From that point on I was able to start another ICA connection, while there were already 5 concurrent users connected. Now I have to wait and see if this actually solved the problem, but I guess it has.

I tried to increase the –maxAAAUsers value to a value higher than 50, but that isn’t possible as you can see.

> set aaa parameter -maxAAAUsers 100
ERROR: MaxAAAUsers value not allowed by license