IAG SP2 Update 2... finally!

There were a number of rumours that SP2 Update 2 would include 64 bit client support, but it seems it was just that... a rumour! The current rumour is that 64 bit client support will be available with SP2 Update 3, which is good considering we were always told that IAG would never support 64 bit operating systems. We can make Windows 7 64-bit work by using XP Mode (and detailed in the previous blog posting)

After QA testing from Celestix, IAG SP2 Update 2 is now available from the Celestix website.

The following issues are addressed with this update:

• Fixed erroneous IAG behavior when headers contain blank characters
• For trunks which do not publish an AAM application, the IAG Session cookie will be a site cookie instead of a domain cookie
• Fixed bug for supporting Citrix XenApp5 application
• Fixed parsing of text/html response Content-type (not binary) body using Chunked encoding type
• Fixed a failure occurring when using IAG’s Socket Forwarding client component on a Citrix terminal server
• Fixed a SharePoint Persistent Cookie Name Race Condition
• Fixed an Authorization Key Header memory Corruption while using an "Authorization Key" header
• Fixed a failure in the endpoint detection policy of AVG on the client computer (mistyped value in the detection policy expression)
• Fixed an Incorrect header removal when header is substring of another header
• Fixed Day Light Saving change leading to a deletion of Internalsite and Portal rules
• The communication between Windows Mobile 6.1 and Exchange 2007 SP1 has changed slightly due to the updating of the EAS protocol to EAS v12.1 – added support/fix for it
• Enabling above 2KB http header request by modifying the following registry key (MaxAllHeadersLen), to prevent SNT from throwing the following error to the client: "Allow http header block of a request to exceed 2KB and avoid SNT throwing an error"
• Fixed non English locales inconsistent encoding/decoding detection
• Fixed few issues related to FormLogin authentication
• Modified the rule-set that broke Java SSL Wrapper
• Added support iPhone and Blackberry support
• Fixed non-IE detection security issues

IAG SP2 Update 2 - Release_Notes

IAG SP2 Update 2 - Installation File

Does IAG work with Windows 7 (64 bit)?

After much experimenting with Windows 7 32 bit, you can see you are able to get Microsoft IAG to work with it, as can be been in one of my previous blog posts.

Now I hope we are all aware that 64-bit Windows operating systems are not supported by IAG. I know there were rumours of 64-bit support being released with IAG SP 2 Update 2, but that is not the case. We will discuss this update is a later blog posting.

Well I was fortunate enough to be provided with a new work laptop, which has a faster processor, bigger hard disk and more importantly 4GB RAM. I did initially install Windows 7 Enterprise 32-bit, but was disappointed to only see that 3GB was recognised by the OS (I would have lived with only 3.25-3.5GB being seen), so I bit the bullet and installed Windows 7 Enterprise 64-bit so that all the RAM is seen and can be used.

I know that Windows 7 64-bit will allow you to install applications as either 32 or 64 bit, so some things like Java should be installed twice to work with both 32 and 64-bit IE browsers, will specific 32 bit applications an be installed and used. That said, despite the workaround detailed for Windows 7 32 bit, this does not work in Windows 7 64 bit!

Luckily, Microsoft have a Windows XP Mode as a solution: http://www.microsoft.com/windows/virtual-pc/download.aspx

By installing Windows Virtual PC RC and Windows XP Mode RC, it will allow you to run a virtualised version of XP on your Windows 7 desktop. There are not additional licenses to consider, but you will need a processor with either Intel® Virtualization Technology or AMD-V™ feature turned on. I downloaded this application from the Intel website to check that my processor supported this feature from here: http://www.intel.com/support/processors/tools/piu/

I found these step by step instructions on Windows 7 XP Mode, which I found very useful: http://lifehacker.com/5245396/set-up-and-use-xp-mode-in-windows-7

Once installed and working, I also installed Avira Premium Security Suite software to remove the Microsoft Security Centre red shield.

I created a shortcut into the all users folder of the virtualised desktop, to my IAG website. This also placed the shortcut into the start menu of my Windows 7 Enterprise 64 bit. By clicking the link, it will start up an IE browser to my IAG appliance from the XP virtual environment, which gives a pretty seamless experience and I retain full IAG functionality.... phew!!!

