SGD Enhancement Module on Windows 2003 64 bit

This week I got a question from one of our customers: Is the the SGD Enhancement Module (formerly know as Tarantella Enhancement Module/TEM) supported on Windows 2003 64 bit?

The answer would be simple when looking at the "SGD Enhancement Module Requirements" on
http://docs.sun.com/source/820-2548/chapter1.html#d0e1434
but there was only a statement which said:

Supported Version - Windows 2003

But no reference to it being the 32 bit or the 64 bit version.

A quick question to Sun gave the following response:

We explicitly call out the systems where we support just 32 bit.
Here only the Linux OS's are 32-bit versions. All the other
OS's are both 32-bit and 64-bit versions. It's a implied.


This means the SGD Enhancement Module is supported for Windows 2003 64 bit (as well as the 32 bit version).

New java version resolves Active Directory bug for SSGD

There was a small bug regarding password changes during the authentication process when Sun Secure Global Desktop (SSGD) is using the Active Directory authentication. This bug was a bug in the underlaying Java of SSGD. A new version of Java is available since this week with a fix for this bug.

Information and instructions to upgrade the Java version for SSGD see the blog post on Mr PotatoHeads blog:
Potato Peelings

Secure Internet Access

When looking at almost all information about Sun Secure Global Desktop (SSGD) it seems that SSGD is only used for access to applications from the Internet which are normally only accessible via the intranet (from within the office). But SSGD can do more ...

The common way to use SSGD is to access applications running on different types of application servers (Windows 2000/2003, *nix, mainframe and more) from the Internet (any device, any time, any place).

SSGD is designed to perform the task of bringing office applications in a secure way to the Internet, but SSGD can also bring Internet to the office :)

Sometimes you might come across a company where access to the Internet is not allowed because of multiple reasons, the most common are:

• Viruses can be installed on the workstation
• Key-loggers can be installed on the workstation
• Security leaks in applications (think of a leak in MSN)
• Installation of insecure applications (for instance: ActiveX components)

There are ways to find solutions for these security issues like installing a proxy, a content/spam/virus filter/scanner, a application firewall (ISO/OSI up to level 7 ) , a messaging gateway. But there is one simple thing which is hard to handle. An employee can simply copy/paste information from a company application to a messenger (MSN/ICQ) or attach documents to a message via an external webmail application.

For all the above issues SSGD can be the solution!


The users can access a browser with access to the internet via SSDG on some sort of 'browser'-host. This 'browser'-host can be a stripped down OS (Windows 2003 or *nix) with only a browser and a couple of readers/plugins (Office readers, PDF viewer, quicktime player, shockwave player, etc). Without Client Drive Mapping and copy/paste to the 'browser'-host turned off, there is no direct way to leak information to the internet.

In this scenario is it impossible for an hacker to get access to the employees workstation. Think for instance about a key-logger. When a key-logger is accidentally downloaded form the internet it can only be installed on the 'browser'-host. The key-logger can 'read' passwords for the web-applications accessed via the 'browser'-host, but it can not 'read' any password on the employees workstation. So no password can be logged for all company applications.

Virtualization can be used to enhance the security of the 'browser'-host. When using for instance VMWare ESX 'reinstalling' the 'browser'-host can be done within minutes, just clone a new virtual machine from a template. This 're-installation' can be done every night or even dynamical when using tools like the VDA-Kit.

Think creative and see the many senario's where SSGD can be a solution and solve issues :)

Configure Windows Application in SSGD

Before configuring a Windows Application make sure the application is running on the Windows Application Server (Windows Terminal Server).

1. First connect to the Windows Terminal Server directly via RDP with an RDP Client.
2. Start a command prompt (Start->Run->cmd.exe)
3. cd to the directory from where the application must be started (Startup Directory)
4. start the program (Application Command Line)

If the application starts you are ready to configure the application in SSGD. First prepare the parameters used in SSGD:

• Split the Application Command Line in "Application Command" and "Arguments for Command"

• The Application Command is the first part of the Application Command Line until the extention exe, bat, com, vbs (and alike)
• The remainder of the Application Command Line are the Arguments for the Command
• Replace in both the \ with a double \\, So c:\Program Files\Internet Explorer\iexplore.exe will be c:\\Program Files\\Internet Explorer\\iexplore.exe
  

• The protocol arguments are: -dir "Startup Directory" (with the \ replaced by \\)
  For example: -dir "c:\\Program Files\\Internet Explorer\\"

Configure the application in SSGD. This can be done in several ways. In this example I will use the command line:

tarantella object new_windowsapp \
--name ".../_ens/o=organization/cn=WindowsApplication" \
--width 1000 --height 800 \
--app Application Command \
--args Arguments for Command \
--protoargs "-dir Startup Directory" \
--appserv ".../_ens/o=organization/cn=ApplicationServerName"