IAG Logs - Extending?

A common issue raised by customers have been regarding how far back the IAG logs can go back.

I have posted in the past about how to use Syslog server with IAG, which will allow the logs to be stored elsewhere for longer, but you may still have issues with what or how much is being reported.

Extending your historical logs:

• In the IAG Configuration console, select the "Admin" menu and select "Event Logging"
• Select the "General" tab
• Change the "Queue Size" to 100
• Change the "Max Report Results" to 10000
• Click on "OK"
• Activate the IAG Configuration

Change the settings for report clean up:

• In the IAG Configuration console, select the "Admin" menu and select "Advanced Configuration"
• Change "Start Cleanup at:" to 10000
• Change "Stop Cleanup at" to 100
• Change "Number of Undeleted Files" to 100
• Click on "OK"
• Activate the IAG Configuration

You may need to wait up to 48 hours to see if these changes have helped, but these settings can be tweaked further to fine tune the logs for your reporting needs.

IAG SP2 Update 3?

Well I've had word that IAG SP2 Update 3 should be out in a month or so.

The components being addressed with this update, are that Windows 7 will be recognised correctly and 64-bit clients will be supported.

Obviously you have seen that I have documented a 32-bit Windows 7 workaround, but there are still issues with this when using certain applications. The only 64-bit client that can be made work is Windows 7, as long as your computer has the ability to run XP Compatibility Mode (which will mean that only specific processors are supported)

As soon as I see that update, I will get it installed and tested, as my work laptop is both Windows 7 and 64-bit..... you can see I like a challenge!!

Happy New Year for 2010!

And what a way to see in the New Year.

Currently where I live in the UK there is 3-4 inches of snow, which has made it very difficult to get off my driveway, let alone drive to work.

Fortunately I can work from home, thanks to a Celestix WSA appliance running Microsoft IAG!

I have access to my emails via OWA, intranet site, CRM server and Terminal Server.

This has allowed me to pretty much carry on as normal!

If you are stuck at home today, I hope you are working!! ;)

Microsoft CRM 4.0 on a non-IE browser and IAG

At e92plus we use Microsoft CRM 4.0 as our CRM system. It is a good product that allows a lot of flexibility, granularity and customisation, but the downside out of the box is that it will only work with an IE browser.

Not a major issue you may think as all the computers at work are all Windows devices.

As you can see in the previous post, we were in the process of replacing our mobile telephones at work, and as part of the rollout, I wanted to offer IAG via the mobile phone. I know it works(albeit very slowly) on a Blackberry and (pretty well with 3G) on iPhones.

Now if we were issuing mobile devices with internet access to the staff, I not only want them able to access the IAG, I also want to give them the ability to access our CRM system.

My choices were to look at Windows Mobile devices, but there is either a comprise on cost or functionality, or find a way to get CRM available on other browsers.

A bit of Googling from Neil Langridge (Marketing Manager for e92plus) turned up the following links:

http://blogs.msdn.com/crm/archive/2009/07/09/product-release-mobile-express-for-microsoft-dynamics-crm-4-0.aspx
http://weblogs.asp.net/gayanperera/archive/2009/07/10/dynamics-crm-4-mobile-express-released.aspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=F592EC6C-F412-4FD5-9A80-CD3BCBD26D8B&displaylang=en

After following the instructions on installing the 28Mb file, we then started testing.

I used Firefox, Safari, Opera and Chrome as my test browsers and they all worked perfectly. The view is slightly cut down, but we now have CRM on other browsers.

The next step was publishing this on IAG as a Generic Web Application (as I did for CRM on IE). Remember to use the server name, correct port number as well as the /m after the URL. I created an access policy to check the users browser, so that if they are using IE they have two icons (one for full blown CRM, and other for the "streamlined" version), and if they are using a non-IE browser they only see the "streamlined" version of CRM.

I have been playing with a number of mobile phones recently, and this works perfectly on Blackberrys, iPhones, Nokia and HTC Windows Mobile devices.

ActiveSync on IAG, with iPhones

The mobile phone contracts at work are up, so I have been investigating alternatives. We were previously using Blackberrys, but I've been investigating more cost effective options. Since the Blackberry server was installed, we have upgraded to Exchange 2007, which gives us the aability to us Push Mail/ActiveSync, something that was not an option on our previous mail server.

I was given a couple of test phones to trail ActiveSync on a Windows Mobile and a Nokia device.

First off, I had to ensure ActiveSync was enable on the Exchange server, and fortunately a "vanilla" build of Exchange 2007 haas it enable on install.

