The Work from Home Dilemma

Introduction

As IT departments face growing demands for security coming from within and increasing demand for flexibility coming from end users we often find ourselves deploying laptops with VPN connectivity.  Which while functional has some considerable costs and risks associated with it.  Further exacerbated by the need of many organizations to encrypt the hard drives of any corporate laptops deployed in the field.

A cheaper solution would be to let users work from home using computing equipment they already own.  But how do you do that without creating security holes of all shapes and sizes tends to be the big question.  Citrix is one solution that certainly works for many people but it also has a significant cost and complexity making it a difficult investment for some smaller organizations.

This article will describe the steps needed to get a user securely connected to a desktop at work via a web page.  All they will need is a web browser, a Yubikey and an Active Directory username and password.  With those three items you will presenting them with a 2-factor authentication solution using a one-time password (OTP) that requires you to open only one port into your DMZ, HTTPS or 443 which connects you to Microsoft’s premier access platform for security.

This solution relies on the following products:

Microsoft Forefront Unified Access Gateway 2010

A secured firewall and access gateway which has numerous single sign on options and 2-factor authentication support.

Ericom AccessNow and Secure Gateway

An HTML 5 web server which delivers Remote Desktop services in a browser agnostic web page with no client software required.

Scorpion Soft. AuthAnvil, NordicEdge OTP or Yubico YubiRadius – any form of radius server that supports Yubikeys

A radius server that will authenticate your OTP device, which in our case is a YubiKey.

Yubico YubiKeys

Your physical OTP device.

The Dime Tour

The basic idea of the solution is using Microsoft UAG 2010 to present a secured login page which will contain a username, password and OTP password field for use with your OTP radius server of choice.  All three have advantages and disadvantages and UAG works equally well with all of them.  Once you have signed into UAG successfully your password will be passed to via UAG’s own forumlar engine to a custom login page which will create the cookies used by Ericom AccessNow for login.  Once that happens you will be passed to a Microsoft Remote Desktop server or connection broker which will be rendered directly in the users browser.   Below is a basic network diagram showing the connectivity described above and showing the ports used for each connection.

The Unified Access Gateway

The glue that holds these pieces together is Microsoft’s UAG 2010 product.  It is a firewall, can sit behind other firewalls, and can be a stand-alone system to provide domain based logins and 2-factor authentication and provides a reverse proxy for internal web sites once a user has authenticated.  UAG can be used with a myriad of Microsoft products which are all pretty well documented.

First install UAG and it’s latest security patches and service packs.  Once you launch the software you will have to configure and internal and external network.  This requires two physical network adapters as UAG is first and foremost a firewall.  Once you have configured the network you must create an HTTPS trunk and select a Portal Trunk.  You must provide a Trunk Name, external IP, HTTP and HTTPS ports, and a public host name (something like uag.fqdn.url) which should NOT be the name you plan to publish your Remote Desktop web sites as, I will cover that later but they must be different.

Then you must then configure your authentication providers which in our case will be Active Directory and a Radius server for our OTP solution.

I wanted to mention here that UAG does NOT need to be joined to the domain to do Active Directory authentication but you will have to setup the provider just right to get it working.

Below you can see screenshots of both providers.  The key to the Active Directory provider is to use the NetBIOS name for your domain at the bottom of the form.  The FQDN will not work.

RADIUS is a little easier, just setup the right hostname and port, which is usually 1812 and setup a shared secret key on your RADIUS server for use here.

When you have added both provider click the check box that tells UAG to use the same username for all providers.  This way your users will only need to specify 3 pieces of information.

         

Next you will need to select the SSL certificate you wish to use with this trunk.  This should be a publicly signed certificate with the FQDN (something like access.your.company) you wish to publish your Remote Desktop application with and the FQDN (something like uag.your.company) you used for your Portal Trunk as a Subject Alternative Name.  The reason you need two names is because UAG acts as a reverse proxy for your application server, which should have the same FQDN internally and externally but UAG relies on the Portal Trunk to provide login services.  You will also be installing this certificate during the setup of Ericom Secure Gateway.

Next are a few screens that define Access Control policies used by UAC.  You will need to configure these based on your corporate policy and Microsoft has a lot of documentation on working with this part of UAG.  For my purposes I have allowed all clients.

Now that you have your trunk you must configure an application.  You can click add under applications on your Trunk.  You will select “Other Web Application (application specific hostname)” for your new application.

Give the application the name and a type (the type is important but can be whatever you want it to be, this has to do with SSO).  This application will be used to publish your remote desktop services so use the FQDN you specified when creating your certificate.  Again this cannot be the same as your Portal Trunk’s FQDN.  Next you must select access control policies for this application and configure and application server.

