HOWTO Setup SGD as a SOHO Remote Access Server

Note: This is a relatively simple guide to setting up SGD for remote access to a Small Office / Home Office (SOHO) environment, and may be useful for illustrating some basic concepts. Most suitable for the "new" administrator.

Setting up SGD as a SOHO Remote Access Server

Purpose

This document provides a step-by-step walk-through of how I set up my home network and Secure Global Desktop (SGD) to allow me to access my home network and computers while I'm traveling. This walk-through is to illustrate some of the common setup tasks you may need to perform for setting up remote access for small / home office. Any of the steps, policies, or procedures I used may not be appropriate to your environment - common sense should always prevail.

Introduction

Sun's Secure Global Desktop (SGD) allows remote users to access and run applications remotely using only a Java-enabled web-browser. That is, SGD lets me access the computers in my home network and run applications on them, including X11 and Windows applications. I can run these applications from almost anywhere, over almost any type of connection, and
securely. When I'm away from home and need to be able to access applications and data on my computers at home, SGD allows me to do so.

Of course, there are other utilities that provide varying degrees of remote access capabilities, but SGD provides advantages over many such utilities, such as:

• Firewall Traversal - This features tunnels all network traffic (https + SGD's
  AIP protocol) over a single port, TCP port 443. This means not only do I not have to open any ports on my home router, but more importantly, I don't have to open ports on any intervening firewalls (because, for the most part, I can't). If I'm at work or at a client's site, it's virtually certain that the SSH port, for example, is closed, while the 443 port is generally open --because it's usually considered a safe and well-known protocol. In addition, SGD can negotiate client-side proxy servers, while most other utilities cannot.

• Performance - The Adaptive Internet Protocol (AIP) is a proprietary protocol optimized to run graphical applications over low-speed network links. AIP automatically determines network conditions such as bandwidth and latency, and tunes itself accordingly for best performance. I can access and run remote graphics applications even on a dial-up facility.

• TLS/SSL Security - connections to my home machines are encrypted via TLS/SSL to prevent sniffing of my private data and passwords.

• No Fat Client installation - all I need is a Java-enabled web browser. This means I can use almost any client (PC, Linux, Solaris, or Mac) to access my remote network.

• File transfer / Printing - SGD allows me to retrieve remote files and print remote documents on local printers.

• Multiple Authentication Providers - SGD allows you to use your existing authentication provider(s). By default, UNIX/Linux passwd is used, but LDAP, Active Directory, NT Domain, RSA SecurID and others can be used to act as SGD authenticators, giving you greater control and flexibility.

• Single Sign-on - SGD can be used as a centralized Single Sign-on (SSO) system, so you need not keep track of your different user-id's and passwords across your various systems.