The thing was the create a NAT rule on my firewall to allow the ActiveSync traffic from the intenet to the Exchange server. This was only a temporary rule while I was testing ActiveSync worked, before the rule was removed again.

My security/paranoia head would not allow me to leave this rule in place, as I would not recommend to anyone to have a rule that allows direct connectivity from the internet to any mail server. (BTW that also includes email, as there are plenty of mail relay options, such as a Barracuda Spam Firewall - Blog post for another day!)

Here at e92plus as the saying goes "We eat our own dog food", where we use a Celestix WSA IAG appliance as a remote access solution.

The next step was for me to create way for the mobile device to connect to my Exchange server, without a direct connection. I configured one of our external IP addresses to NAT into the DMZ of our firewall. I then had to add an additional IP address on the external adapter of the Celestix WSA appliance to match the DMZ IP address of the NAT rule. I also created a new prefix for our domain, and mapped that to the external IP address I'm using.

Now on to IAG, create a new webmail trunk and selected ActiveSync. I defined the domain, selected the DMZ IP address, defined the details of my Exchange server, aand then activated the configuration.

I took the Trusted Root Certificate from my Exchange server and applied that to the IAG appliance.

From the mobile devices, I defined the domain, username and password. For the server address, I use the new IAG portal address.

It worked perfectly on the demo Nokia E63 and the HTC Touch, although the interfaces were different the information required to login was the same. This allows the devices to sync up emails, contacts, calendar and tasks.

After much deliberation, I decided that I wanted an iPhone as my mobile device. Although I am still waiting for the SIM to be activated, ActiveSync is syncing my email, contacts and calendar via my wireless network, so once the iPhone can get onto the O2 3G network, it will be working as it should!

For added security/paranoia, on the Exchange server I have also enabled mandatory passwords on the device, madatory encryption of the storage and the ability to remote wipe the devices, so pretty much the core features of a Blackberry server, at a much lower cost!

Web Monitor Logs

A common question I'm asked, is how can I keep my Web Monitor logs for longer. Ensure you have SP2 Update 1 installed for this feature.

Just feed the logs into a Syslog server, sounds easy...

• Start up the IAG Configuration application
• Select 'Admin' at the top and select 'Event logging'
• Select the 'Syslog' tab and enter in the details of your Syslog server

Sometimes, we just want an easy solution.... and here is one!

I've had a play with a freeware Syslog server called Syslog Watcher, which works very well with this integration, but would welcome any recommendations for Syslog software.

High Availability for IAG

After four hours on the train today, I spent a fair chunk of today configuring a pair of Celestix Load Balancers for an IAG deployment.

The only way to create IAG in a highly available configuration, is to put the IAG solution behind a front end load balancer. A common question I get asked is why do I recommend a pair of load balancers... well why would specify a solution with multiple application servers, only to place them behind a single load balancer and risk moving your single of failure from the application server, to the load balancing solution.

There are some simple instructions on how to configure the Celestix Load Balancers (CLB) and well documented in the manuals, but here are some headline points when configuring the solution for Direct Server Return (DSR), where the load balancer coming into the IAG solution, but outbound (as the name suggests) the IAG solution will go directly back to the client, rather than through the load balancer.

1. Configure the IAG external IP address to the be the virtual server IP address
2. Ensure DSR is selected in the advanced settings
3. Under the Healthcheck option for the target, ensure PING is off, but check TCPOpen ais enabled for 443,2,10
4. Ensure all IP addresses are unique, including gateways, servers, engines, etc.
5. Create an ISA rule to allow access from the CLB range to the Local Host, for port 443.
6. Create loopback adapters for the WSA appliance, ensuring that there is no gateway, and within advanced ssettings, the Interface Metric is set to 254
7. Ensure VRRP is enable, where both appliances have the same VRID, ensure the Master has a priority of 1 and the backup of 254, on a different network
8. Ensure the local host files that the server name points to the VIP

I had a pretty unique situation today, where four portals were configured on two IAG appliances, with virtual IPs and load balancers.

We ended up using 14 external IP addresses, VIP for each portal (4 external IPs), an external IP for each portal on each appliance (8 external IPs), and a unique IP for each load balancer (2 external IPs). It's very rare to have this many real IPs to play with, but the same principle would apply, if these IPs were internal ones behind a NAT'ing device, which would only have required 4 external IPs (one for each portal)

Ensure you understand the customer requirements and follow the manual.

Good luck with maaking your IAG solutions highly available! :)