Here you will specify the FQDN of your server, leave the path as “/” and select HTTPS.  The public host name should match the FQDN above otherwise you will run into problems with your SSL certificate.

At step 6 you will be able to choose to use SSO, you should add an authentication server and select the Active Directory provider you setup earlier and HTML form as the type. (We require 2-Factor to login to UAG but most web applications only support basic authentication which is the beauty of the UAG security model.)

Finally at step 7 make sure the application URL reads as:

https://access.your.company/AccessNow/Login.html

This will be important to get SSO working with Ericom.  For now we should be done with UAG though it is a complex product and you may have to make some changes to settings to get it working in your environment.

The HTML5 Remote Desktop Solution

Ericom (www.ericom.com) offers a variety of products but the two we will need to purchase and install here are the Secure Gateway and AccessNow.  Both have free trials if you wish to demo this solution before you buy it.

The easiest way to configure the Ericom server is to install AccessNow and Secure Gateway on one system, though they recommend installing AccessNow on your Remote Desktop server for better performance.

You should take all the defaults when installing AccessNow.  When installing Secure Gateway you will need to install and select the SSL certificate you also used for your UAG server.  Otherwise take the defaults.

To configure the Secure Gateway you will need to navigate to the following directory, assuming you took the default installation settings:

C:\Program Files (x86)\Ericom Software\Ericom Secure Gateway\WebServer\AccessNow

Within that folder we are going to modify the Config.js and add two html files:

Login.html and Logout.html

Config.JS

// Configuration settings for Ericom AccessNowvar defaults = {overrideSaved: true,               // These settings override   saved user settings

//     onlyHTTPS: true,                 // Don’t use WebSockets – go   straight to HTTPS

//     noHTTPS: true,                   // Don’t allow using HTTPS   instead of WebSockets (HTTPS requires Ericom Secure Gateway)

autostart: false,                   // Start session   automatically

oldStyleProtocol:   false,            // Set to true to use   version 1.0 protocol

singlePort: true,

wsport: 8080,                       // AccessNow Server   port

gwport: 443,                        // Ericom Secure   Gateway port

showAddress: false,                 // Show server address in   error dialogs

dialogTimeoutMinutes:   2,            // Dialog timeouts

sessionTimeoutMinutes:   0,           // Zero disables feature

hiddenUpdateRateSeconds:   20,

keepAliveRateSeconds: 30,

minSendInterval: 30,

disableImageReuse: false,

clipboard: true,

clipboardTimeoutSeconds:   15,

clipboardUseFlash: true,

clipboardKey: 12,                   // Key to open clipboard   paste dialog. Set to false to disable

printing: false,

fileDownload: false,

fileUpload: false,

specialKeys: true,                  // See   http://support.microsoft.com/kb/186624

chromeKeys: true,

rightToLeft: false,

noEndDialog: false,                 // Do not display end of   session dialog

//     message: “”,

leaveMessage: “Leaving   this page will disconnect Ericom AccessNow”,

//     keyboard_locale:   “00000409”,

//       convert_unicode_to_scancode: true,

endURL: “logout.html”,                      // URL to go to when   session has ended (# value closes window; ^ prefix to assign to window   instead of top)

address:   “localhost”,                       // address of AccessNow server

full_address: “Your.RDP.Server”,                // address of RDP host

//     username: “”,

//     password:   “”,                    //   plain text

domain: “YourNetBiosDomainName”,

//     remember: false,                 // password

//     encryption: false,

blaze_acceleration: true,

blaze_image_quality: 40,

//     resolution:   “1024,768”,

use_gateway: true,

     gateway_address: “Access.Your.Company:443”,   // The same FQDN used for your Remote   Desktop application in UAG

//     audiomode:0,

//     remoteapplicationmode:   false,

//     alternate_shell:   “”,             // startup   application

//     shell_working_directory:   “”,

//     console: false,

//     settingsURL:   “resources/blaze.txt”, // URL from which to download connection   settings

//     hidden:   “remember”,                   // Advanced button is showAdvanced

//     restrictHost:   “127.*,localhost”,

_last: 0

};

Login.HTML (This file is our login form which is essential for SSO as it sets some important cookies and the default Start.HTML provided by Ericom does not play nicely with UAG.)

<html><head><body onload=”javascript:createCookie()”>

<script>

function createCookie()

{

var username =   document.forms[‘cookieform’].username.value;

var password =   document.forms[‘cookieform’].password.value;

var tomorrow =   new Date();

tomorrow.setTime(tomorrow.getTime()   + (1000*3600*24));

document.cookie   = “EAN_autostart=true; expires=”+tomorrow+”; path=/”;

document.cookie   = “EAN_username=”+username+”; expires=”+tomorrow+”;   path=/”;

document.cookie   = “EAN_password=”+password+”; expires=”+tomorrow+”;   path=/”;

if   (navigator.appName == “Microsoft Internet Explorer”)

{

window.location   = “/accessnow/start.html”;

}

else

{

window.location =   “/accessnow/start.html”;

}

}

