... {toc}
h3. What is Secure Global Desktop?
A. Secure Global Desktop (SGD) is a software solution that allows remote users to securely access and run centralized legacy applications, using the web browser on their supported client computer. Applications types supported include Microsoft Windows (via RDP), Unix/Linux X-Windows, character terminal (e.g. "VT420"), tn3270, and tn5250.
Most commonly, SGD is viewed as a having a "Three-tier Architecture", with "client" computers representing tier 1, the SGD server(s) being tier 2, and Application Servers tier 3. Clients (tier 1) connect to the SGD server(s) (tier 2), which in turn launches proxied connections to tier 3. This can be depicted as:
!firewall.gif!
Clients connect to the SGD server using AIP, and the SGD server proxies / connects to the Application Server Tier using native protocols appropriate to the application type (e.g. RDP for RDP/Windows applications, ssh/X11 for X-Windows applications, etc.) Users never connect directly to the application server tier. This allows the application servers to be isolated from internet access, except through the SGD server.
h3. What is the latest available version?
Version 4.50.907 was released in May 2009. The version history of SGD can be found [here|http://wikis.sun.com/display/SecureGlobalDesktop/Release+Information]
h3. Where can I find documentation?
The 4.5 documentation collection can be found [here|http://docs.sun.com/app/docs/coll/1706.4?l=en].
h3. Where can I find the software?
SGD 4.5 can be downloaded [here|https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=SGD-4.5-M-G-F@CDS-CDS_SMI]. For access to previous versions, see: "[Release Information|http://wikis.sun.com/display/SecureGlobalDesktop/Release+Information]."
h3. What Operating Systems does SGD run on?
For version 4.5, the list of supported server operating systems can be found [here|http://docs.sun.com/source/820-6688/chapter1.html#d0e758].
h3. What Application types are supported?
For version 4.5, the supported application types (and associated protocols) can be found [here.|http://docs.sun.com/source/820-6689/chapter4.html#d0e15701]
Note that this does not specify "Application Server Operating Systems." This is because SGD uses standard protocols to connect to the application servers, and the application server operating system isn't something that SGD is overly dependent on, provided that the hosting application server behaves in a predictable way. So, for example, it probably doesn't matter if the X-Windows application you're publishing is hosted on Solaris 8, or some Linux distribution, or OpenSolaris. But it will matter if the hosting operating system isn't a Unix work-alike, like OpenVMS. There are usually ways to deal with such differences.
Where Application Server Operating systems are relevant are when installing an [Enhancement Module|http://docs.sun.com/source/820-6688/chapter1.html#d0e1521]; Enhancement modules install on application servers to provide additional functionality, and are completely optional. They provide:
- Advanced load balancing
- Client drive mapping
- Seamless windows (Windows platforms only)
- Audio (UNIX or Linux platforms only)
Note that X-Windows applications which require some extension not supported by SGD may not always work; for a list of X-Windows extensions supported by SGD, see "[Supported X Extensions.|http://docs.sun.com/source/820-6689/chapter4.html#d0e18285]"
h3. Where can I find the Enhancement Modules?
The simplest way is to browse to the SGD server "landing page" from the application server console, and locate the link "Install a Sun Secure Global Desktop Enhancement Module." Clicking on this link will take you to a download page, where you can download and install the appropriate module.
h3. What Clients are supported?
For version 4.5, the supported clients are [here.|http://docs.sun.com/source/820-6689/chapter6.html#d0e30595]
h3. I have an client / server operating system / application server operating system not on your list - will this work?
It depends on the nature of the differences in your operating system / configuration. They will often work if they're substantially similar to a supported platform. This list of platforms are simply those that have been through our Quality Assurance testing process, and minor differences between versions or distributions are usually not a problem. The exception to this are the audio-redirection drivers for Unix/Linux servers. However, that said, Sun support cannot guarantee an unsupported platform will operate properly. If you have contracted Support, Sun Support will only offer assistance on a "best-effort" basis. If you have questions or concerns, please contact your Sun sales or support representative.
h3. How do I get support?
If you're entitled to SGD Support of any kind (a license purchase includes 1 year Basic Support), you should use it. If you do not have contracted support, you may be able to get your questions answered elsewhere - see ["Support Resources"|http://wikis.sun.com/display/SecureGlobalDesktop/Support+Resources].
h3. What training is available for SGD?
Instructor-led Administrator training is available in many parts of the world. The course description and schedule may be found [here|http://www.sun.com/training/catalog/courses/SGD-2495.xml].
h3. What is the relationship of SGD to Tarantella?
Sun Microsystems purchased Tarantella, Inc, on July 13, 2005. You can read a brief history of that company [here|http://en.wikipedia.org/wiki/Tarantella,_Inc.].
h3. How is Secure Global Desktop Licensed?
Secure Global Desktop is licensed on a per-concurrent user basis, by feature used, on an array-wide basis. The "features" are based on the type of application being accessed; in terms of purchasing licenses, they are:
* Unix/Linux X11/ANSI terminal/5250/3270
* Windows / RDP
* Both Unix / Linux and Windows
Each user who accesses these hosted applications will consume one (and only one) of these licenses, irrespective of the number of instances of the particular application type they may launch. That is, launching 5 different Windows applications will consume one Windows license.
Upon logging off, a user releases the licenses they hold, unless one or more applications are "suspended". A suspended application is maintained active, even though the user may have disconnected. Because of this, the license associated with the user is retained, that is, is not released, until the suspended application terminates.
Licenses are shared (pooled) across an array of SGD servers. However, licenses cannot be used more than once; that is, they cannot be installed on more than one array at a time.
h3. What is AIP?
AIP stands for the Adaptive Internet Protocol, and is covered by patent number 6362836, and is described [here|http://www.google.com/patents?id=a1MJAAAAEBAJ&dq=adaptive+internet+protocol]. AIP is the protocol used between the SGD server and an SGD client to deliver an application over a network connection, and is designed to provide optimal application behavior and responsiveness when delivered by SGD. AIP is an adaptive protocol, (meaning that it adapts to changing network conditions), and measures network bandwidth, network latency, client performance, and application behavior to determine the best strategy for optimizing perceived performance at the client computer.
h3. How much bandwidth does AIP require?
This is a difficult question to answer, as there are a great many variables that impact network bandwidth. These include screen size, color depth, application behavior, display complexity, frequency of screen refreshes, and the like. Graphical applications tend to have a high initial requirement, as the initial screen is displayed, after which, the bandwidth demands are far smaller. User think-time and idle time are often used in bandwidth calculations to artificially reduce bandwidth "averages." Therefore, protocols which state the bandwidth required as "average over time" must be viewed with some skepticism, because while 20Kb _on average_ might be technically accurate, a user which connects over a 20Kb unshared connection is unlikely to have acceptable performance, yet 10 users on a 200Kb shared network connection may experience adequate performance. The best way to determine the requirements for a particular installation is to simulate the network environment, and measure the actual application behavior under constrained conditions.
A common error in benchmarking AIP is to use an unconstrained network connection. As was mentioned, AIP measures the available network bandwidth available, and adjusts its behaviors accordingly. If you test on a 100Mbps network connection, AIP will detect that, and will invoke relatively few optimizations. If you measure the bandwidth consumed under such conditions, you may conclude that AIP requires a very large amount of bandwidth. However, if the client connection were constrained to, for example, 48Kbps, AIP will adjust its optimization techniques accordingly, to "fit" within the available bandwidth, and to deliver the best interactive response.
Also be aware that AIP, (with certain exceptions), will send a rather large amount of packets at the beginning of a session to profile the available bandwidth and network latency, so be sure to allow any testing to run long enough for AIP to "train" to the detected bandwidth.
All that said, a 56Kbps unshared network connection is usually considered minimally adequate for accessing a "typical" graphical application.
h3. Can I constrain how much bandwidth AIP consumes?
Yes, bandwidth limits can be applied to users, or groups of users. This is not generally necessary, but when users are using applications which can demand high amounts of bandwidth, such as streaming video / animations, this may well be appropriate. See ["X Application Uses Too Much Bandwidth"|http://docs.sun.com/source/820-6689/chapter4.html#d0e22856] and ["SGD Uses Too Much Network Bandwidth"|http://docs.sun.com/source/820-6689/chapter7.html#d0e43134].
h3. How is SGD different from a VPN?
In general terms, a VPN, (or "Virtual Private Network"), creates a "virtual" communications circuit as a component of a larger network. As this relates to how SGD is used, the common use of a VPN is to create a tunnel between a client computer to a private network, using the Internet as the carrier of this tunnel. What this is commonly used for is to allow a computer (user) to access the private network facilities of their company from a remote location, using the Internet as the physical transport of this tunnel. This allows them to access computers and services held within the private network, which are not otherwise exposed to the public Internet.
This typically requires some form of VPN client software on the client computer, and a VPN concentrator at the border of the private network. Typically this provides some form of authentication and encryption (IPSec, commonly), so that eavesdroppers cannot intercept or alter the data as it traverses those public links.
The key point is that the VPN tunnel provides network "presence" of the remote computer. This allows applications present on the remote computer to access computers and services on the private network as though the client computer were on the same network as these internal hosts, because, in effect, they are. These applications may include web browsers, accessing internal web servers, and e-mail clients, accessing internal mail servers. Using the appropriate emulation software installed on the private computer, the client can also access other application types, such as Windows (via the RDP protocol) and X-Windows (using X11) running on computers in the private network.
One way in which SGD is different is that it doesn't provide network presence to the remote computer; the client connects to the SGD server, which itself is local to the private network. The SGD server then proxies the client connection to the appropriate application server. The client computer never needs direct access to the internal network. In the case of a VPN, the user can browse the internal networks, and can communicate directly with any computer they desire. One risk this introduces is the potential for malware, such as a Trojan or worm, infecting the client computer. Such a malicious program, installed on the users computer, can connect directly to these internal systems, and perhaps infect them or steal data. This is why some VPN solutions have techniques such as "Endpoint validation" to ensure that connected clients have appropriate virus scanners, firewalls, and/or patch levels installed. As SGD doesn't provide client network access, such techniques are unnecessary to protect internal systems.
h3. What Network Ports does SGD use / require to be "open"?
The network ports used by SGD are described in the following documentation links:
* [Connections between SGD Client and SGD Server(s)|http://docs.sun.com/source/820-6689/chapter1.html#d0e1858]
* [Connections between SGD Server(s) (array connections)|http://docs.sun.com/source/820-6689/chapter1.html#d0e2048]
* [Connections between SGD Server(s) and Application Server(s)|http://docs.sun.com/source/820-6689/chapter1.html#d0e2170]
* [Connections between SGD Server(s) and "Other" Services|http://docs.sun.com/source/820-6689/chapter1.html#d0e2504]
Note that, technically, there are two ports used by the SGD client - one port for http and one for AIP. In most cases, "Firewall Traversal" is used to provide a single port connection between the SGD Client and SGD Server. New in SGD version 4.5 is the Secure Gateway, which provides an alternative single-port mechanism to "Firewall Traversal. See "[Sun Secure Global Desktop 4.5 Gateway Administration Guide|http://docs.sun.com/source/820-6691/index.html]" for more details.
h3. What is Firewall Traversal and how do I enable it?
As mentioned, the connection between the SGD client and SGD server requires two separate ports, one for http and one for AIP. The ports are as follows:
|| Source || Destination \\ || Port \\ || Description \\ ||
| Client | SGD Server\\ | 80/tcp \\ | Standard, unencrypted HTTP requests and responses.Used to display webtops and for web services. |
| Client | SGD Server \\ | 443/tcp | Secure, encrypted HTTPS requests and responses.\\
Used to display webtops and for web services \\ |
| Client | SGD Server\\ | 3144/tcp | Standard, unencrypted AIP connections.Used for control and application display updates. |
| Client | SGD Server\\ | 5307/tcp | SSL-based secure, encrypted AIP connections.Used for control and application display updates. |
Client web browsers connect over either port 80, or port 443, while the SGD Client Component connects over 3144 or 5307, depending on whether encryption is enabled or not on the respective protocols.
Note that even when using unencrypted AIP connections for a client, the first connection is always secure (that is, on 5307, unless firewall traversal is enabled.
When the connection between the client and the SGD server is on a wide area network, or other network connections that may include firewalls, the ports required by AIP (either 3144 or 5307) are usually blocked. While it's sometimes possible to change firewall configurations to allow these connections, there's a better way.
Most firewall configuration allows port 443 connections to take place, if they're properly encrypted. SGD Firewall Forwarding places both protocols on port 443, with the SGD SSL Proxy acting as the end-point for communications. The SSL Proxy examines the packet headedrs to determine their true destination - the webserver or SGD, and sends the packets to the appropriate destination.
Firewall forwarding requires Security to be enabled on both http and AIP connections.
To enable firewall forwarding, in SGD 4.5, you can set it up automatically (subject to certain restrictions) with a single command; the 'tarantella security enable' command. For more information, see ["Enabling SGD Security Services with Automatic Configuration" |http://docs.sun.com/source/820-6689/chapter1.html#d0e3767].
If unable to use automatic configuration, firewall traversal can be setup using manual methods; see ["Setting Up Secure Client Connections (Manual Configuration)"|http://docs.sun.com/source/820-6689
/chapter1.html#Z40000061439433].
Similar to the "Firewall Forwarding" technique is the SGD Secure Gateway. First available in Version 4.50, the Secure Gateway is a alternative to firewall traversal; that is, you either configure firewall traversal or a Secure Gateway, not both. The Secure Gateway is designed to be installed on one or more dedicated servers deployed "in front" of SGD servers, typically in the DMZ, allowing the SGD server/array to be installed in an internal network.
An example of a simple Gateway deployment:
!post-4.50.png|align=center!
The Secure Gateway performs the functions of a traditional reverse proxy, as well as an AIP router. It can also perform load-balancing, and multiple gateways can be installed to avoid a single point of failure. For more information on the Secure Gateway, see [SGD 4.50 Gateway Administration Guide.|http://docs.sun.com/source/820-6691/index.html]
h3. How Can I Redirect Users to The "Secure" / _https_ Port?
For version 4.50, the simplest way is to edit the Apache httpd.conf file, and locate the section that reads:
{{SGD BEGIN AUTO-FORWARD TO HTTPS (don't delete this line!}}
and uncomment (removing the leading {{#}} signs) from each line in the section, and restarting the webserver.
For previous versions, please see [Secure Deployment Checklist|Best Practice - Secure Deployment Checklist - (V. 4.41)#Redirect]. By redirecting users to the secure port, you can ensure that the connection, especially including login credentials, are strongly encrypted.
h3. Can SGD be installed using Solaris Containers / Zones?
Yes, SGD can be installed in both global and non-global zones, subject to some caveats:
* For Unix Application Servers, Client Drive Mapping depends on NFS support, and since NFS is restricted to global zones, then Unix CDM can only be supported in a global zone;
* There have been (unconfirmed) reports that installing the SGD Server in a global zone with non-global zones active may cause intermittent application launch issues. If zones are in use, you may wish to consider installing SGD in a non-global zone, as this seems to alleviate the problem. Note that this is _not_ a confirmed issue, and installations in the global zone remain fully supported, but you may wish to consider this when planning a new installation.
h3. Is Secure Global Desktop Supported on Virtualization Platform _x_?
Yes, Secure Global Desktop is "supported" on virtual machine instances, provided, of course, the virtualized operating system instance in one of the tested and supported operating systems listed for the particular SGD release. However, if the problem cannot be reproduced by Sun Support, you may be asked to demonstrate the issue on a non-virtualized operating to ensure the problem isn't related to the use of a virtualization technologu. If it's determined that a particular problem is related to the use of a virtualization technology, then Sun may be unable to offer a solution.
|