• Web API - SGD uses SOAP/XML calls to interact with the server and uses Java Server Pages (JSP's) to provide the user interface. This gives me a platform for learning to code JSP's.

If you'd like to get a feel for what Secure Global Desktop does, log in to the public demonstration site here:

https://sgddemo.sun.com.

Click "Log in"

And at the login box, click the "Log In" button. On the left side of the resultant page, called the webtop, is a list of demo applications you can interact with.

My Environment

To give a bit of background, my home is serviced by a 768K/128K ADSL line and I use a Linksys WRT54G wireless router as a NAT device to allow my computers to share the ADSL connection. The router is assigned an IP address via DHCP by my service provider, so my WAN IP address changes periodically.

I have several computers in my home network running a variety of operating systems, including Ubuntu, Solaris 10, OpenSolaris, Windows XP and Windows Server 2003. Some of these are hosted by a server running VMware's ESX Server, which, among other things, hosts Windows XP instances that are part of my Virtual Desktop Infrastructure (VDI) environment, which is described here http://www.sun.com/datacenter/consolidation/virtualization/desktop/. These (physical) computers are connected via both wired and wireless connection. I run a local DNS server for local name services / Active Directory, and most of my computers are wired to my local hub. I use the built-in DHCP service on my router to assign
IP addresses to wireless clients.

Because my router is assigned a dynamic IP address, accessing my home network via IP address won't work. I'd have no way, when away from home, to know the IP address of my router if it changed since the last time I made note of it. In addition, since I'll be using SSL, a variable IP address requires I use a fixed DNS name to access my network. The solution is to use Dynamic DNS, which correlates a fixed DNS name with the IP address your provider assigns to your router, even though it may periodically change. My Linksys router has a built-in client which automatically keeps this information updated. By using Dynamic DNS, I can access my home network with a consistent DNS name without having to keep up with IP address changes.

To install SGD, I needed to choose one of my servers to run the SGD software and act as the gateway into my network; I had both Linux and Solaris platforms to choose from, and I chose Solaris. SGD runs on this machine and proxies my incoming connection to applications running on my other systems. This means all of my internal systems must be reachable by this host. The system I chose for this 'gateway' function in my network is actually a Solaris Virtual Machine housed within my Sun W2100z server.

In this example, I have a small internal network (mydomain.com) with name resolution services setup for resolving local addresses.

An important note regarding hostnames

The internal hostname of your SGD gateway server is called the Peer DNS Name - this is the internal hostname other servers in your network will know you by. In my example, this name is "myhost.mydomain.com". The DNS name your SGD gateway host is known by from outside your network is your External DNS Name, and in the example is "myname.homelinux.net". Substitute your own hostnames for these in the following examples.

Getting Started

Before you begin, you should read the installation documentation for SGD.  These documents include the Installation Guidehttp://docs.sun.com/app/docs/doc/820-2549, the  Administration Guide, and Release Notes

Step-by-Step Procedure

Obtain a DNS Address for Your Network
    As mentioned above, I wanted to assign a permanent DNS name that I could use to access my network. Since my router supports DynDNS, I elected to use their service and went through the following steps. The Linksys router also supports the TZO service, http://www.tzo.com, and would be setup similarly.

From my home network I went to http://ww.dyndns.org/services/dyndns to register a hostname that I could associate with my home network. I first created an account for myself and then went through the ''Add Host'' procedure.

This creates a hostname like "myname.homelinux.net" (DynDNS has 43 domains under which you can register your hostname, including the homelinux.net domain used in the example). This page detects your currently-assigned IP address. Confirm the address shown is correct and add the hostname you've chosen.

Configure Router to Update DDNS Service
    The way Dynamic DNS works is that when the WAN IP address of my router changes, the Dynamic DNS service provider is notified of the change. The Linksys^{<small>†</small>} router has a built-in DDNS client to perform this notification. Alternatively, if your router doesn't support this function, you can obtain a DDNS software client to install on a machine on your network to perform these updates. See: http://www.dyndns.org/services/dyndns/clients.html

Note - Older versions of the Linksys firmware may be "embargoed" by DynDNS, due to a misbehavior in the client code - you may need to update the firmware on your router for DynDNS to accept updates from your router''

Log in to your Linksys router as admin and set DDNS client information.

Configure Router to Port Forward https Traffic

Disable / Remove Apache Server on Server Box
If you have a web server installed on your SGD server system, turn off or remove it. SGD includes a pre-configured Apache web server and Tomcat server, which is required for proper operation.

Create "Service" Accounts
Before installing SGD, you need to create two user-id's and one group-id, to which both id's belong. The names of these accounts are fixed:

"ttaserv", with a group name of "ttaserv", owns the webserver files
"ttasys", with a group name of "ttaserv", is the (unprivileged) id that the SGD server will run as.

The (numeric) login-id and group-id are not important, only the names are. For example:

# groupadd ttaserv

# useradd -m -g ttaserv -d /home/ttasys  ttasys

# useradd -m -g ttaserv -d /home/ttaserv ttaserv

The '-m' option creates home directories for the users, which is required. 

Install SGD Software

The following command will install SGD onto your system.

#  pkgadd -d tta-4.40-917.sol-x86.pkg

 
When you start SGD for the first time, it will run the SGD installation program to configure your installation. To start SGD, run the following command:

# /opt/tarantella/bin/tarantella start

The most important setting here is the Peer DNS name. This should be the fully-qualified domain name of your server and should be resolvable in the ''local'' network. Check to be sure this is correct.

Also, if using a Linux server, it would be a good time to mention that some Linux distributions will assign the hostname (''myhost.mydomain.com'') as an alias to the loopback address (127.0.0.1). This will cause problems and should be corrected before you begin.

Once you've accepted the installation settings the installation process will run to completion.

Enable SSL

Enabling SSL connections will encrypt the traffic between your roaming location and your home network and is mandatory for SGD Firewall Traversal to function. Recall that SGD uses two connections between a client browser and an SGD server - the http connection and the AIP connection. To SSL-encrypt these two protocols, two (logical) X.509 certificates are required - one for the web server (https) and one for SGD (AIP). In practice, these certificates are usually shared between the web server and the SGD Security Pack, and Apache is pre-configured to do just that.  .

Server certificates are generally purchased from a Certificate Authority (CA) such as Verisign or Thawte. However, for most casual home and/or test installations, this is probably unduly expensive. It's possible to use self-signed X.509 server certificates to enable https connections. Such certificates are typically not considered truly secure as they are not issued by a trusted CA, but many consider them to be fine for this type of project. I'll leave this for you to decide. The following section describes two ways to use self-signed server certificates in Tarantella.

The first step in obtaining an X.509 certificate is to create a "Certificate Signing Request" (CSR). This creates an unsigned X.509 server certificate, and includes information about your server, organization name, etc, as well as a generated public key, and, separately, a private key, which corresponds to the public key. This unsigned certificate is then sent to a CA to be "signed" with their signing key. Run the following command to generate a CSR, substituting your information (between the '<>") as appropriate (note that the "tarantella" command can be found in /opt/tarantella/bin - you may wish to add this directory to your path):

# tarantella security certrequest --country <country> --state <state> --orgname <orgname>

This command displays some output, then displays:The hostname to be used in the certificate request is myhost.mydomain.com.
Do you want to use this hostname? [yes] no
Enter the fully qualified hostname [ myhost.mydomain.com] myname.homelinux.net

(If you're using version 4.40, you will be asked for an additional hostname, as follows.  This feature allows you to specify multiple hostnames for a host in the SSL server certificate. )

Do you want to add any additional hostnames? [no] yes

Type in the subject alternative names for the certificate, one per line. Enter a blank line to finish.

-n subjectAltName:

myname.mydomain.com

-n subjectAltName:

<Return>
[ a number of informational lines will be shown, then ]
Create CSR Now? yes

The generated Certificate Signing Request is displayed between the two lines marked:

----CUT HERE----

If you wish to have this signed by a CA, take this CSR and send it to the CA in whatever manner they specify. If you wish to use self-signed certificates, you can use the SGD built-in command to generate a self-signed certificate. Notice that this is an unsupported and undocumented feature, its use is at your own risk. To create and install a self-signed certificate, enter the following command:

# tarantella security selfsign

which results in the output:

Now that the certificate is installed, start SSL connections with the following command:

# tarantella security start

to which the system responds:

Enable SGD Firewall Forwarding
In the following section we're going to make several changes to the Apache and SGD configuration to support the Firewall Traversal feature. These steps include:

*Modify the Apache ''ServerName'' associated with the 127.0.0.1 Virtual Host to match your external DNS name.

*Modify SGD so that it communicates its secure AIP connections on port 443.

*Modify SGD so that it knows to setup an SSL listener on port 443. This listener process, "ttassld", binds to the network interface on port 443, receiving all https packets from the network. If inbound packets are destined for the web server, the packets will be forwarded to the 127.0.0.1:443 interface (where Apache is bound) and if the packets are destined for SGD they will be handled by SGD.

*Modify the SGD External DNS name to the resolvable (DDNS-assigned) DNS name. When clients connect to an SGD server, the client software (via the browser) is instructed to connect to the SGD External DNS name, (this can be different from what the client has typed into their web browser.) By default, the hostname that the client connects to is the "Peer DNS Name" as defined above. However, for external clients, the "Peer DNS Name" is unresolvable, so we want to alter the name returned to the client to the resolvable name.

Edit the Apache Configuration File

Locate the Apache configuration file, located in this (4.40) release in:

/opt/tarantella/webserver/apache/1.3.36_mod_ssl-2.8.27_openssl-0.9.8d_jk1.2.15_u1/conf/httpd.conf

and make the following changes (note that this directory name may vary by version):

Change Apache Listen Port

Locate the line that reads:

    Listen 443

 and change this to read:

    Listen 127.0.0.1:443

Change Apache Virtual Host Bind-To Interface

Locate the line that reads:

    <VirtualHost default:443>

and change this to read:

<VirtualHost 127.0.0.1:443>

Change Apache Virtual Host Name

Several lines below, in this same "VirtualHost" section, locate the line:

    ServerName myhost.mydomain.com

and change to read:

    ServerName myname.homelinux.net

Save changes and exit.

Change SGD Settings

In this section, you're going to change the AIP Secure Port to 443, and set the Firewall Forwarding URL.  This signals SGD to setup an SSL proxy on port 443, and where to forward packets which are destined for the webserver, that is, non-AIP packets.  For brevity, I'll use the command-line, but you can use the administration tool to make these changes, if you prefer.

# tarantella config edit --array-port-encrypted 443
# tarantella config edit --security-firewallurl https://127.0.0.1:443
# tarantella config edit --server-dns-external "*:myname.homelinux.net"

Restart Services

Now, restart SGD and the webserver:

# tarantella webserver restart --ssl


# tarantella restart

Test Your Installation

From a supported web browser, type the following URL:

https://myname.homelinux.net

If everything is configured correctly, you should see an SGD landing page with various options displayed, (e.g. "Log In", etc.) If you do not see this page check to ensure your DNS resolver is returning the proper IP address for your network name. If it is, check to ensure that you've established port forwarding properly on your router so that TCP packets on port 443 are forwarded to the proper IP address.

From the landing page, click "Log In".
Log in as "administrator", using the root password for that system - note that the "Administrator" account is an alias for "root" provided by a "Person Object" in the SGD data store.

If all was successful, you should see a list of default applications listed in the left-hand pane of this page. Click on any application to launch.

Windows Application Notes

SGD is designed to support Windows applications, most commonly through the use of the Terminal Services component of Windows 2000 Advanced Server or Windows Server 2003 (though other mechanisms exist). This service provides the RDP network protocol so that remote users can connect to such a server and run remote Windows sessions.

To enable the built-in RDP service in Windows, do the following:

Windows 2000 Server

Install Terminal Services in Remote Administration mode, by running:

Control Panel > Add/Remove Programs, "Windows Components", select "Terminal Services", and check to ensure that "Remote Administration Mode" is selected.

Windows XP

Enable Remote Assistance Connections, by running:

Control Panel > System, then selecting the "Remote" tab, and ensuring that "Allow users to connect remotely to this computer" is selected.

Windows Server 2003

Enable Remote Assistance Connections, by running:

Control Panel > System, then selecting the "Remote" tab, and ensuring that "Allow users to connect remotely to this computer" is selected.

Other Windows Versions

For accessing computers that are running a version of Windows that doesn't support RDP, one simple solution is installing a VNC server on the computer running Windows, and a VNC client on your SGD server, then run the VNC Client as an application under SGD. There's a significant loss of functionality, with no printer or drive mapping, and performance is, well, "limited". But it works.

Create an X-Windows application that launches the VNC client. For example:
Application name: VNC Snoopy
:Application Pathname: /usr/local/bin/tightvnc
:Command Line Parameters: snoopy.mydomain.com
:Display Using: Client Window Management

A better alternative might be to look at VirtualBox - VirtualBox is a virtualization tool that includes a built-in RDP Server, which allows you to connect to versions of Windows that don't include an RDP server, such as Windows 2000 Professional.  

More on this later ...