Creating a SSTP split tunnel in UAG

I like to provide remote access by publishing applications on UAG, but there are times when a full VPN tunnel gets around a number of issues, but may reduce your security posture.  I don't like to make changes to the security unless they are respected or being used by responsible people.  For most people using the SSTP VPN tunnel feature in UAG would be adequate, but there are times when a user needs a split tunnel.

I was told that SSTP in UAG did not support split tunnels, but there seems to be a workaround with this blog post: http://blogs.technet.com/b/fsl/archive/2011/01/26/uag-sstp-split-tunnel.aspx

In trying this myself, I did the following:

I went to the following location: C:\Program Files\Microsoft Forefront UAG\Endpoint Components\3.1.0 (The location of your files may be different depending to what service pack level you are at with UAG). 

Copy the 'sstp.pbk' file to the desktop, and rename the original file in the original location (I chose 'sstp.pbk_old').  Go back to the desktop and double click on the 'sstp.pbk' file you just copied.

You will be presented with the following box, where you need to select 'Properties':

Highlight 'Internet Protocol Version 4 (TCP/IPv4)', and then click on the 'Properties' button:

From this screen, you will need to selected the 'Advanced' button:

From this box, uncheck the 'Use default gateway on remote network' option, and close all the boxes.

Take the modified 'sstp.pbk' file and copy it back to the original location.

To prove the difference it makes, I took a 'route print' using the original 'sstp.pbk' file, and a 'route print' of the modified 'sstp.pbk' file.

I haven't tested this in anger, but looks like it will solve the issue we currently encountering.

UAG ActiveX issues on IE10

I saw something today that I had not encountered before.  I had a user connecting to my UAG setup, but it seemed like the UAG client would install when running as administrator, but would not run.

After running a remote session, I spotted that there was an extra icon that I had not seen before on the IE10 address bar:

 

It turns out this is an ActiveX filter built into Internet Explorer.  Although with it running, the UAG components can not execute, meaning only web applications will run.

This feature can be disable by going to the cog icon, clicking on "Safety" and then unchecking "ActiveX Filtering"

Importing UAG applications to another server

Today, I had to build two additional UAG servers with the same applications as the original one I deployed.  I used the following procedure to achieve this:

1. On the original UAG server, export the configuration and give it a password.
2. Configure the new UAG server with the appropriate networking information, including LAN and WAN IP details, static routes on the server, ensure the networking is reflected in TMG.
3. Patched up the new UAG server to the same level as the original server.
4. Import the configuration to the new UAG server.
5. Activate the configuration.
6. Change the hostname on the truck (and remember to change the hostname on OWA, if you are using this feature)
7. Ensure the right certificate is in the certificate store and associated with the trunk.
8. SSL Network Tunnelling IP addresses will need to be added, if you are using this feature.
9. Check the AD authentication service account password (and secret keys for RADIUS authentications, if being used) as these were removed from one restore, but not the other!

Hope that helps, if you have to do the same.

UAG File Access Script Errors Post SP3...

Today, I was looking at UAG SP3 installation, where we were configuring OWA, CRM and SharePoint.

We encountered an issue with File Access, it was working prior to SP3, but since SP3, when you try to access the console, we were getting the following script error:

A bit of Googling, brought up this blog article that I know solved the issue with other UAG users: http://itcalls.blogspot.co.uk/2013/03/uag-2010-file-access-application-fails.html but it didn't resolve my issue.

I ended up doing the following to get it to work:

• In the UAG Management Console, remove File Access from the UAG application list
• Activated the UAG configuration without File Access
• Rebooted the server
• Installed UAG SP3 Rollup 1 (following this previous blog article: http://blog.andytang.com/2013/07/service-packs-on-uag.html)
• Activate the UAG configuration
• Reboot the server
• In the UAG Management Console, on the toolbar click on "Admin", then "File Access..."
• When prompted if you want to enable NETBIOS, agree to this
• Log into the File Access console using your NETBIOS domain administrator credentials
• I can now browse the File Access structure without the script error

Enjoy!

UAG SP3 install fails and rollsback...

On site again this week, with another UAG installation, but this one offered something different as we were creating a gateway for mobile devices.

We encountered some issues installing service packs on the Celestix WSA UAG appliance.

As my previous post shows how to install SP2 and SP3, I had a failed install of SP2 this week.  The issue was not permissions, but failed after 10 minutes, after which the service pack would roll back.  A bit of a search brought up this Microsoft article:
http://support.microsoft.com/kb/2811066

I followed Method 1, which meant opening Notepad as an Administrator, then editing the following file:
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\Machine.config

I added the following text, just before the </configuration> tag near the end of the file:

<system.transactions>   

<machineSettings maxTimeout="01:00:00" />

</system.transactions>

This effectively increases the timeout from 10 minutes to 1 hour, which resolved the issue for us.

 

Service Packs on UAG...

In the past I've never encountered issues service packing the UAG software running on Celestix WSA appliances.  Recently I had a situation on site where the service packs would not apply by simply double clicking them, and after a bit of trial and error found the optimum way to get these installed.

I was using a Celestix WSA appliance, with build 2.4.0.0, which runs UAG 2010 SP1 Update 1.

I downloaded all the Windows and Celestix updates for the appliance, as well as TMG SP2, UAG SP2 and UAG SP3.

I found the best way to install the updates were as follows:

• Run through the UAG quick start to get UAG online, but there is no need to create a portal (assuming this is a new install)
• Apply the Windows updates and Celestix updates, then reboot
• Apply TMG SP2, then reboot
• Double clicking on UAG SP2 or SP3 will not install correctly, so follow the procedure in the point below.
• Open up the Command Prompt as Administrator, then while holding down the shift key, right click on the UAG SP2 file, and select "Copy as path".  Right click on the command screen and paste this link in, then run it.  Follow the instructions to install UAG SP2 and reboot.
• Open up UAG and check that the version number has changed from 4.0.1xxx.xxxxx to 4.0.2095.10000, then activate the UAG configuration.
• Open up the Command Prompt as Administrator, then while holding down the shift key, right click on the UAG SP3 file, and select "Copy as path".  Right click on the command screen and paste this link in, then run it.  Follow the instructions to install UAG SP3 and reboot.
• Open up UAG and check that the version number has changed from 4.0.2095.10000 to 4.0.3123.10000, then activate the UAG configuration.

You now have a UAG appliance up to service pack 3 ready for your portal.

Publishing Citrix XenApp 6.5 on UAG 2010

I'm not a fan of publishing XenApp on UAG.  Much as there is a wizard, it only works with older versions of XenApp, so you end up having to make a number of modifications to UAG whether it be coding or registry changes, which may end up breaking when you update to a new version of XenApp or apply UAG service packs.

Last week I had to publish Citrix XenApp 6.5, but on testing the main screen just loops.  So fortunately, Ben Ari came to my rescue via this blog post: http://blogs.technet.com/b/ben/archive/2011/10/05/issues-with-citrix-5-4.aspx

Another issue that pops-up with Citrix often, and has been reported to occur with Citrix 5.4 is a looping behavior, where trying to launch the application triggers the browser to loop through the login page repeatedly, ad infinitum. This is caused by a change to the way Citrix handles cookies. To fix it, one needs to configure UAG to treat the cookies a little differently, and that is done via a custom SRA and AppWrap configuration.

To resolve this, you will need to create two XML files on your server, and populate them with the content that I will include ahead. Be careful when copying the content, to preserve a good structure. If any of the XML tags gets broken, it cause UAG to produce a 500 error, so be prepared to back-out any changes if you run into issues. You may also contact me directly via the contact-me form to obtain the files directly from me. The 2^nd file there is the more sensitive one, as it has a very long line of text that must be kept intact.

Here are the steps:

1. Copy the content of the first box below into a text file, and save it as “WhlFiltSecureRemote_HTTPS.XML” on your UAG server, under the folder <UAG Path>\Von\Conf\Websites\<Your Trunk>\Conf\CustomUpdate
2. Look at the path settings (highlighted below in green). Your actual path for the Citrix installation may differ (a common variation is /Citrix/XenApp/auth/). If so, change it in the file you create.
3. Copy the content of the second box below into a text file, and save it as “WhlFiltAppWrap_HTTPS.XML” on your UAG server, under the same folder
4. If there are files by those names in there already, STOP! The files CAN be combined, but it could be tricky to do, and I recommend opening a support case with Microsoft CSS to work-through that process.
5. Activate your UAG configuration

The code for the XML files are available from Ben's blog post.

I did encounter an issue though.  This works perfectly on UAG 2010 SP2, but as soon as I applied UAG 2010 SP3, it no longer worked.  Instead of taking you seamlessly into the XenApp application, it presented Windows 2008 R2 login screen.  If you enter your details it works, but if you try to start up another application it would prompt for a login again.  It seems that the SP3 update no longer passes the credentials for the XenApp SSO to work.  I'll update, if I can find out why.

Publishing Microsoft Lync 2010 using Microsoft UAG 2010

I've been working with Microsoft UAG since it's been available.  I had a head start as I was using and deploying IAG and Whale previously, which were the two predecessors to UAG.

I've published a few different applications, but a majority of the solutions will include Microsoft Exchange (whether it's OWA, full Outlook and/or ActiveSync), RDP connections (usually for administrators to access servers or to Terminal Servers), and some sort of Intranet or SharePoint site.  Some of the rarer occasions I've been asked to give terminal access to AS/400 solutions, publish VMware View, deliver the Neocoretech VDI solution using HTML 5 clients on iPads, etc, etc.

