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.

Clickjacking and UAG

I got an email from a customer and friend, regarding penetration test results on a Microsoft UAG environment.  The report highlighted that Clickjacking is way of tricking web user into revealing confidential information or allowing their computer to be controlled while clicking on seemingly harmless web pages.  Clickjacking can be embedded code or a script that executes without the web users knowledge.

I took this opportunity to learn a bit more about this and found a couple of interesting websites.  It seems that other UAG users have encountered this during penetration testing before, and there is a fix:  http://forums.forefrontsecurity.org/default.aspx?g=posts&m=2788

The following code needs to be added into the UAG login.asp script:

<script type="text/javascript">
if(top != self) top.location.replace(location);
</script>

Adding the code is fine, but I had to find a way of testing the Clickjacking.  I found this site, which allowed me to test the vulnerability:  https://www.codemagi.com/blog/post/196

By creating an HTML page with the following code, and replacing the red text with the URL that you want to test, it will show if the website is vulnerable to Clickjacking:

<html>
<head>
<title>Clickjack test page</title>
</head>
<body>
<p>You’ve been clickjacked!</p>
<iframe sandbox="allow-scripts allow-forms" src="http://localhost:8080" style="width:100%;height:90%"></iframe>
</body>
</html>

With a little experimentation, I found the best place within the UAG login.asp to put the additional line of code was here:

var capsLockNote = "<%=GetString(111, "Note: The Caps Lock key is on. Passwords are case-sensitive.")%>";

</script>

<script type="text/javascript">

  if(top != self) top.location.replace(location);

</script>

<script language="JavaScript" src="/InternalSite/scripts/capsLock.js"></script>

I have to stress that it may be different on your UAG deployment, so remember to test it works, rather than assume!

VMWare View on IAG & UAG - Borrowing Advice!

Good to see that my advice from this blog post is of use:
http://blog.andytang.com/2010/05/vmware-view-on-microsoft-iag.html

Spot the differences:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025861

http://www.nappliance.com/blog/uag-publishing-vmware-view-using-forefront-unified-access-gateway

I don't have issue with my advice being used, but at least show credit from where it was from!

UAG Registry Keys

Found this TechNet section when looking for something else and it may be very useful to you.

Here are the registry keys used by UAG:
http://technet.microsoft.com/en-us/library/ee809087.aspx

The one that is the most use, especially carrying out proof of concepts and "real" certificates are not being used:

HKEY_LOCAL_MACHINE\SOFTWARE\WhaleCom\e-Gap\Von\URLFilter\Comm\SSL


By default Forefront UAG validates both the certificate and the revocation list of each SSL backend server during the TLS handshake procedure. In the event where the certificate or the CRL are not valid, backend users are denied access to that given backend server. If a Forefront UAG administrator wishes to disable those validation tests, set the ValidateRwsCert and ValidateRwsCertCRL key values to 0, and then restart the IIS service on the Forefront UAG server.

As UAG checks certificates and CRL, where IAG really didn't this can be new to most people who have experienced IAG.

ActiveSync and email on iPhones (and other ActiveSync devices)

Recently I’ve been asked a lot about ActiveSync for iPhones, but I try to highlight the security implications for this.

I have spoken with a number of people who have ActiveSync running on their Exchange Servers, where they can access the server directly from the internet. I’m not a fan of having servers on the LAN available from the internet, but the pressure to deploy the access this is often overlooked. Especially as the Microsoft IAG and UAG solutions will allow you to reverse proxy the ActiveSync connection, eliminating the need for a direct connection to the Exchange server.

Ensure the handset you have has a level of encryption on it, as the company can be subject to hefty fines from the ICO, if personal data is not encrypted. Apple iPhones have AES 256-bit hardware encryption to protect the data at rest. The Nokia E-series that I have investigate have encryption on both device and storage memory.

Although as this is protecting data at rest, ensure there is at least a password on the device, or there is no point having the encryption. Enforcing password on the device, and comprehensive password policies can be created on from the Exchange server.

 

What is the handset is stolen? There is the ability to remote wipe the mobile device, as well as enforce a wipe if there are too many failed attempts to logon to the device.

 

The only concern is a number of requests for this access on personal iPhones, which is a worry from a data leakage perspective. Although a number of places have said they will ensure password policies and reserve the right to remote wipe the device when it is required, then make their employees agreeing to this. Personally, I am not a fan of this and would rather be working with corporate devices, where as a business you have more “rights” to your hardware.

 

From a technical perspective, you will need to do the following:

• Ensure ActiveSync is configured and running on the Exchange server, with the relevant password, encryption and wipe policies. Assign the access to the users who should be able to access it, taking care to remove access from everyone else (so they are unable to connect up unauthorised or personal mobile devices).
• Configure an ActiveSync portal on IAG, or create a portal for ActiveSync on UAG.
• Ensure all the Exchange server settings are entered correctly.
• Apply a real SSL certificate to the portal, as some mobile devices will not allow you to except a self signed SSL certificate.
• Publish the portal.
• Test the ActiveSync by defining the server name, domain/username and password here: https://testexchangeconnectivity.com/
• Expect it to fail on the OPTIONS section, but everything else should pass.
• Configure your device to point to the newly created portal.
• Allow device to synchronise and enjoy emails on your mobile device!

 

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

Celestix Technical Training - Microsoft UAG & TMG

Celestix will be giving training in Microsoft UAG and TMG (which will replace Microsoft IAG and ISA server) on the 3rd February.

If you are a reseller based in the UK and this is of interest, please register here