ActiveSync on IAG - Certificate Issues

I realised the other day that I hadn't updated the issue that was encountered within this blog post about ActiveSync on IAG.

Well the issue turned out to be certificate related. The Exchange server was using a self signed certificate, so the trusted root certificate had to be added to the mobile devices.

There is some well documented information with regards to configuring Exchange 2003 ActiveSync using a self-signed SSL certificate.

Export the root certificate

1. On the Certificate Authority that issued the certificate to the Exchange server, open the Control Panel and double click Internet Options. NOTE - this guide assumes that you are using a Microsoft CA.
2. Click on the Content tab and then on the Certificates button.
3. Click on the Trusted Root Certification Authorities tab.
4. Locate the trusted root certificate for your domain. It is vital that the certificate be trusted rather than be listed under any other tab. Select the certificate and click on the Export button.
5. The Export Certificate Wizard will be displayed, click Next.
6. Select the option to export the certificate in DER encoded binary X.509 (.CER) format and click Next.
7. Enter a name for the certificate and specify where you would like the file saved. Click Next,
8. Finish and then OK.

Install the root certificate onto the client device

1. Now locate the .cer file created and copy it to your PDA via Microsoft ActiveSync to any folder on the device (for a Windows Mobile device), or using the appropriate synchronisation software for your device. Alternatively the file could also be saved to a memory card or transferred via Bluetooth.
2. On the PDA, open File Explorer and browse to the folder where you saved the certificate.
3. Tap on the icon for the certificate and tap Yes to install it when prompted.
4. On a Windows Mobile device, tap on Start → Settings → System → Certificates → Root and verify that the certificate is listed.
5. You are now ready to use Server ActiveSync securely, using your own SSL certificate.

There is also some useful troubleshooting information here: http://blogs.technet.com/edgeaccessblog/archive/2008/07/29/publishing-microsoft-activesync-through-iag-2007-part-2-of-2.aspx

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 63-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!!!

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 support!!

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

Multiple URLs with IAG

Thanks to my hosting provider Titan Internet , I have a very comprehensive statistics package which shows the top search phrases that leads people to this blog.

One of the phrases recently was:"IAG allow several URL"

In short yes, IAG will allow multiple URLs, where each URL will access a different trunks.

So you will be able to host a number of URLs and trunks, all with a different look and feel, as well as different authentication methods. There are some limitations, such as File Access can only be configured once, and not to different shares for different trunks.

So you could have the following:

Company wide remote access

URL: https://iag.mycompany.com

Authentication: AD & HOTPin

Endpoint Protection: Machine must be running AV software

Applications: OWA, SharePoint, CRM, File Access & Terminal Server

Technical Support remote access

URL: https://tech.mycompany.com

Authentication: AD & VASCO

Endpoint Protection: Machine must be a member of the domain

Applications: OWA, SharePoint, CRM, File Access, Terminal Server & RDP access to servers

Auditor Access

URL: https://audit.mycompany.com

Authentication: Local Users & RADIUS

Endpoint Protection: Machine must be running AV software

Applications: Accounting database (authorisation by user account)

Partner Access

URL: https://partner.mycompany.com

Authentication: Novell

Endpoint Protection: None

Applications: Intranet Access (authorisation by user account)

The granularity is there for a number of different portals, and each one can have a different look and feel, with a different URL.

Have fun trying this!!!

Installing Windows 7 using a USB memory stick

As I have a few days off work, I decided to rebuild my Windows 7 netbook, which led me to find a useful website again. I know a few people have struggled to get Windows 7 onto their computers as netbooks and some laptops don't have DVD drives.

I created a bootable memory stick so that I could install Windows 7 on my Advent 4211 netbook (MSI Wind clone) and have done the same for a few friends who are not so computer literate.

This website gives very good step-by-step instructions on how to do this: http://www.intowindows.com/how-to-install-windows-7vista-from-usb-drive-detailed-100-working-guide/

Bear in mind you will need a Vista or Windows 7 machine in order to create this.

ActiveSync on IAG

ActiveSync is a pretty straight forward component to activate on IAG.... or at least it normally is, but I got an support question about it today.

Probably best to start with the basics first, and some more useful information gathered along the way.

The starting point with most application should be this document regarding applications that IAG is aware of: IAG Application Aware [1.0Mb]

Someone pointed me towards these Microsoft blog entries, which gives a little more detail:
Publishing Microsoft Activesync through IAG2007 - Part 1 of 2
Publishing Microsoft Activesync through IAG2007 - Part 2 of 2