Websense Hosted Email Security Training

I had a very interesting day learning more about Websense Hosted Email Security.

People always assume that any hosted (or Software as a Service - SaaS, for the hip and groovy Twitter generation) solution is more expensive, but it's just a common misconception, along with other common myths:

1. Cost - It will be more expensive than an appliance or software
2. Control - You will lose control of the solution
3. Data Leaks - The soution will not be able to protect from data leakage
4. Security/Privacy - Your email will not be secure
5. Reliability - The solution will not be reliable

Well these should be addressed:

1. Cost - Have all costs been taken into account, including additional hardware, subscriptions, bandwidth, storage, electricity and labour!
2. Control - Websense provides 24x7 control, including policy control, user/group policies, LDAP synchronisation, message search facilities, end user quarantine and flexible reporting.
3. Data Leaks - Websense includes built in data leak protection, including dictionaires, deep content inspection and custom dictionaires with support for regular expressions.
4. Security/Privacy - Websense is just another hop in the chain for the email. Websense is ISO27001 certified, and TLS can be used to create a secure channel to the Websense datacentres.
5. Reliability - Websense provides a 99.999% availability SLA

To summarise the Websense Hosted Email Security:

• Increased protection, coupled with an SLA
• Reduce costs
• Retain control

Why wouldn't you use the hosted solution???!!!

IAG and Citrix XenApp 5

I had a fun day in Northampton on Monday and it was thanks to Wayne and Daryl for being such great company!

A seemingly straight forward IAG implementation, with straight forward requirements:

The applications required were OWA and Citrix XenApp, with RDP as a nice to have. The authentication methods were Windows AD and VASCO. Basic customisation and guidelines about housekeeping and DR.

We were replacing a SonicWALL SSL-VPN solution, which works in a single NIC configuration, so a number of services were needed from the appliance back into the LAN. We started by reviewing the firewall rules, removing the existing SonicWALL SSL-VPN rules, and creating a port 80 and 443 access on the WAN side of the Celestix appliance, as well double checking existing NAT rules to ensure that the external side was accessible through the internet.

The authenication methods were straight forward, but an oversight on the VASCO delayed the deployment, but after creating the backend to point at the IAG appliance, it was up and running!

OWA worked fine, but oddly RDP didn't work back to the blade servers, but did the Celestix appliance. Obviously a configuration on the blade servers need to be modified, but not really my field of expertise. Apparently this blade server setup can be configured with a web interface, so that could be published as a generic web app, when it's up and running.

The existing SSL certificate on the SonicWALL was moved to the Celestix appliance, after creating the CSR file from within IIS and getting the supplier to reissue the certificate. It was getting late, but the certificate wasn't working. We were unable to access the website, but we could with the self signed certificate. My gut feel was an issue with either the CSR file, or the creation of the CER file. We reverted back to the self signed certificate, but the customer was going to recreate the CSR file and get another reissue..... I found out today that this solved the issue!! (Phew!)

The reason for this blog entry was really due to the issue we encountered with the Citrix XenApp! Having deployed a number of Celestix appliances to work with Citrix Presentation Servers, I was quite confident that there really wouldn't be much difference with XenApp..... (How wrong I was!!)

I published the XenApp server and all seemed to work, but when you start up the application, we recieved the following message: Error: Cookies Required

My gut feel was that as XenApp worked before the issue lay with the configuration within IAG. After a bit of searching, we found this Citrix article: http://support.citrix.com/article/CTX117597

This article didn't really hit the nail on the head, but after a little experimentation, we found that this solved the issue, as detailed by the customer. As this software will not allow me to post Javascript code correctly, please find the details in the text file: XenApp5.txt

Does IAG work with Windows 7 (32 bit)?