</script>

</head>

<body>

<form name=”cookieform” action=”#”><p>

<input name=”username” input   type=”hidden”><br/>

<input name=”password” input   type=”hidden”><br/>

</form>

</body>

There is a little redundancy in the script on the login page but some people may want to do browser checks.  Only IE9 and up, Firefox, Google Chrome and Safari will work with Ericom due to HTML 5 support.  This page serves as a place holder for the login and password info which it then uses javascript to store this information in the cookies that Ericom’s login page normally creates.  This page is self-submitting so there is no need to have UAG run any JavaScript but we do need to setup one last thing which I will cover later to get UAG to fill out these fields and make the SSO work correctly.

Logout.HTML

<html><head><body>

Please close this window to completely logout.

</body>

</html>

The logout.html is just there to give the users and ending point once they logoff there remote desktop session.  Otherwise they will end up back at the Ericom Start.html which will allow them to connect to systems other than what you’ve configured.  Theoretically they should never need to see that page.

Back to UAG to complete to SSO configuration and come full circle

Now that we have Ericom ready for connection, you should test this before trying to reach it via UAG.  If the page comes up and you have configured UAG correctly everything should work smoothly.  The last steps is to configure the Formular engine within UAG.  This is a daunting challenge for most, but luckily I have done all the work for you and provided you with the exact login form to use.

You will need to go to the following directory:

%UAG Installation dir%\von\Conf\WebSites\YourTrunkName\conf

Create a file called “custom_submit.js” which should contain a blank function like exactly like this:

“Function FormLoginSubmit(){}”

(We are setting this up to override the default UAG JavaScript.)

Next you will need to go to this directory:

%UAG Installation dir%\von\Conf\WizardDefaults\FormLogin\CustomUpdate

Here you will create a file called FormLogin.xml with the following contents:

<WHLFILTFORMLOGIN ver=”1.0″><APPLICATION><APPLICATION_TYPE>YourCustomUAGApplicationType </APPLICATION_TYPE>

<USAGE description=”form_login”>

<PRIMARY_HOST_URL>.*/accessnow/login\.html</PRIMARY_HOST_URL>

<SCRIPT_NAME   source=”file”>custom_submit.js</SCRIPT_NAME>

<USER_AGENT>

<AGENT_TYPE   search=”group”>all_supported</AGENT_TYPE>

<POLICY>multiplatform</POLICY>

<SCRIPT_NAME   source=”data_definition”>FormLoginHandler</SCRIPT_NAME>

</USER_AGENT>

<LOGIN_FORM>

<NAME></NAME>

<METHOD>POST</METHOD>

<CONTROL handling=”real_value”>

<TYPE>USER_NAME</TYPE>

<NAME>username</NAME>

<DEF_VALUE>siteuser</DEF_VALUE>

</CONTROL>

<CONTROL handling=”real_value”>

<TYPE>PASSWORD</TYPE>

<NAME>password</NAME>

<DEF_VALUE>sitepass</DEF_VALUE>

</CONTROL>

</LOGIN_FORM>

</USAGE>

</APPLICATION>

</WHLFILTFORMLOGIN>

The only thing you have to change in this file is the application name at the top.  This MUST match the application name we setup earlier in UAG for your Remote Desktop application.  If the name’s don’t match exactly, SSO will not occur and you will be left sitting at a blank page or form.

Once you have added both files you must Activate your UAG settings, something that must be done any time you change UAG in any way.

The Finale!

Assuming you have done everything just right you should be able to login to the external site on your UAG server using the Remote Desktop applications public host name (You will need this to match the UAG servers public IP on your client but UAG server should resolve the DNS for this host name as belonging to the IP address on the internal Ericom server, that way you tunnel through UAG and end up on the Ericom server all using one hostname and SSL certificate.  Doing this any other way will probably not work.)

You will login with your domain credentials and your Yubikey and end up right on a Remote Desktop presented in HTML5 directly in the browser.

Not only will your users love the functionality but because of the nature of the Yubikey’s OTP and very simple network and firewall requirements this is a very secure solution and in many ways is more secure than laptops which can be stolen.

This is obviously a fairly complicated architecture relying on many moving parts but as you deploy it you will find it has a simple elegance and you can generally figure out where you have made mistakes along the way pretty easily.  I hope this post is helpful and I will try to write up more promising enterprise class solutions for Small to Midsize budgets for your IT needs.