Another useful component is this Microsoft Exchange Server Remote Connectivity Analyser, which can test the connections to ensure your configuration works. (Thanks Andrew for showing me this, it will be very useful!)

The analyser will allow you to check the connection including SSL certificates and server name, connection to the trunk, AD authentication, connection to the Exchange server and the OPTIONS commands.

The issues we had today were regarding the OPTIONS commands, as everything else seems to work. More investigation to follow..... and hopefully an answer!

Avira and IAG

The last few days I've been speaking to a reseller who purchased Avira AntiVir Professional Anti Virus software from e92plus.

They were having issues connecting their PC to an IAG solution! For some reason, since the AV change from McAfee to Avira, they were unable to access an IAG solution. The IAG solution was not deployed or implemented by e92plus, so it was just fortunate that I work with both products.

My initial reaction to the description of the problem, was that the IAG solution was not up to date, and lacked IAG SP2, which would give WMI recognition which works with all versions of Avira. Prior to SP2, IAG would only recognise Avira V6 or V7. The reseller checked with the IAG supplier and it turns out that SP2 is already installed.

My colleague tried to access the site from an XP machine running Avira 8, and was able to access it. The reseller had installed the latest version of Avira Professional which is version 9, and the assumption was that was the problem. I tried to access the site from an Vista machine running Avira 9, and again I was able to access the site!

With a bit more digging, it turns out that the endpoints must meet three criteria before they are able to login.

1. Must have an anti-virus application running
2. Must have a software firewall running
3. Must have the IAG components installed and running

So at e92plus we also use an IAG appliance, which would explain why we were able to access the site. This would mean that our machines meet the above requirements as all these components were installed.

Checking with the reseller, we highlighted that without the IAG components installed, it would not work. These components will require adminsitrative rights to install. Despite their frustration, I was not able to help from an IAG perspective, but pointed them in the right direction, as the offline installation package may be required due to a corrupted installation, or not having adminstrative rights when the initial installation was run.

They were able to access the site from both Vista and XP machines with Avira version 9, as well as e92plus proving that we were able to access from Vista and XP machines with both Avira version 8 and 9.

The issue that the reseller now has is that on site, it will not work with their client's machines, and the finger was pointed at Avira.

I can catergorically say, I don't believe the issue to lie with Avira, as we were able to prove from a number of machines that it works. Despite this, it was requested that we escalate this with Avira, and they also see no issue with their product!!

Although I understand our resellers frustration, the troubleshooting needs to be with the IAG side or the client installation, rather than the AV! The troubleshooting should start with the log files from the IAG server, but as the supplier of the IAG solution seems reluctant to help our reseller, so they are stuck between a rock and hard place!!

Celestix WSA evaluation... and RDP queries!

At e92plus we have a number of Celestix evaluation units for proof of concepts, and today I spent the day installing one.

We had a number of applications to install, including OWA, Intranet site and RDP which all were very straight forward.

They run a number of Citrix servers, but we had an issue publishing this. Publishing as a browser embedded application, we had issues as we could not apply a root certificate to the broswer. The end user will create a web based Citrix environment, which I will remotely configure once this has been deployed.

I got a call from a reseller, where there was an issue with an RDP session, where the application would start up the Windows Remote Desktop Client, but would not populate the server name. The fix is to set the Initial Server as the server you want to RDP to.

There was also a query about how use local drives within an RDP session. It's something I've struggled with in the past, but as it wasn't essential I didn't get a chance to get a definitive answer. Something to look into...

Websense as well....

I guess from reading this blog, you would assume that I only work with Celestix products! I have to say it feels a bit like that recently has I'm running a 3-4 IAG web demonstrations a week now, along with evaluation and real installations.

I work with Websense a lot as well, and it's easy to forget that Websense not only provide web filtering, but also email and data security products.

Today, I ran a web demo for a Websense Web Security solution, which runs perfectly in an ISA environment, including the Celestix MSA appliances. The discussion turned to Web 2.0 and user generated content, where a solution such as Websense Web Security Gateway comes into its own.

Websense WSG, has to run on a Linux platform and will not run on Windows. This solution can be the proxy and cache server, negating the need for a third party proxy such as Bluecoat or Microsoft ISA server.

WSG runs an anti virus scanner at the gateway, which is not supplied with Websense Web Security, but could be an add-on for Microsoft ISA server, where something like Avira AntiVir for ISA Server would work.

Another shortcoming of Websense Web Filter or Web Security is that it can not deal with user generated content or SSL encrypted content.