Well IAG did work when I was using Windows 7 RC (32 bit) on my netbook, but it no longer works on Windows 7 RTM (32 bit)!! :( I couldn't even get the login page to show!!

A bit of Googling found these instructions:

1. Copy the folder located here from your Celestix WSA appliance: C:\Whale-Com\e-Gap\utils\OfflineClientSetup to a temporary location on your computer
2. Find "Setup.exe" and set the compartibility mode to "Windows Vista SP2"
3. Find "ComponentsConfig.xml", and edit the Network Connector entry so install="1"
4. Run the setup.exe (as administrator)
5. Select either normal or custom, depending on what is required
6. Ignore the error "Can not register Whale Client Components whlvaw.dll" and finish the program
7. Start up the Command Prompt as Administrator, then start up Powershell within the command shell
8. Switch to the path "C:\Program Files\Whale Communications\Client Components\3.1.0″
9. Execute the command: "regsvr32 whlvaw.dll" (Attention: Ignore the Warning about the Driver installation and select YES)
10. The Network Connector should work as long as you start Internet Explorer as Administrator, because the file "whlioc.exe" & "whliocsv.exe" require local administrator rights.

The original post is here: http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/a7ca54cc-60e7-467a-961c-fc4b32151249 - Thanks Joerg! :)

IAG to protect internal systems?

Going through the search phrases, again I see that a few people have looked up using IAG internally.

Can IAG to used to protect internal systems? Yes, but you have to get your networking principles correct!

Although I have not done this, I understand the principle and I know where this has been deployed.

Imagine you run a datacentre (a proper datacentre, and not a glorified server room!!!) where physical security is as important as network security.

With an IAG server deployed to service a datacentre, you no longer have to give physical access to your datacentre for software installation/configuration/reconfiguration.

So in reception you have a number of PCs which can access the external side of the IAG appliance. The authenication is set up using one time password (OTP) solution, so they are only able to access the server this one time. You could also restrict access to the trunk to only the computers in reception.

When they log, they can either be presented with a portal showing the RDP connections to the servers they look after, or have the start up application as the RDP session itself, rather than present a portal.

Just remember than you still need to have two network segments for this to work, as IAG can not run in a single NIC setup as explained previously in this blog.

HA deployment of IAG, using CLB

I spent the last couple of days in Wakefield, helping out a reseller with a high available deployment of Celestix WSA appliances using Celestix Load Balancers. Thanks for the company David!! :)

We started by configuring the Celestix Load Balancer (also known as CLB), after configuring the solution we were informed that the internet lines would be a number of weeks away, and we would not know whether the IPs that would be provided would be either external internet facing IP addresses, or NAT'd internal addresses. Why would this be an issue?

Well the customer wanted four IAG portals to be created, and as each portal would have to be created on both appliances. With the CLB in front of the IAG appliances, the way the IP addresses are presented will impact on how to deploy the solution.

If the addresses are external facing, we would need 12 external IP address, three for each portal (one on each appliance, and one for the virtual IP). If the addresses are NAT'd, then there would only be a need for one external address as the virtual IP on each portal.

We only configured one IAG appliance, and then backed up and restored the configuration on the second IAG appliance. Obviously the IP addressing needs to be changed, and the certificate information to be modified, but that was pretty much it.

We were deploying OWA, Sharepoint, Citrix, Mapped Drives, File Access, RDP and an IIS based intranet site.

From an authentication perspective, we looked at AD, AD & HOTPin, AD & Vasco Middleware (RADIUS) and just HOTPin. As expected the authentication methods were straight forward and I got a chance to use HOTPin a bit more. We configured HOTPin on the primary box, and had the secondary box referencing the primary box. You only have to allow port 10000 access between the appliances, and using local administration credentials is fine. The only pain was HOTPin not scanning AD correctly in subtrees, which means each OU would need to be defined when importing users, but I'll let Celestix know about that.

We also encoutered the Java issue, so that was resolved using the fix from one of my previous blog posts.

We can only complete the deployment, once we know how the IPs will be presented.... which will also impact the way we can balance the load (do we use DSR or not, VRRP, Loopback adapter configuration, etc, etc).... Let's see!

Another trip to Birmingham!

Another trip to Birmingham, another Celestix WSA/Microsoft IAG proof of concept!

Pretty straightforward today, where we used Windows 2003 and a RADIUS based authenication solution called SecureIT.

Applications we deployed were OWA, a couple of intranet sites, RDP session and Network Connector.

The appliance was deployed in a workgroup, so we needed to use FQDN for the internal servers.

SecureIT requires the IAG server to be defined within the software, which includes IP address and which ports to use.

There was an issue with the Network Connector, which seem to lie with the authenication methods defined and changed. We needed to define both AD and SecureIT as the authentication methods, and then re-define the Network Connector.