So when I was asked to deploy Lync 2010, I was pretty confident it would be straightforward.  I did some research to ensure I was following best practise, but ended up using a few documents to achieve a fully working solution.  Please note I wasn't doing this blind as I had deployed Lync in our office, but could make it work with UAG without real certificates (as is highlighted in the following instructions)

I was deploying an SSL-VPN portal as well as creating a Lync connection for the computers, which meant I modified some of the configurations given.

The first document I used was this one:
http://social.technet.microsoft.com/wiki/contents/articles/14000.publish-lync-2010-with-forefront-unified-access-gateway-2010-uag.aspx

Ensure you have all the domain names for the various Lync components, but I used a different document for this.

As ever, I was deploying a Celestix WSA solution, which was straightforward.  I followed Georg Thomas' instructions, but did not follow the section on the "Additional Trunk Configuration" as this would impact my SSL-VPN portal.  I did create the registry key as described, but also follow Erez Ben Ari's blog here with the additional registry key: http://blogs.technet.com/b/edgeaccessblog/archive/2012/06/15/lync-publishing-on-uag.aspx

I would typically use wildcard certificates, but as these do not work with Lync on UAG, we has to use a SAN (Subject Alternate Name) certificate.  As I have never done this before, I followed these comprehensive instructions: http://technet.microsoft.com/en-us/library/gg429704.aspx  The request of the certificate from the provider is the same as a "normal" or wildcard certificate, as is the installation.

Thanks the well written documents abover, the publishing of Lync 2010 was straightforward.

UAG - Activating your configuration

The first few times I used UAG, I wondered why it took so long to activate the configuration.  Even though the finish screen came up, the configuration would not always be live.

There is an easy way to check this by using the messages.  On the main UAG screen, click on "Messages" and select "Filter Messages...", then select "Informational messages".

So the before the finish button would appear after activation:

But if you have a look at the following screen, you can see it takes a bit longer before the activation is completed.

UAG - RDP set up

I've been struggling with publishing RDP on my test UAG appliance, as it was not the same as IAG.

First of all, publish the application which is located on the "Terminal Services (TS)/Remote Desktop Services (RDS)", where you have "RemoteApp" for use with Windows 2008 Terminal Services, Remote Desktop (Predefined and User defined), as well as the two options available from IAG.

I can't use the two options from IAG, as they do not support 64-bit clients (and I use Windows 7 64-bit).

Publish the application as Remote Desktop, either predefined so no user interaction, or user defined where the user will need to specify the desktop to connect to.

Give the application a name, set up the appropriate access policy, define the server to connect to, configure the client settings, ensure the portal link information is correct and ensure the authorisation is correct.

As I found out, this alone will not work and your will receive an error, which points to certificate issues.

As the UAG appliance is the Remote Desktop Gateway, a certificate will need to be applied to it.  Go to the Start menu, and select "Administrative Tools/Remote Desktop Services/Remote Desktop Gateway Manager".  From there expand the server, and you will see an option to apply a certificate to the gateway.

Apply the appropriate certificate and enjoy remote access!

Microsoft UAG Update 1

Microsoft released UAG Update 1 last month, which updates the following areas:

• Remote Desktop access from Windows Vista and Windows XP: Client endpoints running Windows Vista and Windows XP can now access RemoteApps and Remote Desktops published through Forefront UAG.
• Support for Microsoft SharePoint Server 2010: Forefront UAG now supports SharePoint Server 2010.
• Support for MSOFBA: Forefront UAG now supports the Office Forms Based Authentication protocol to allow rich clients to directly access applications published through Forefront UAG.
• Support for site cookies: Forefront UAG now supports the use of site cookies for non-alternate access mapping applications, in addition to domain cookies.
• Support for large CustomUpdate files: Forefront UAG now supports CustomUpdate files up to 1.5 GB in size.
• Changes in Group Policy Object (GPO) provisioning for DirectAccess clients: Update 1 fixes an issue that caused the export script that creates GPO objects to fail, and an issue that caused the GPO to be applied to all authenticated users in the domain (including computer accounts), instead of to DirectAccess clients only.

More information regarding this update can be downloaded from here

VMWare View on Microsoft IAG

VMWare View has been a bit of a pain to a number of people, but here what I have done in the past to get it to work.  (Thanks to Andrew Button for helping to remind me of some of these bits!!)

Let me be clear, I am not a VMWare expert in any fashion, and I have little knowledge of VMWare View!

1. Ensure VMWare View works internally first
2. Ensure a VMWare Security Server has been deployed (this tip was thanks to my  friend, Google)
3. On IAG, publish a "Enchanced Generic Client App (hosts optional)"
4. Give the application a name and the right access policy
5. Give the server name that is hosting the VMWare View server, with the correct port (probably 443, if you are using HTTPS), iexplore as the executable, and the argument is the full URL for the service
6. Finish the wizard
7. Go into the properies and ensure that the Socket Forwarding Mode is set to VPN
8. Publish and test

I have been struggling with making this SSO, but no joy.  If this changes, I will update this post!

ASP Error when configuring File Access within IAG

I was on site when I encountered an odd issue.  When configuring the File Access component within IAG, we got teh following ASP error:

Request object error 'ASP 0104:80004005'

Operation not allowed /whalefilesharingadmin/computers.asp, line 47

Thanks for Senthil from Celestix who found the answer to this.

The error was being caused due to the size limit in IIS for the maximum number of bytes allowed in the entity body of an ASP request.

The answer is to locate this file:

C:\Windows\System32\Inetsrv\metabase.xml

and modify the following value:

AspMaxRequestEntityAllowed to 1073741824

This changes the excepted size limit to 1GB.

Testing IAG SP2 Update 3 - Part 3

Having been distracted from IAG with the impending launch of UAG on the Celestix platform, and Websense launching their Triton platform, I finally found time today to do some more testing.

Uri from Eurodata dropped me an email checking if my AD repository was the same as my domain (which it isn't!), as this would save having to edit inc files after an upgrade.  Step 9 of the following article: http://blogs.technet.com/edgeaccessblog/archive/2008/07/24/publishing-microsoft-activesync-through-iag-2007-part-1-of-2.aspx

Today I reset my demo appliance and tried the following:

• Configure the networking components of my Celestix WSA applaince
• Install Java, Active Perl, SP2 and SP2 Update 2
• Create an ActiveSync trunk
• Import my Exchange certificate
• Use an AD repository that is named the same my domain
• Modify the ASP file mentioned above
• Test - Success!
• Install SP2 Update 3
• Test - Success!
• Recreate my portal trunk for my applications
• Test - Success!

Now IAG SP2 Update 3 is working successfully in a new installation (albeit via SP2 Update 2, rather than straight to SP2 Update 3), I will try an in-place upgrade on my known working appliance.

Thanks for the email Uri, as it motivated me to look at this issue again!! :)

Testing IAG SP2 Update 3 - Part 2

Here is some useful information from the MS UAG Blog about IAG SP2 Update 3.

The table in the link is very useful at summerising what is and isn't supported.

Socket forwarding is not supported by any 64 bit Windows operating system, as well as Mac & Linux machines.  I have seen this with my Windows 7 64 laptop, which does not work with published RDP sessions, but can confirm that XP compatibility mode does work.

The Network Connector will not work with either 32 or 64 bit Windows 7 machines, as well as Mac & Linux machines.  I can confirm this as a customer and I have tested this, although I have yet to test a Windows 7 in XP compatibility mode with the Network Connector, but I suspect it will work.

Although this update was meant to be the "fix" for Windows 7 and IAG, I'm afraid there are still limitations.

IAG is dead.... long live UAG!

Testing IAG SP2 Update 3 - Part 1

I managed to get my hands on SP2 Update 3 for IAG v3.7 a week or so ago.

So far I've only managed to deploy this to my live environment, but with some good and bad results!