Traditional web filtering solutions can not filter feeds into pages such as iGoogle. The page is "seen" as being google.com so completely allows it, the problem is that iGoogle can have feeds from Hotmail, GMail, Facebook, etc which are normally blocked. By using WSG, the individual feeds can be allowed, blocked, quota'd or confirmed.

Traditional web filtering solutions will not be able to filter SSL packets, but the Linux gateway will be able to be the "man in the middle", where it will be able to decrypt, inspect, and either discard the packet or re-encrypt the packet and forward it on.

Content inspection can also be carried out on the fly!!

With all these features of dynamic user content filtering, SSL filtering, on the fly content filtering, why are users on jumping at this product? The issue is not really price, but rather the Linux server that the software must run on!! It's amazing how many people are still put off my Linux!!

Busy day with new eyes!

A few things, firstly my eyes are a little sore, but even after a couple of days my vision is as good as it was with contact lenses!!

Anyway.... a couple of IAG bits to cover:

1) An evaluation that needed to be scoped! Some interesting bits as they want to look at: RSA (ACE), Celestix HOTPin, KCD and Windows 2003 AD authentication, with OWA, Sharepoint, File Access and Citrix (Web & client based). I'm confident with all the components, except for the KCD. Anyone who has ever worked with KCD, will not it's not always straight forward! Research will happen next week, so we'll see from there.

2) Pre-sales call, where we needed to be able to publish Terminal Server and use Swivel as the authentication method. IAG can either "pop" the RDP client and create a secure tunnel to connect the client to the Terminal Server, or to connect to TSWeb, which will then connect to the terminal server. It's not like AEP Netilla, which will start up a Java RDP client, which will allow any machine with Java to be able to connect to a Terminal Server. As for Swivel, I know a number of IAG/Whale Communication partners that use Swivel as the authentication method, but not something I've used. If it's based on RADIUS, then the only thing that the customer will need to investigate is how to ensure the webpages are displayed correctly.

A few things to look up to learn a bit more, so KCD and Swivel research!!

A day in the life of an IAG installation... (Part 2)

Right... day two!

We tried the VMWare View configuration first, but it seems that the Security Server element wasn't deployed, so they cracked on a deployed one!!

We spent a little getting the IP phone working, but it seems that the ports that I Googled didn't let it work!! We ran Wireshark, but nothing showed up that we didn't already allow. The conclusion was to do one of two things; call up the supplier and see if they can shed any light on the port configuration, or utilise the NAT feature on the IP softphone, which would allow the traffic to traverse the firewall and not use the SSL-VPN!

We ran through the customisation element of the IAG appliance. Initally we used the component on the Celestix web UI, which avoids the need for looking at the coding. The next element was the look at how to manually modify the site.

This guide was written by Michael Riva, who attended the same IAG course as me, which helps with the basics:
http://www.isaserver.org/tutorials/Customizing-IAG-2007-Portal-Pages.html

Also check out the manual (the link of which is below) which was written by someone technical, so you are not treated like an idiot!!

We also installed CAPTCHA on to the appliance, which requires a sub-400Kb file to be installed on the appliance, and some minor changes to the URL sets to make it work. What is CAPTCHA, well more information here: http://www.captcha.net/ Contact Celestix for more information as to how you can get this on your Celestix WSA appliance.

We ended the day talking about administrative tasks, backing up configurations and most importantly... changing all the default passwords!!

Another happy customer! It's great to be involved from the beginning, carrying out the webinar and presales component, understanding the customer's requirements, architecting the solution, scoping out the implementation, then carry out the implementation! :)

A day in the life of an IAG installation...

Today I'm away from home carrying out a two day installation for a Celestix WSA/Microsoft IAG appliance.

This was a slightly different implementation as the firewall is hosted offsite and they don't have a traditional DMZ. After a couple of chats with the ISP, we managed to get a new subnet implemented, creating a virtual DMZ. Bear in mind that IAG can not be deployed a single NIC server, it needs to have an external and internal zone.

The customer had a number of requirements, including OWA 2007, SharePoint, RDP access, an intranet site, file access and granular endpoint/access policies, which all go swimmingly. As well as ensuring that the appliance was correctly service packed to SP2 Update1.

The challenges today (and there are always challenges with an IAG installation) included SSH connections to Linux servers, and Telnet terminal emulation application. These were made to work as bespoke client/server applications, along with automatic startup of the associated applications and the correct switches to start them up on the correct screens. These should have been straight forward, but as everyone uses different clients, the testing of the various switches took a bit of time. There was also an issue with a static route, but was dictated incorrectly, but as ever check the obvious first, such as..... manually entered IP addresses!!