There was an issue with the external IP address, but fortunately we could prove it works with a crossover cable and a laptop defined with an IP address on the external range.

IAG & VASCO?

Another search phrase that I thought I could answer!

Yes, IAG will work with VASCO!

VASCO Middleware and Identikey use the RADIUS protocol, and RADIUS can be configured as one of the authenication methods on IAG.

You will need to define the VASCO server, along with the correct ports and shared secret.

I would configure Windows AD authentication and VASCO, so the user would need to login with AD username, AD password and VASCO one time password.

In the past, I have installed VASCO Middleware on the IAG appliance, but this would be subject to the number of users/tokens required. Unless you are looking at single figures of VASCO tokens, I would recommend that the VASCO server be installed somewhere else.

Complicated POC...?

I was expecting a long day today....

I knew that this proof of concept was more demanding, as we were looking to use AD, RSA and KCD authentication, and deploy a number of applications.

The trunk was created and it was configured to use RSA (via ACE server) and Windows 2003 (using KCD), but with this configured the login page would not be delivered.

We agreed to disable the KCD in order to carry on with the POC. The next issue was RSA!! The RSA client is installed on the appliance, but required RSA files to be copied on to the appliance to get it to work. I don't deal with RSA, but fortunately the customer resolved this.

After a little confusion about RPC access, we should be clear. The IAG appliance does not support the use of ISA features!! The ISA is there for the SSL-VPN and the ISA features should not be used for anything else!

We deployed OWA, Citrix, Sharepoint, File Access (using a NetApp filer), Network Access, RDP sessions, telnet, as well as discussed policies and customisation.

Outlook access was being left on the MSA appliance, where ISA would manage the RPC connection.

I expected difficulties with the NetApp filer, but as it can be accessed via NETBIOS, all the shares were visable through the File Access application.

The POC went smoothly and it was fortunate that I was working with someone technical! Some of the issues I'd normally have to work around with HOST files or self signed certificates were avoided as the customer knew what to expect! Thanks Matt!

Straight forward POC....?

A trip to Brimingham was on the cards today, but I'm going in blind!

I didn't manage to speak to the end user before this proof of concept, but I was pretty confident that I could deal with most situations.

Luckily we were deploying OWA, Citrix, Sharepoint and RDP sessions.

It all went swimmingly and the only difference was that we were using an external IP address directly on the appliance, instead of using a DMZ. This was fine until....

We tried to deploy an additional trunk for third parties/contractors, and this was where using two external IP addresses on the NIC (one as an aliase) we came unstuck.

The box would only hold one external IP address, and would not release it correctly to allow access for the other trunk.

Previously when I have deployed a similar solution, we were using DMZ addresses, so that seemed like the logical solution.

Once the firewall was configured correctly within the DMZ with the correct NAT rules, it worked perfectly!

Single NIC deployment of IAG.....

....... is not supported!!

Another search phrase which hits this blog has been "single NIC IAG deployment", so lets clear that up.

A single NIC deployment is not supported.... why? Well IAG uses ISA to segment the LAN and WAN zones, so ISA needs to be able to differentiate the trusted LAN zone, and everything else (the WAN).

The typical deployment is to deploy the external side into the DMZ of an existing firewall. The internal side would then be deployed into the LAN, of course!

The external side can be connected directly the internet, such as an ADSL router, and again the internal side into the LAN.

I have encountered some different deployment issues, such as MPLS networks where they have externally managed firewalls, with just a single internal subnet, so no DMZ.

There are two ways around this, the suggestion from Microsoft was to either deploy a firewall, such as ISA.... or to deploy two IAG deployments.

The first IAG appliance will be just to carry out authentication, where the external side will be the existing subnet, and the internal side would be a new subnet. The second IAG appliance would then be used to deploy applications, where the external side would be the new subnet, and the internal side would be the existing subnet where the application servers are located.

Fortunately when I last encountered this, the MPLS provider supplied an additional subnet, which was accessible from the internet, but no where internally. Basically they provided me with a DMZ.

Also to reiterate that on the external side, you only need provide HTTP and HTTPS access. Why HTTP as we are deploying an HTTP solution, but we can create an HTTP redirect. This way your users only need to remember the URL, but don't need to remember the the HTTPS!!