My current IAG platform is a Celestix WSA 4000, and it has been Service Packed and updated pretty much as and when these updates have been available.

As I'm a little wary of these things, I use the Celestix Last Good Version (LGV) feature, which allows me to take a snapshot of my appliance and save this to a Linux partition on the appliance. It takes around 15 minutes to make this snapshot, and around 10 minutes to rollback... if required!

My appliance hosts a portal with various applications such as OWA, Intranet, RDP, etc, as well as an ActiveSync tunnel for our mobile devices.

After the update was applied, the portal worked perfectly with both Windows 7 32-bit and 64-bit machines, but it broke my ActiveSync tunnel!

One of my authentication methods is Active Directory and it is used for both the Portal and ActiveSync tunnel. The authentication using AD was perfect on the Portal, but it failed for the ActiveSync tunnel. All the mobile devices said the wrong password was being presented.

No changes were made to the mobile devices and this impacted both Nokia E71 and Apple iPhones. Changing the password on the device made no difference, but we knew that the AD authenication should be working correctly as the portal works.

Rolling the appliance back to SP2 Update 2 using the LGV feature, allowed all the mobile device to authenicate again, even though someof these devices did not have their password changed.

Since then, I've managed to get hold of another appliance to test with, so Part 2 will continue tomorrow.....

Two factor authentication tokens on iPhone

I've been playing with the iPhone recently and I've been very impressed with the amount of applications you can get for the phone.

The other day after some prompting from the UK Vasco Technical Account Manager, I installed a Vasco Digipass for the iPhone. (Thanks Dan)

So now I have a demo Digipass on my phone, where I can use it for demonstration purposes. It was fairly straight forward, you need to download the app from the Apple AppStore and tap in a couple of codes to make it work. Obviously I need a Vasco server installed somewhere and install the relevant DPX file on it, so the token can be used.

Off the back of this success, I took the opportunity to install a Celestix HOTPin client on my iPhone as well.

Again, just download the iPhone client software from the Apple AppStore. You will need to ensure that the Celestix HOTPin server is running somewhere. Currently it can run on the Celestix WSA appliance, which negates the need for an additional server hardware. Once the server component is configured and users added to the system, it is ready to go.

I used the HOTPin client on the iPhone to communicate with my Celestix WSA appliance which is hosting the HOTPin server. It downloads the client.dat file onto the iPhone and the client then allows the phone to generate the one time passwords.

The Vasco token required a bit more information to set up and they have the advantage of being able to provide your users with hard tokens, software tokens, mobile phone tokens and OTP via SMS, all through a single server element and manage them from one console.

The Celestix is a more cost effective solution as the HOTPin server software can run on the Celestix WSA appliance and there is no server software cost as such. The only down side is that there is no hard token option, so you may encounter some friction from users as they will not want the HOTPin client installed on their own personal mobile devices, although you have the option for a software client on Windows or using OTP vis SMS.

Although both solutions support receiving the one time password via SMS, what happens if your users are in a mobile telephone blackspot?


- Posted using BlogPress from my iPhone

Microsoft IAG SP2 Update 3

Information from Microsoft regarding: IAG SP2 Update 3

Once this has been tested by Celestix, it will be available for download from the webiste.

It will also give me a chance to test it in my lab as well.

Routing issues on IAG

I was asked this evening by a friend and customer why he was unable to remotely access a Celestix WSA appliance via a VPN, but able to access via an RDP session from one of the servers on the LAN.

There is a site to site IPSEC VPN between the two sites and the remote site subnet had been added into the Remote Management trusted subnets.

The issue lies with the Microsoft ISA 2006 component within the Celestix WSA appliance, that is used to protect Microsoft IAG.

First of all I would create a static route on the appliance. This can be done either by using the command line and adding a persistent route, using the jog dial on the front of the Celestix WSA appliance or using the Celestix Web UI (:10000) select "Network", then "Routing" and then "Static Routes", where you can create a new static route.

Once this is done, I would start up Microsoft ISA Server on the appliance, expand "Configuration", select "Networks", go to the "Networks" tab, right click for "Properties" of the internal network, select the "Addresses" tab, click the "Add Adapter" button, and select the "LAN" tickbox.
This will apply the all the routes that the LAN card can see, including the new static route(s). Once trusted, you will be able to access resources within the defined subnets, and ISA will be able to allow the traffic defined from the site to site VPN.


- Posted using BlogPress from my iPhone

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.