So a fair chunk done for the day, but two things left me scratching my head. Two outstanding applications need to be dealt with, as I have never seen or used either before. The first was a VMWare View implementation and a Mitel 8602 IP Softphone. As I'm in a hotel tonight, it gave me a chance to do some Googling and see if any of this helps.

VMWare View (Deploy as a browser embedded application)
Frontend: Ports 80 & 443
Backend: Ports 3389 (RDP), 4001 (JMS) and 8009 (AJP13)

Mitel 8602 IP Softphone (Deploy as a client/server application)
5566 - TCP
5567 - UDP
5004 to 5069 - TCP
6004 to 6247 - TCP & UDP

We'll see if those fix the issues tomorrow! Then it only leaves customisation, administration overview and housekeeping, which means a packed day ahead!

Useful IAG Links

Primarily an ISA forum, but there is an IAG section on the messageboard: http://www.isaserver.org
A forum focused on IAG: http://forums.forefrontsecurity.org
Independent Wiki for IAG: http://www.ssl-vpn.de/wiki/

Java client not working on IAG?

This is a bit of a common issue, but it's not normally noticed as the tests are normally carried out on IE, so it uses the ActiveX components, which aren't an issue.

The fix (found here: http://forums.forefrontsecurity.org/?g=posts&m=553):

The default rule set blocking the java-client, so make the following changes to the URL list:

InternalSite_Rule28: (/internalsite/applet/(sslvpnclientdetectjavamicrosoftclientoesislocalruntimeelevatoragent_win
_helperagent_mac_helperagent_lin_helper)\.jar) change Parameters value Reject to: Ignore

Duplicate rule 29: Change URL value of new rule to: /internalsite/com/whale/sslvpnclient/whalesslvpnclient/class.class

It worked for my Firefox users, but didn't impact me using ActiveX clients on IE8.

Celestix and Microsoft IAG

What is Microsoft Intelligent Application Gateway (IAG)?

It's an remote application delivery platform or as some would call it.... an SSL-VPN.

It's a way of delivering the applicatons you use internally at work, to an external audience via HTTPS.

The IAG can interogate computers to check what operating system it runs, whether there are specific applications running (such as anti-virus software, software based firewalls, etc), whether the computer is a member of a domain, etc.

By coupling endpoint checks, along with user credentials, granular understanding of applications, reporting and monitoring. We have a secure delivery method, as we can ensure correct users, can access correct applications, with approved computers, and be able to see who, accessed what and when. Sounds pretty comprehensive!!

This product originally was made by Whale Communications and was developed about ten years ago, prior to being bought out my Microsoft. This software platform is avalable on the Celestix WSA appliance. If you are based in the UK and want to evaluate an appliance, contact e92plus on 020-8274 7000

Some useful resources for those new to IAG are available here:

Celestix WSA Quick Start Guide [3.8Mb]
Microsoft IAG User Guide [3.32Mb]
Microsoft IAG Advanced User Guide [2.77Mb]

Microsoft IAG 2007 Service Pack 2 - Notes
Microsoft ActivePerl (which must be installed prior to SP2) [15.8Mb]
Microsoft IAG 2007 Service Pack 2 [36.5Mb]

Microsoft IAG 2007 Service Pack 2 Update 1 - Notes
Microsoft IAG 2007 Service Pack 2 Update 1 [19.8Mb]

Celestix and Microsoft ISA

For the last three years, I've been working at e92plus as the Technical Manager. We have a portfolio of products, some have gone since then, some new ones have come, but the one I took a shine to was Celestix.

Celestix make hardened Windows appliances that run Microsoft ISA Server, and Microsoft IAG Server.

I have been a Microsoft Certified Professional (MCP) since 1998... (yes, I'm that old and then some!) and have worked with NT3.51 through to Windows 2008.

It seemed like the logical step for me to take the Celestix product range under my wing.

I started playing with Windows ISA 2006 nearly three years ago, but a majority of these deployments have been as a proxy and cache, but have seen the other flavours as well.

Any way the point of this post is to list the useful resources that have helped me along the way:

http://www.isaserver.org/ - A proper ISA guru - Thanks Tom! :)
http://blog.msfirewall.org.uk/ - Jason Jones of Silversands is an MVP based in the UK
http://tmgblog.richardhicks.com/ - Recently I meet Richard Hicks of Celestix, and this is his blog