C H A P T E R  1

Networking and Security

This chapter describes how to integrate Sun Secure Global Desktop Software (SGD) into your network infrastructure and secure the network connections used by SGD.

This chapter includes the following topics:


Overview of Networks and Security

When using SGD, client devices never connect directly to application servers. Instead they connect to SGD using Hypertext Transfer Protocol (HTTP) or HTTP over Secure Sockets Layer (HTTPS) and the SGD Adaptive Internet Protocol (AIP). SGD then connects to the application servers on the user’s behalf. The network connections required are shown in FIGURE 1-1.

FIGURE 1-1   Diagram Showing the Network Connections Required by SGD

Diagram showing the network connections between
application servers on the left, SGD servers in the middle, and
client devices on the right.


SGD servers can also join together as an array.

The following are the main network connections involved when using SGD:

In a default SGD installation, most network connections are not secure. The following sections describe how you can secure these network connections.

Connections Between Client Devices and SGD Servers

To secure connections between client devices and SGD servers, configure the SGD web server to be a secure (HTTPS) web server, and enable SGD security services. See Securing Connections Between Client Devices and SGD Servers for details.

SGD security services enables SGD to use Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to provide secure connections between an SGD Client and an SGD server. SGD supports TLS version 1.0 and SSL version 3.0.

Secure connections have the following benefits:

The SGD Gateway can also be used to provide an increased level of security between client devices and SGD servers, see The SGD Gateway.

Connections Between SGD Servers and Application Servers

The connections between SGD servers and application servers are used to start applications on the application server, and to send and receive data from the application, such as key presses and display updates.

The level of security between SGD and your application servers depends on the types of application server and the protocols they use.

UNIX or Linux System Application Servers

When connecting using the Telnet protocol or the rexec command, all communication and passwords are transmitted unencrypted.

For secure connections to UNIX® or Linux system application servers, use Secure Shell (SSH). SSH encrypts all communications between SGD hosts and encrypts passwords before they are transmitted. See Securing Connections to Application Servers with SSH.

By default, SGD secures X displays using X authorization. This prevents users from accessing X displays they are not authorized to access.

Microsoft Windows Application Servers

The level of security depends on the protocol configured for the Windows application, as follows:

  • Microsoft Remote Desktop (RDP) protocol – All communication is encrypted

  • Citrix Independent Computing Architecture (ICA®) protocol – All communication uses the Telnet protocol and is unencrypted

For secure connections to Microsoft Windows application servers, use the Microsoft RDP protocol.

Web Application Servers

The level of security depends on the type of web server used to host the web application, as follows:

  • HTTP web servers – All communication is unencrypted

  • HTTPS web server – All communication is encrypted

For secure connections to web application servers, use HTTPS web servers.

Connections Between SGD Servers in an Array

Connections between SGD servers are used to share static and dynamic data across the array. This includes the following:

See Securing Connections Between SGD Servers for details on how to secure these connections.


The SGD Gateway

The SGD Gateway is an optional SGD component. It is a proxy server designed to be deployed in front of an SGD array in a demilitarized zone (DMZ), and it enables an SGD array to be located on your internal network. Additionally, all connections can be authenticated in the DMZ before any connections are made to the SGD servers in the array.

The SGD Gateway consists of the following components:

Using the SGD Gateway is an alternative to running your SGD servers with firewall traversal, also called firewall forwarding. The SGD Gateway manages the load balancing of HTTP connections, so you do not need to use the JavaServer Pagestrademark (JSPtrademark) technology load balancing page included with SGD.

Instructions on how to install, configure, and use the SGD Gateway are included in the Sun Secure Global Desktop 4.5 Gateway Administration Guide.


DNS Names

The following are the main Domain Name System (DNS) requirements for SGD:

SGD servers can have multiple DNS names. Each SGD server has one peer DNS name, and one or more external DNS names.

A peer DNS name is the DNS name that the SGD servers in the array use to identify themselves to each other. For example, boston.indigo‐insurance.com.

An external DNS name is the DNS name that the SGD Client uses to connect to an SGD server. For example, www.indigo‐insurance.com.

These two types of DNS names might be associated with the same network interface on the SGD host, or they might each use a different network interface. These DNS names must be fully-qualified DNS names.

When you install SGD you are prompted for a DNS name for the SGD server. This must be the peer DNS name that is used inside the firewall. This is the DNS name that the SGD web server binds to.

After installation, you can configure each SGD server with one or more external DNS names. The external DNS name is used by the SGD Client when it connects to an SGD server. By default, the peer DNS name is also used as an external DNS name. If you use the SGD Gateway, external DNS names are only used for direct client connections that are not routed through an SGD Gateway, see The SGD Gateway for more information.

In a network containing a firewall, you might need to make some names usable outside the firewall, for example across the Internet, and others usable inside the firewall. For example, users outside the firewall might be able to use www.indigo‐insurance.com, but not boston.indigo‐insurance.com. Users inside the firewall might be able to use either name.



caution icon

Caution - You do not have to make all your SGD servers available outside the firewall. However, if users log in to an SGD server from both inside and outside the firewall, they might not be able to resume some applications when logging in from outside the firewall.



If you are using mechanisms such as an external hardware load balancer or round‐robin DNS to control the SGD server that a user connects to, you must configure SGD to work with these mechanisms, see User Session Load Balancing.

This section includes the following topics:

Configuring External DNS Names

When an SGD Client connects to an SGD server, it connects using the external DNS name provided by the SGD server. The actual DNS name used is determined using the Internet Protocol (IP) address of the client.

If you use the SGD Gateway, external DNS names are only used for direct client connections that are not routed through an SGD Gateway, see The SGD Gateway for more information.

You configure external DNS names by setting one or more filters that match client IP addresses to DNS names. Each filter has the format Client-IP-Pattern:DNS-Name

The Client-IP-Pattern can be either of the following:

SGD servers can be configured with several filters. The order of the filters is important because SGD uses the first matching Client‐IP‐Pattern.



caution icon

Caution - If SGD is configured for firewall traversal, you cannot use multiple external DNS names because SGD cannot determine the IP address of the client device. In this situation, you can configure a single external DNS name, for example *:www.indigo-insurance.com, and then use split DNS so that clients can resolve the name to different IP addresses, depending on whether they are inside or outside the firewall. See Using Firewall Traversal.



The following is an example of external DNS names configuration:


"192.168.10.*:boston.indigo-insurance.com,*:www.indigo-insurance.com"

With this configuration, the following applies:

If the order of the filters is reversed, all clients connect to www.indigo‐insurance.com.

procedure icon  How to Configure the External DNS Names of an SGD Server

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. In the Administration Console, go to the SGD Servers tab and select an SGD server.

    The General tab displays.

  2. In the External DNS Names field, type one or more filters for the external DNS names.

    Each filter matches client IP addresses to DNS names.

    Press the Return key after each filter.

    The format of each filter is described in Configuring External DNS Names.

    The order of the filters is important. The first match is used.

  3. Click Save.

  4. Restart the SGD server.

    You must restart the SGD server for the external DNS names to take effect.

Changing the Peer DNS Name of an SGD Server

You can change the peer DNS name of an SGD server without having to reinstall the software, see How to Change the Peer DNS Name of an SGD Server.

You must detach an SGD server from an array and stop SGD before changing its peer DNS name.

After changing the DNS name, the /opt/tarantella/var/log/SERVER_RENAME.log file contains the details of the changes that were made. Your existing server security certificates are backed up in the /opt/tarantella/var/tsp.OLD.number directory.

Changing a peer DNS name of an SGD server might also affect your application servers, see Configuring Application Servers after Changing a Peer DNS Name.

procedure icon  How to Change the Peer DNS Name of an SGD Server

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

You can only change the peer DNS name from the command line.

  1. Log in as superuser (root) on the SGD host.

  2. Detach the SGD server from the array.

    If you are changing the peer DNS name of the primary SGD server, first make another server the primary server and then detach the server.


    # tarantella array detach --secondary serv
    

    Run the tarantella status command on the detached server to check that is detached from the array.

  3. Stop the SGD server.

  4. Ensure that the DNS name change for the SGD host has taken effect.

    Check your DNS configuration and ensure that the other SGD servers can resolve the new DNS name. You might also have to edit the /etc/hosts and the /etc/resolv.cnf files on the SGD host.

  5. Change the DNS name of the SGD server.

    Use the following command:


    # tarantella serverrename --peerdns newname [ --extdns newname ]
    

    Use the --extdns option to change the external DNS name of the server. This option only works if the SGD server has a single external DNS name. If the server has more than one external DNS name, you must manually update the external DNS names. See Configuring External DNS Names.

    When prompted, type Y to proceed with the name change.

  6. Regenerate the certificates used for secure intra‐array communication.


    # tarantella security keystoregen
    

    For details about secure intra‐array communication, see Securing Connections Between SGD Servers.

    If you are using the SGD Gateway, you must install the new peer Certificate Authority (CA) certificate on each SGD Gateway.

  7. Create and install a new server SSL certificate.

    For details about server SSL certificates, see Securing Connections Between Client Devices and SGD Servers.

    If you are using the SGD Gateway, you must install the new server SSL certificate on each SGD Gateway.

  8. Restart the SGD web server and SGD server.

  9. Join the SGD server to the array.


    # tarantella array join --primary p-serv --secondary s-serv
    

Configuring Application Servers after Changing a Peer DNS Name

If you have installed SGD printer queues on UNIX or Linux platform application servers, you might have to remove the printer queue that uses the old DNS name of the SGD server, and configure a new printer queue that uses the new DNS name of the SGD server. See Configuring UNIX and Linux Platform Application Servers for Printing.

If you use an SGD server as an application server, you must manually reconfigure the application server object by changing the DNS name for the application server and, optionally, renaming the object.


Proxy Servers

To be able to connect to SGD through a proxy server, client devices might need to be configured with the address and port number of the proxy servers. You might also need to configure SGD to give clients information about server-side proxy servers.

This section includes the following topics:

Supported Proxy Servers

To use SGD with a proxy server, the proxy server must support tunneling. You can use HTTP, Secure (SSL) or SOCKS version 5 proxy servers.

For SOCKS version 5 proxy servers, SGD supports the Basic and No Authentication Required authentication methods. No server-side configuration is required.

Configuring Client Proxy Settings

To configure client proxy settings, you must configure proxy settings for both the HTTP connections and the AIP connections. How you do this is described in the following sections.

HTTP Connections

HTTP connections are the connections between the user’s browser and the SGD web server, for example to display a webtop. These connections always use the proxy settings configured for the browser.

AIP Connections

AIP connections are the connections between the SGD Client and the SGD server used to display applications. For these connections, the settings in the client profile control whether the SGD Client determines the proxy settings from a browser or from the client profile itself.

The SGD Client always stores the last proxy settings it used in the client profile cache. See About the Profile Cache for details.



Note - You can only configure a SOCKS proxy for the AIP connection by specifying an array route, see Configuring Server-Side Proxy Servers for details.



Determining Proxy Settings From a Browser

If the Use Default Web Browser Settings check box is selected in the client profile, the proxy server settings are determined from the user’s default browser. The SGD Client stores the proxy settings in the profile cache on the client device and uses these settings when it next starts.

If Establish Proxy Settings on Session Start is selected in the client profile, the SGD Client obtains the proxy settings from the browser every time it starts. The stored proxy settings are not used. If Automatic Client Login is selected in the client profile, the Establish Proxy Settings on Session Start setting is disabled.

If the SGD Client is Integrated mode, and there are no proxy settings in the profile cache, the SGD Client attempts to make a direct connection.

To be able to determine the proxy settings from a browser, the browser must have Java technology enabled. If Java technology is not available, or it is disabled in the browser, the proxy settings must be manually specified in the client profile.



Note - If proxy server settings are defined in the Java Control Panel for the Sun Java Plugin tool, these settings are used instead of the browser settings.



Specifying Proxy Settings in the Client Profile

If the Manual Proxy Settings check box is selected in the client profile, you can specify either an HTTP or an SSL proxy server in the client profile itself.

Using Proxy Server Automatic Configuration Scripts

Whenever client proxy server configuration is determined from a browser, you can use an automatic configuration script to automatically configure the proxy settings.

You specify the Uniform Resource Locator (URL) of the configuration script in the connection settings for the browser. The automatic configuration script must be written in the JavaScripttrademark programming language and have either a .pac file extension or no file extension. See Proxy Auto-Config File for details.



Note - Use this format for all browsers supported by SGD.



Known Issue With Automatic Configuration Scripts

Proxy server automatic configuration scripts can specify a list of proxy servers to try. If the first proxy server in the list is unavailable, the browser tries the other proxy servers in turn until it finds one that is available.

If you are using Microsoft Internet Explorer with Sun Java Plugin tool version 1.5.0, only the first proxy server in the list is used. If that proxy server is not available, the connection fails. The solution is to use Sun Java Plugin tool version 1.6.0.

Proxy Server Exception Lists

You can use proxy server exception lists to control the connections that are not proxied. Proxy exception lists can only be used if the proxy settings are determined from a browser. You cannot configure exception lists in the client profile. The exception list can be configured in the browser or Sun Java Plugin tool.

An exception list is a list of DNS host names. For Internet Explorer, the list is a semicolon-separated list. For Mozilla-based browsers, the list is a comma‐separated list. Exception lists can include the * wildcard.

There is no translation between DNS host names and IP addresses in exception lists. For example, with an exception list of *.example.com, connections to chicago.example.com and detroit.example.com do not use a proxy server, but connections that use the IP addresses for these hosts do use a proxy server.

Exception lists must always include the following entries:

localhost; 127.0.0.1

Proxy Server Timeouts

Proxy servers can drop a connection after a short period of time if there is no activity on the connection. By default, SGD sends AIP keepalive packets every 100 seconds to keep the connection open.

If you find that applications disappear after a short while, you might have to increase the frequency at which AIP keepalive packets are sent.

In the Administration Console, go to the Global Settings -> Communication tab and decrease the AIP Keepalive Frequency. Alternatively, use the following command:


$ tarantella config edit --sessions-aipkeepalive secs

Configuring Server-Side Proxy Servers

SGD can be configured to “instruct” the SGD Client to connect through a server‐side SOCKS version 5 proxy server. The actual proxy server used is determined using the IP address of the client. This known as an array route.

If you use the SGD Gateway, array routes are only used for direct client connections that are not routed through an SGD Gateway, see The SGD Gateway for more information.

You configure array routes by setting one or more filters that match client IP addresses to server-side proxy servers. Each filter has the format Client-IP-Pattern:type:host:port.

The Client-IP-Pattern can be either of the following:

The type is a connection type. Use CTSOCKS for a SOCKS version 5 connection. Use CTDIRECT to connect directly without using a proxy server.

The host and port are the DNS name, or IP address, and port of the proxy server to use for the connection.

SGD can be configured with several filters. The order of the filters is important because SGD uses the first matching Client‐IP‐Pattern.

If you use an external SSL accelerator instead of SGD to handle SSL processing, append the array route with :ssl, see the following example. This instructs the SGD Client to use SSL on that connection before continuing with the SOCKS connection. See Using External SSL Accelerators for details.



caution icon

Caution - If SGD is configured for firewall traversal, you cannot use multiple array routes because SGD cannot determine the IP address of the client device. You can configure a single array route, for example *:CTSOCKS:taurus.indigo‐insurance.com:8080. See Using Firewall Traversal.



The following is an example of array routes configuration:


"192.168.5.*:CTDIRECT:, \
192.168.10.*.*:CTSOCKS:taurus.indigo‐insurance.com:8080, \
*:CTSOCKS:draco.indigo-insurance.com:8080:ssl"

With this configuration, the following applies:

procedure icon  How to Configure Array Routes

You can only configure array routes from the command line.

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

  1. Configure the filters for array routes.

    Use the following command:


    $ tarantella config edit \
    --tarantella-config-array-netservice-proxy-routes routes
    

    Enclose routes in quotes, and separate each filter with a comma, for example:

    "filter1,filter2,filter3"

    The format of each filter is described in Configuring Server-Side Proxy Servers.

    The order of the filters is important. The first match is used.

  2. Restart every SGD server in the array.

    You must restart every server in the array for array routes to take effect.


Firewalls

Firewalls can be used to protect various parts of a network. To use SGD you must configure your firewalls to allow packets to be sent between client devices and SGD servers, and between SGD servers and application servers, as shown in FIGURE 1-2.

FIGURE 1-2   Diagram Showing SGD Connections and Firewalls

Diagram showing firewalls between application
servers and SGD servers on the left, and between SGD servers and
client devices on the right.


This section includes the following topics:

Firewalls Between Client Devices and SGD Servers

Client devices must be able to make HTTP and AIP connections to any SGD server in the array. This is because a user’s SGD session and a user’s application sessions can be hosted on different SGD servers.

The following table lists the ports you might need to open to allow connections between client devices and SGD servers.


Source Destination Port Protocol Purpose
Client SGD web server 80 TCP Standard, unencrypted HTTP requests and responses.

Used to display webtops and for web services.

Client SGD web 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.


Transmission Control Ports (TCP) 80 and 443 are the Internet-standard ports for HTTP and HTTPS. Port 443 is only used if HTTPS is enabled on the SGD web server. You can configure the SGD web server to use any port. If you use your own web server with SGD, you must still open the ports used by the SGD web server because this web server provides the web services needed to access SGD.

In a default installation, ports 3144 and 5307 must both be open in the firewall. The SGD Client initially makes a secure connection on port 5307, but once the user has authenticated, the connection is downgraded to a standard connection on port 3144.

If you enable SGD security services and use only HTTPS, only ports 443 and 5307 must be open in the firewall.

If it is not possible to open the required ports, you can direct all SGD traffic through a single port, usually port 443. To do this, you can use either of the following:

Ports 3144 and 5307 are registered with the Internet Assigned Numbers Authority (IANA) and are reserved for use only by SGD.

Firewalls Between SGD Servers

A network might contain firewalls between the SGD servers in an array, for example if you have multiple offices each containing an SGD server. The SGD servers in an array must be able to connect to any other member of the array.

The following table lists the ports you might need to open to allow connections between SGD Servers.


Source Destination Port Protocol Purpose
SGD server Another SGD server 515 TCP Used when moving print jobs from one SGD server to another using the tarantella print move command.
SGD server Another SGD server 5427 TCP Used for connections between SGD servers to allow array replication, and sharing of both static and dynamic data across the array.

Port 5427 is registered with IANA and is reserved for use only by SGD.

If you enable support for audio, smart cards, or serial ports for Windows applications that use the Microsoft RDP protocol, your firewall must allow connections between SGD servers on TCP port 1024 and above. If you do not use these features, it is best to disable support for them in SGD. See the following for more information:

Firewalls Between SGD Servers and Application Servers

An SGD server must be able to connect to an application server in order to run applications.

The ports used for connections between SGD servers and application servers depends on the application type and the connection method used to log in to the application server. Other ports are needed to provide support while using applications.

The following table lists the ports you might need to open to allow connections between SGD Servers and application servers.


Source Destination Port Protocol Purpose
SGD server Application server 22 TCP Used to connect to X and character applications using SSH.
SGD server Application server 23 TCP Used to connect to Windows, X, and character applications using Telnet.
Application server SGD server 137 UDP Used for Windows Internet Name Service (WINS) services with client drive mapping. The server binds to this port at start‐up only if WINS services are enabled.
Application server SGD server 139 TCP Used for client drive mapping services. The server binds to this port at start-up, whether or not client drive mapping services are enabled.
SGD server Application server 512 TCP Used to connect to X applications using rexec.
Application server SGD server 515 TCP Used to send print jobs from the application server to an SGD server.
SGD server Application server 3389 TCP Used to connect to Windows applications configured to use the Microsoft RDP protocol.
SGD server Application server 3579 TCP Used for connections between the primary SGD server and the SGD load balancing service on an application server.
Application server SGD server 3579 UDP Used for connections between the SGD load balancing service on an application server and the primary SGD server.
SGD server Application server 5999 TCP Used to connect to Windows applications, if the application is configured to use the Wincenter protocol and the connection method is Telnet. The Wincenter protocol is no longer supported but might be used by legacy Windows application objects.
Application server SGD server 6010 and above TCP Used to connect X applications to the protocol engines on the SGD server.

User Datagram Protocol (UDP) port 137 and TCP port 139 might be used by products providing Windows file and print services, such as Samba. You only need to open these ports if you are using client drive mapping on Microsoft Windows application servers. See Client Drive Mapping for details.

For X applications, ports 6010 and above are only used if the connection method for X applications is Telnet or rexec. If the connection method is SSH, the connections use port 22. If you enable audio for X applications, all ports must be open between the application server and SGD. This is because the SGD audio daemon connects to the SGD server on random ports. This applies even if the connection method is SSH. See Audio for details.

Port 3579 is registered with IANA and is reserved for use only by SGD. You only need to open these ports if you are using SGD Advanced Load Management. See Application Load Balancing for details.

Other Firewalls

SGD needs to make connections to any authentication services and directory services you might be using.

The following table lists the ports you might need to open to allow connections between SGD Servers and other services.


Source Destination Port Protocol Purpose
SGD server Windows server 88 TCP or UDP Used to authenticate users from a Microsoft Windows domain.
SGD server Windows server 137 UDP Used to authenticate users from a Microsoft Windows domain.
SGD server Windows server 139 TCP Used to authenticate users from a Microsoft Windows domain.
SGD server LDAP directory server 389 TCP Used to authenticate users, or to assign applications to users, using a Lightweight Directory Access Protocol (LDAP) directory.
SGD server Windows server 464 TCP or UDP Used to enable users to change their password if it has expired.
SGD server LDAP directory server 636 TCP Used to authenticate users, or to assign applications to users, using a secure connection (LDAPS) to an LDAP directory.
SecurID Authentication Manager SGD server 1024 to

65535

UDP Used to authenticate users using SecurID.
SGD server Windows server 3268 TCP Used to authenticate users from a Microsoft Windows domain.
SGD server Windows server 3269 TCP Used to authenticate users from a Microsoft Windows domain.
SGD server SecurID Authentication Manager 5500 UDP Used to authenticate users using SecurID.

Ports 88, 464, 3268, 3269 are only required if you are using Active Directory authentication. Ports 88 and 464 can use either the TCP or UDP protocol depending on the packet size and your Kerberos configuration. See Configuring SGD for Kerberos Authentication for details.

Ports 137 and 139 are only required if you are using a domain controller for authentication. See Windows Domain Authentication for details.

Ports 389 and 636 are only required if you are using an LDAP directory to establish a user’s identity or to assign applications to users. This applies to the following authentication mechanisms:

Ports 1024 to 65535 are only required if you are using SecurID Authentication. For the RSA SecurID Authentication Manager to communicate with an SGD server acting as an Agent Host, all ports from 1024 to 65535 must be open from the IP addresses of the Master and Slave Authentication Managers to the IP addresses of all Agent Hosts. See SecurID Authentication for details.

Port 5500 is only required if you are using SecurID authentication. For the RSA SecurID Authentication Manager to communicate with an SGD server acting as an Agent Host, port 5500 must be open from the IP addresses of the Host Agents to the IP addresses of the Master and Slave Authentication Managers.


Securing Connections Between Client Devices and SGD Servers

When securing connections between client devices and SGD servers, the following connections must be considered:

When SGD is first installed, connections to the SGD web server are not secure. The initial connection between an SGD Client and an SGD server is secure, but after the user is logged in, the connection is downgraded to a standard connection. This section describes how to secure the connections between client devices and SGD servers.

This section includes the following topics:

Setting Up Secure Client Connections

You can set up secure client connections using automatic configuration or manual configuration.

Automatic configuration uses the tarantella security enable command to configure secure connections to an SGD server. However, automatic configuration can be used only on a fresh installation of SGD when the server is not part of an array.

Setting Up Secure Client Connections (Automatic Configuration)

Setting up secure client connections with automatic configuration involves the following steps:

  1. (Optional) Generate a Certificate Signing Request (CSR) and send it to a CA.

    See How to Generate a Certificate Signing Request.

    This step is optional if you obtain a server SSL certificate without using the tarantella security certrequest command to generate a CSR, or if you want to enable security using a self-signed SSL certificate.

  2. Install a server SSL certificate and enable security.

    See Enabling SGD Security Services With Automatic Configuration.

  3. (Optional) Configure connection definition processing.

    Connection definitions enable you to determine which users receive secure connections.

    See Using Connection Definitions.

Setting Up Secure Client Connections (Manual Configuration)

Setting up secure client connections with manual configuration involves the following steps:

  1. Obtain and install an SSL certificate for each SGD server in the array.

    To use secure connections, an SGD server must present an SSL certificate to identify itself to an SGD Client.

    See Obtaining and Installing a Server SSL Certificate.

  2. Configure each SGD web server in the array to use HTTPS.

    To secure the connections between a browser and an SGD web server, HTTPS connections must be enabled.

    See Using HTTPS Connections to the SGD Web Server.

  3. (Optional) Configure SGD for firewall traversal.

    If it is not possible to open TCP port 5307 between client devices and SGD servers, use firewall traversal to give users access to SGD using a single port, usually port 443.

    See Using Firewall Traversal.

  4. Configure the SOAP connections to use HTTPS.

    Client applications, such as the SGD webtop, use the Simple Object Access Protocol (SOAP) protocol and HTTP to access the web services provided by an SGD server.

    See Securing SOAP Connections to an SGD Server.

  5. Enable SGD security services and restart SGD.

    To enable secure connections, you must enable SGD security services and restart SGD.

    See Enabling SGD Security Services.

  6. (Optional) Configure connection definition processing.

    Connection definitions enable you to determine which users receive secure connections.

    See Using Connection Definitions.

Using Server SSL Certificates

An SSL certificate is an encoded file that a secure service, such as a web server, uses to identify itself to a client. When security is enabled, an SGD server requires an SSL certificate.

SGD supports Privacy Enhanced Mail (PEM) Base 64-encoded X.509 certificates. These certificates have the following structure:

-----BEGIN CERTIFICATE-----
...certificate...
-----END CERTIFICATE-----

SGD supports the Subject Alternative Name (subjectAltName) extension for server SSL certificates. This enables you to associate more than one DNS name with a certificate. If the subjectAltName field is present in an SSL certificate, the subject field is ignored and only the subjectAltName is used. The SSL certificate is accepted by the SGD Client if any of the Subject Alternative Names match the name of the SGD server you are connecting to.

Supported Certificate Authorities

A server SSL certificate is issued by a Certificate Authority (CA). A CA is a trusted third party that digitally signs a server SSL certificate using a CA, or root, certificate.

SGD includes support for a number of CA certificates by default. The /opt/tarantella/etc/data/cacerts.txt file contains the X.500 Distinguished Names (DNs) and MD5 signatures of all the CA certificates that SGD supports.

You can use a server SSL certificate that is signed by an unsupported CA. However, by default, all users are prompted to accept or decline these certificates because they cannot be validated by SGD. This is a potential security risk.

SGD supports the use of certificate chains. With certificate chains, an Intermediate CA signs an SSL certificate with a CA certificate that is issued by another CA.

If your server SSL certificate is signed by an unsupported CA, or an Intermediate CA, you must install the CA certificate or certificate chain.

Using an SSL Certificate Obtained for Another Product

You can use an SSL certificate that was originally obtained for another product, such as a web server. To do this, you must have access to the private key for that certificate. If the private key is encrypted by a product that uses the SSLeay or OpenSSL certificate libraries, you can obtain the private key by decrypting it. See How to Install an SSL Certificate Obtained for Another Product for details.

If you do not have access to the private key, or the key is not encrypted by a product that uses SSLeay or OpenSSL certificate libraries, you must obtain and install a new server SSL certificate. See Obtaining and Installing a Server SSL Certificate.

Self-Signed SSL Certificates

SGD enables you to create self-signed server SSL certificates for test purposes, for example, while you are waiting to complete the registration requirements before the SSL certificate can be generated.

Only use self-signed SSL certificates in a test environment because self-signed SSL certificates are not truly secure. While a self-signed SSL certificate can be used to give users secure connections, users have no guarantee that the server they are connecting to is genuine.

You can create self-signed SSL certificates with the following commands:

  • tarantella security selfsign – enables you to self-sign a CSR generated with the tarantella security certrequest command

  • tarantella security enable – enables you to configure a secure SGD server automatically and install a server SSL certificate

Obtaining and Installing a Server SSL Certificate

Obtaining and installing an SSL certificate for an SGD server involves the following configuration steps:

  1. (Optional) Generate a CSR and send it to a CA.

    See How to Generate a Certificate Signing Request.

    If you already have an SSL certificate for another product, such as a web server, you might be able to use that certificate. See Using an SSL Certificate Obtained for Another Product.

  2. Install the server SSL certificate.

    When a CA receives a CSR, they check the validity of the request, and return a signed SSL certificate. You then install the SSL certificate on the SGD server, see How to Install a Server SSL Certificate.

    To install an SSL certificate obtained for another product, see How to Install an SSL Certificate Obtained for Another Product.

  3. (Optional) Install the CA certificate.

    Perform this step only if the server SSL certificate is signed by an unsupported CA, or an Intermediate CA, see Supported Certificate Authorities.

    The certificates that must be installed are as follows:

procedure icon  How to Generate a Certificate Signing Request

  1. Log in as superuser (root) on the SGD host.

  2. Generate a CSR.

    Use the tarantella security certrequest command to generate the CSR.

    SGD supports the Subject Alternative Name (subjectAltName) extension for server SSL certificates. This enables you to associate more than one DNS name with an SSL certificate. See DNS Names for details.

    SGD supports the use of the * wildcard for the first part of the domain name, for example *.indigo‐insurance.com.

    Generating the CSR also creates the public and private key pair.

    On the SGD server, the CSR is stored in the /opt/tarantella/var/tsp/csr.pem file, and the private key is stored in the /opt/tarantella/var/tsp/key.pending.pem file.

    If you are replacing a server SSL certificate, for example because it is about to expire, you can generate a CSR without affecting your current certificate.

    In the following example, a CSR is generated for the SGD server boston.indigo‐insurance.com. This server also has an external DNS name of www.indigo‐insurance.com and so this name is added as a Subject Alternative Name.


    # tarantella security certrequest \
    --country US --state Massachusetts --orgname "Indigo Insurance"
     
    The certificate’s common name (CN) will be:  boston.indigo‐insurance.com
     
    This hostname is included in the Certificate Signing Request (CSR) and
    corresponds to the name of the server that users will connect to.
     
     - If DNS names are used to connect to the server, the hostname above
       MUST be a fully qualified DNS name.
     
     - If clients are required to connect to the server using an IP address,
       the hostname above should be the IP address. A DNS record for this
       IP address SHOULD NOT exist.
     
    For clients to accept the certificate once it’s installed, a DNS
    lookup of the hostname followed by a reverse lookup of the result must
    return the original hostname.
     
    The hostname to be used in the certificate request is
    boston.indigo‐insurance.com.
     
     
    Do you want to use this hostname? [yes] y
     
     
    Do you want to add any additional hostnames? [no] y
     
    Type in the subject alternative names for the certificate, one per line. Enter a 
    blank line to finish.
     
    subjectAltName: www.indigo-insurance.com
    subjectAltName:
    2048 semi-random bytes loaded
    Generating RSA private key, 1024 bit long modulus
    ..++++++
    ...........................................................++++++
    e is 65537 (0x10001)
     
    --------------------------------------------------------------------------
    Certificate Signing Request (CSR): Summary
    --------------------------------------------------------------------------
     
    Subject:
     C=US
     ST=Massachusetts
     O=Indigo Insurance
     CN=boston.indigo‐insurance.com
     
     
    Subject Alternative Names:
     DNS:boston.indigo‐insurance.com, DNS:www.indigo-insurance.com
     
    The information above will be contained in the CSR.
     
    Create CSR now? [yes] y
     
    Send the following Certificate Signing Request (CSR) to a Certificate
    Authority, such as VeriSign (www.verisign.com). Check with your CA
    that you’re providing all the information they need.
     
    ------CUT HERE------
    -----BEGIN CERTIFICATE REQUEST-----
    NhY2h1c2V0MIIB5TCCAU4CAQAwXDELMAkGA1UEBhMCVVMxFjAUBgNVBAgTDU1hc3
    dpZS5VdHMxGTAXBgNVBAoTEEluZGlnbyBJbnN1cmFuY2UxGjAYBgNVBAMTEXJhZG
    sd+SmX7zz6Sy5TdW4uQ09NMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDbWM
    sMqBs7gQw8Q1Gk3NAypySP6aRiEItLrfSlZ8XgKXmjmlLtb03V9JonjLfhH3fBzk
    gnOG6EpTmJM4y3OOpEXZZ2yhtWgsQsXyLWbfTLWZPfHLPI5ztEEJ7Z0G6dpeG0xg
    wODA2ApAp6sIrmBqbZG2Aaf5poB+FQ4lsmQIDAQABoEkwRwYJKoZIhvcNAQkOMTo
    N1cmFuBgNVHREELzAtghFyYWRnaWUuVUsuU3VuLkNPTYIYd3d3LmluZGlnby1pbn
    V617E7oFKY2UuY29tMA0GCSqGSIb3DQEBBQUAA4GBAMsOieZzrGHN7fkW6LmYNHW
    sW1tmHeFjekpiUiTLYE+KUZXKKCH9f1eo+nfwFdi9VOomIdga4uehl+4acqqiGEe
    W4iIb9BC9b/V1pA/lGJwWN0aDDB3/d47UGAlli+spW37chg53Fp7eP2xIYWfJR6O
    35eSPZm42dyp
    -----END CERTIFICATE REQUEST-----
    ------CUT HERE------
     
    When you receive your certificate, use ’tarantella security certuse’
    to install it.
    

  3. Send the CSR to a CA.

    See Supported Certificate Authorities for details of the CAs that SGD supports by default.

    Either copy the CSR as output from the command line, or use the copy of the CSR that is stored in the /opt/tarantella/var/tsp/csr.pem file on the SGD server.

    While you are waiting for the CA to return the server SSL certificate, you can use the tarantella security selfsign command to create and install a self-signed SSL certificate for test purposes. See Self-Signed SSL Certificates for more details.

procedure icon  How to Install a Server SSL Certificate

Use the following procedure to install a server SSL certificate that was obtained by using the tarantella security certrequest command to generate a CSR.

Before you begin, ensure you have access to the server SSL certificate. The SSL certificate must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Install the server SSL certificate.

    Use the tarantella security certuse command to install the SSL certificate.

    If you are replacing a server SSL certificate, for example because the original SSL certificate is about to expire, the tarantella security certuse command prompts you for confirmation before overwriting the SSL certificate and private key.

    When you install the server SSL certificate, the private key stored in the /opt/tarantella/var/tsp/key.pending.pem file is moved to the /opt/tarantella/var/tsp/key.pem file.

    If you specify the path to a file, you must specify the full path to the file.

    The CSR, the SSL certificate, and the private key are stored in the /opt/tarantella/var/tsp directory on the SGD server.

    • To install the SSL certificate from standard input, use the following command:


      # tarantella security certuse
      

      Paste the server SSL certificate in to standard input and press Control-D.

    • To install the SSL certificate from a temporary file, use the following command:


      # tarantella security certuse < /tmp/cert
      

    • To install the SSL certificate from a permanent file, use the following command:


      # tarantella security certuse --certfile /opt/certs/cert.pem
      



      caution icon

      Caution - This command creates a symbolic link to the SSL certificate file stored in the /opt/tarantella/var/tsp directory on the SGD server. Do not delete or move the SSL certificate file after running this command.



procedure icon  How to Install an SSL Certificate Obtained for Another Product

Use the following procedure to install an SSL certificate obtained without using the tarantella security certrequest command to generate a CSR.

To install an SSL certificate obtained for another product, you must have the private key for that certificate. If the private key is encrypted by a product that uses the SSLeay or OpenSSL certificate libraries, you can obtain the private key by decrypting it.

  1. Log in as superuser (root) on the SGD host.

  2. Copy the SSL certificate and key file to a safe location on the SGD host that can only be accessed by superuser (root).

    For example:


    # cp /etc/httpd/certs/boston‐indigo‐insurance.com.pem \
    /opt/tarantella/var/tsp
    # cp /etc/httpd/certs/boston‐indigo‐insurance.com.key.pem \
    /opt/tarantella/var/tsp
    

  3. Decrypt the certificate’s private key.

    Use the tarantella security decryptkey command.

    For example:


    # tarantella security decryptkey \
    --enckey /opt/tarantella/var/tsp/boston.indigo‐insurance.com.key.pem \
    --deckey /opt/tarantella/var/tsp/boston.indigo‐insurance.com.key.out \
    --format PEM
    

  4. Install the SSL certificate.

    Use the tarantella security certuse command to install the SSL certificate.

    When you specify the path to the SSL certificate file and the key file, you must specify the full path.

    For example:


    # tarantella security certuse \
    --certfile /opt/tarantella/var/tsp/boston.indigo‐insurance.com.pem \
    --keyfile /opt/tarantella/var/tsp/boston.indigo-insurance.com.key.out
    



    caution icon

    Caution - This command creates symbolic links to the SSL certificate file and the key file in the /opt/tarantella/var/tsp directory on the SGD server. Do not delete or move the SSL certificate file or key file after running this command.



procedure icon  How to Install the CA Certificate for an Unsupported CA

Before you begin, ensure you have access to the CA certificate. The CA certificate must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Install the CA certificate.

    Use the tarantella security customca command.

    • To install the CA certificate from standard input, use the following command:


      # tarantella security customca
      

      Paste the CA certificate in to standard input and press Control-D.

    • To install the CA certificate from a file, use the following command:


      # tarantella security customca --rootfile /tmp/cert
      

procedure icon  How to Install a CA Certificate Chain

Before you begin, ensure that you have all the certificates in the CA certificate chain. The certificates must be in PEM format.

  1. Log in as superuser (root) on the SGD host.

  2. Combine all the certificates in the chain into a file.

    For example, create a file called chainedcerts.pem.

    The CA certificate used to sign the server SSL certificate must appear first, for example:

    -----BEGIN CERTIFICATE-----
    ...Intermediate
    CA’s certificate...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...CA
    root certificate...
    -----END CERTIFICATE-----

  3. Install the CA certificate chain.

    Use the tarantella security customca command.

    • To install the CA certificate from standard input, use the following command:


      # tarantella security customca
      

      Paste the CA certificate chain in to standard input and press Control-D.

    • To install the CA certificate from a file, use the following command:


      # tarantella security customca --rootfile /tmp/chainedcerts.pem
      

procedure icon  How to Replace a Server SSL Certificate

Use the following procedure to replace the server SSL certificate for an SGD server, for example because the original SSL certificate is about to expire.

  1. Obtain and install a new server SSL certificate.

    See Obtaining and Installing a Server SSL Certificate for details.

  2. Restart the SGD server and SGD web server.

    You must restart the SGD server to ensure that the new server SSL certificate is used for secure connections.

    Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

    Use the following command:


    # tarantella restart
    

Enabling SGD Security Services With Automatic Configuration

The tarantella security enable command enables you to quickly configure and start SGD security services. You can only use this command if both of the following are true:

If these conditions are not met, the tarantella security enable command fails and you must enable security by configuring it manually. See Setting Up Secure Client Connections (Manual Configuration).

The tarantella security enable command performs the following configuration:

If you do not specify a server SSL certificate to install, the tarantella security enable command creates and installs a self-signed SSL certificate. If you want to install a server SSL certificate later, use the tarantella security disable command to restore the security settings to their previous state. You can then run the tarantella security enable command again and specify a server SSL certificate.

By default, the tarantella security enable command configures the SGD server for firewall traversal. Use the --firewalltraversal off option if you want to enable security without firewall traversal. You can enable firewall traversal later by doing either of the following:



Note - SGD servers configured for firewall traversal cannot be used with the SGD Gateway.



procedure icon  How to Enable SGD Security Services With Automatic Configuration

Before you begin, ensure you have access to the server SSL certificate, and the private key and CA certificate, if needed. The certificates must be in PEM format.

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the SGD host.

  2. Install a server SSL certificate and enable SGD security services.

    Use the tarantella security enable command to install a server SSL certificate and enable SGD security services.

    If you used the tarantella security certrequest command to generate a CSR, you can omit the --keyfile option. The key stored in the /opt/tarantella/var/tsp/key.pending.pem file is used. When you install the server SSL certificate, the private key is moved to the /opt/tarantella/var/tsp/key.pem file.



    caution icon

    Caution - If you use the --certfile option and the --keyfile option together, SGD creates symbolic links to the SSL certificate file and the key file in the /opt/tarantella/var/tsp directory on the SGD server. Do not delete or move the SSL certificate file or key file after running this command.



    If you do not specify a server SSL certificate to install, the tarantella security enable command generates a CSR, and then creates and installs a self-signed SSL certificate. Only use a self-signed SSL certificate for test purposes.

    SGD supports a number of CAs by default. Only use the --rootfile option if the server SSL certificate is signed by an unsupported CA, or by an Intermediate CA. See Supported Certificate Authorities for details.

    If the server SSL certificate is signed by an Intermediate CA, combine all the certificates in the CA certificate chain into a file. The certificates must be in PEM format. The CA certificate used to sign the server SSL certificate must appear first, for example:

    -----BEGIN CERTIFICATE-----
    ...Intermediate
    CA’s certificate...
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    ...CA
    root certificate...
    -----END CERTIFICATE-----

    If you specify the path to a certificate or key file, you must specify the full path to the file.



    caution icon

    Caution - If you use the SGD Gateway, you must use the --firewalltraversal off option to enable security without firewall traversal. SGD servers configured for firewall traversal cannot be used with the SGD Gateway.



    The CSR, the SSL certificate, the private key, and the CA certificate are stored in the /opt/tarantella/var/tsp directory on the SGD server.

    • If the server SSL certificate is signed by a supported CA, and the tarantella security certrequest command was used to generate a CSR, use the following command:


      # tarantella security enable [ --firewalltraversal off ]\
      --certfile certificate-path
      

    • If the server SSL certificate is signed by a supported CA, and the tarantella security certrequest command was not used to generate a CSR, use the following command:


      # tarantella security enable [ --firewalltraversal off ]\
      --certfile certificate-path --keyfile key-path
      

    • If the server SSL certificate is signed by an unsupported CA, or an Intermediate CA, use the following command:


      # tarantella security enable [ --firewalltraversal off ]\
      --certfile certificate-path [--keyfile key-path] \
      --rootfile CA-certificate-path
      

    • To enable SGD security services with a self-signed SSL certificate, use the following command:


      # tarantella security enable [ --firewalltraversal off ]
      

Using HTTPS Connections to the SGD Web Server

SGD security services only secure the connections between an SGD Client and an SGD server. To secure the connections between a browser and an SGD web server on the SGD host, HTTPS connections must be enabled on the web server.

The SGD web server is preconfigured to be a HTTPS web server and use the same SSL certificate as the SGD server. This is configured in the Apache configuration file, /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/conf/httpd.conf.



Note - You can use a separate SSL certificate for the SGD web server if you prefer.



Once a server SSL certificate is installed, you enable HTTPS connections by using the --https argument when you start the SGD server or the SGD web server. See Enabling SGD Security Services.

If you enable HTTPS connections, you must enable HTTPS connections for every SGD web server in the array. You must not mix HTTP and HTTPS web servers in the same SGD array. Every SGD web server in the array must use the same HTTPS port.

Once you enable secure connections to a web server, ensure that users have an HTTPS URL for the Login URL in their client profile. See Client Profiles.

For advice on securing the SGD web server, see Securing the SGD Web Server.

Using Firewall Traversal

When SGD security services are enabled, the SGD Client connects to an SGD server on TCP port 5307. If it is not possible to open this port between client devices and SGD servers, you can use firewall traversal to give users access to SGD using a single port, usually port 443. With firewall traversal, you configure the SGD server to listen on port 443. The SGD server then forwards all traffic that is not AIP traffic to the SGD web server. For this reason, firewall traversal is sometimes called firewall forwarding.

By default, the tarantella security enable command configures an SGD server for firewall traversal, see Enabling SGD Security Services With Automatic Configuration. Use the information in this section if you want to enable firewall traversal manually.

If SGD is configured for firewall traversal, you cannot use any SGD features that depend on filtering the IP address of the client device. This means you cannot use the following features:

If you use firewall traversal, you can configure a single external DNS name, for example *:www.indigo-insurance.com, and then use split DNS so that clients can resolve the name to different IP addresses, depending on whether they are inside or outside the firewall.

procedure icon  How to Configure Firewall Traversal

  1. Configure each SGD web server in the array to bind to localhost and TCP port 443.

    Repeat the following step on each SGD web server in the array.

    1. Log in as superuser (root) on the SGD host.

    2. Edit the Apache configuration file.

      The configuration file is /opt/tarantella/webserver/apache/2.2.10_openssl‑0.9.8i_jk1.2.27/conf/httpd.conf.

    3. Change the <IfDefine SSL> directive in the SSL Support section.

      Change the directive to the following:

      <IfDefine SSL>
      Listen 127.0.0.1:443
      </IfDefine>

    4. Save the changes.

  2. Log in as superuser (root) on the primary SGD server in the array.

  3. Configure each SGD server in the array to use TCP port 443 for encrypted connections.

    Use the following command:


    # tarantella config edit --array-port-encrypted 443
    



    Tip - You can also configure the port in the Administration Console. Go to the Global Settings -> Communication tab. Type 443 in the Encrypted Connections Port field.



  4. Configure each SGD server in the array to forward HTTP traffic to the SGD web server.

    Use the following command:


    # tarantella config edit --array \
    --security-firewallurl https://127.0.0.1:443
    



    Tip - You can also configure the port in the Administration Console. Select an SGD server and go to the Security tab. Type https://127.0.0.1:443 in the Firewall Forwarding URL field.



  5. Check that the firewall forwarding URL has taken effect for each SGD server in the array.

    Use the following command to check each server:


    # tarantella config list --server serv --security-firewallurl
    

Securing SOAP Connections to an SGD Server

Client applications, such as the SGD webtop, use the SOAP protocol and HTTP to access the web services provided by an SGD server. You can use HTTPS to secure these connections.

To secure the SOAP connections, a client application, such as the SGD webtop, must be configured to use HTTPS. The client application must also be able to validate the server SSL certificate for any SGD server in the array. To do this, the client application’s truststore must contain the CA certificate, or the certificate chain, used to sign the server SSL certificate.

You must secure the SOAP connections to SGD in the following circumstances:

procedure icon  How to Secure the SOAP Connections to an SGD Server

  1. Log in as superuser (root) on the SGD host.

  2. Import CA certificates or certificate chains into the CA certificate truststore.

    SGD supports a number of CAs by default. You only need to import CA certificates if the SSL certificate for any SGD server in the array is signed by an unsupported CA, or by an Intermediate CA.

    See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.

  3. Configure the web services resources file for the client application.

    1. Change to the shared resources directory.


      # cd /opt/tarantella/webserver/tomcat/6.0.18_axis1.4
      # cd shared/classes/com/tarantella/tta/webservices/client/apis
      

    2. Edit the Resources.properties file.

      For each of the web services listed in the properties file, change the URL to an HTTPS URL and change the port number to port 443, for example, https://server.example.com:443/axis/services/document/print, where server.example.com is the name of the SGD server.

    3. Save the changes.

Securing the SOAP Connections From Remote Hosts

This section contains information about securing SOAP connections to SGD from a client application that is hosted remotely. Typically this occurs in the following circumstances:

  • You relocate the SGD webtop to another JSP technology container

  • You develop your own client applications, using a relocated SGD com.tarantella.tta.webservices.client.views package

If you develop your own client applications without using the SGD com.tarantella.tta.webservices.client.views package, the information in this section contains the principles you need to follow to secure the SOAP connections to an SGD server.

To secure the SOAP connections from remote hosts, you configure the following:

  • The CA certificates truststore on the remote host

  • The web services resources file on the remote host

  • The CA certificates truststore on the SGD server

Configuring the CA Certificates Truststore on the Remote Host

On the remote host, you might have to import CA certificates into the Java Runtime Environment (JREtrademark) software truststore for your JSP technology container. This truststore is used for the HTTPS connections from the client application to the SGD server, and enables the client application to validate the SSL certificate presented by an SGD server.

You must ensure that the JRE software truststore contains the CA certificate used to sign the certificate for any SGD server in the array. If a server SSL certificate was signed by an Intermediate CA, ensure that the truststore contains every certificate in the CA certificate chain.

If the tarantella security customca command is used to install a CA certificate or certificate chain on an SGD server, the /opt/tarantella/var/tsp/ca.pem file contains the CA certificate or certificate chain.

How you import certificates, and the truststore used, depends on the JSP technology container.

Configuring the Web Services Resources File on the Remote Host

On the remote host, you must configure the client application to use HTTPS URLs to access SGD web services. The client application must also be configured to use the JRE software truststore for your JSP technology container.

For client applications that use the SGD package, the web services URLs are configured in the Resources.properties file in the shared library directory on the JSP technology container on the remote host. See Relocating the Webtop for details. For each of the web services listed, change the URL to an HTTPS URL, for example, https://server.example.com:443/axis/services/document/print.

Once you have added the certificates, add the details of the JRE software truststore on the remote host to the Resources.properties file, by adding the following lines:

keystore=keystore-path
keystorepass=password

After changing the Resources.properties file, you must restart your JSP technology container. You must also make sure the web server is configured to accept HTTPS connections and restart it.

Configuring the CA Certificates Truststore on the SGD Server

On the SGD server, you might have to import CA certificates into the CA certificates truststore for the SGD server. This truststore is used for the HTTPS connections from the SGD server to the remote host. This connection is used to send events from the SGD server.

SGD supports a number of CAs by default. You only need to import CA certificates if the SSL certificate for the remote host is signed by an unsupported CA, or by an Intermediate CA. See The CA Certificate Truststore for details of how to check for supported CAs and how to import CA certificates.

Enabling SGD Security Services

You enable SGD security services from the command line.

When you first enable security services, you must restart all the SGD servers and the SGD web servers in the array. Once security is enabled, security services are available whenever SGD restarts.

If you change your SGD configuration, for example by enabling firewall traversal or by installing a new server SSL certificate, you must restart the SGD server and the SGD web server.

If firewall traversal is enabled, you must start the SGD server before starting the SGD web server. If firewall traversal is not enabled, start the SGD web server before starting the SGD Server. If you use the tarantella start or tarantella restart commands without any command options, the SGD server and SGD web server are always started in the correct order depending on your firewall traversal configuration.

procedure icon  How to Enable SGD Security Services for an SGD Server

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the SGD host.

  2. Enable SGD security services.

    Use the following command:


    # tarantella security start
    

  3. Restart the SGD server and SGD web server.

    Use the following command:


    # tarantella restart --https 
    

Using Connection Definitions

Connection definitions can be used to control whether a secure connection or a standard connection is used between an SGD Client and an SGD server. The connection type can depend on the following factors:

If SGD security services are not enabled on an SGD server, secure connections to that server are not available regardless of the user’s connection definitions.



caution icon

Caution - If SGD is configured for firewall traversal, do not use connection definitions. You always use secure connections with firewall traversal. See Using Firewall Traversal.



If you use the SGD Gateway, connection definitions are only used for direct client connections that are not routed through an SGD Gateway, see The SGD Gateway for more information.

To use connection definitions, you must do the following:

When connection definition processing is enabled, you configure the connection definitions to determine which users receive standard or secure connections. You configure connection definitions at an organization level, which you can override at an organizational unit level or user profile level. By default, all users can receive secure connections if SGD security services are enabled.

Connection definitions use the IP address or DNS name of the client device and the SGD server to determine whether standard or secure connections are used. The order of the connection definitions is important as the first match is used. Connection definitions can include the * or ? wildcards to match more than one DNS name or IP address.

For example, the user profile object for Elizabeth Blue has the following connection definitions:


Client Device Address SGD Server Address Connection Type
*.example.com * Standard
* * Secure

If Elizabeth logs in to SGD from her usual client device, sales1.example.com, the first connection definition in the list matches and Elizabeth receives a standard connection.

If Elizabeth logs in to SGD from a client device that is not part of example.com, the second connection definition in the list matches and Elizabeth receives a secure connection.

If Elizabeth had no connection definitions, the connection type is determined by the connection definitions of a parent object in the organizational hierarchy.

procedure icon  How to Enable Connection Definition Processing

  1. In the Administration Console, go to the Global Settings -> Security tab.

  2. Select the Connection Definitions check box.

  3. Click Save.

procedure icon  How to Configure Connection Definitions

  1. In the Administration Console, go to the User Profiles tab and select the object you want to configure.

    It is best to configure connection definitions for organization and organizational unit objects as this configures connections definitions for many users at once and makes administration easier.

  2. Go to the Security tab.

  3. Add a connection definition.

    DNS names or IP addresses in a connection definition can include the * or ? wildcards.

    1. In the Connection Definitions table, click the Add button.

      The Add New Connection Definition window is displayed.

    2. In the Client Device Address field, type an IP address or DNS name.

    3. In the Secure Global Desktop Server Address, type an IP address or DNS name.

    4. Select a Connection Type from the list.

    5. Click Add.

      The Add New Connection Definition window closes and the connection definition is added to the Connection Definitions table.

  4. Add further connection definitions as needed.

    The Connection Definitions table also shows the definitions that are inherited from parent objects in the organizational hierarchy.

  5. Use the Move Up and Move Down buttons to change the order of the connection definitions.

    The order of the connection definitions is important. The first matching entry is used. Make sure the most specific definitions appear before more general ones.

Client Connections and Security Warnings

When using secure connections between client devices and SGD, users see some or all of the following security warnings:



Note - Users might see these warnings even if SGD security services are not enabled. This is because the initial connection between an SGD Client and an SGD server is always secure.



This section describes why these warnings occur and what you can do about them.

Browser and Java Plugin Tool Security Warnings

If you have enabled secure connections (HTTPS) to the SGD web server, users see a warning if the CA or root certificate used to sign the web server SSL certificate is not available in the browser’s certificate store. To enable the web server SSL certificate to be validated without displaying a security warning, import the CA or root certificate into the user’s browser certificate store. Use the browser’s tools to do this.

If Java technology is enabled in the browser, the Java Plugin tool might also warn users about the web server’s SSL certificate. This depends on the configuration in the Java Control Panel. By default, the Java Plugin tool is configured to use the certificates in the browser certificate store. If the Plugin tool is not configured to do this, you might have to import the CA or root certificate using the Java Control Panel.

SGD Server SSL Certificate Security Warnings

When a user logs in to an SGD server that has a server SSL certificate, the SGD Client validates the certificate before proceeding.

If there is a problem with a server SSL certificate, users see a security warning message. The security warning message enables users to view the SSL certificate details before deciding to accept the SSL certificate permanently or temporarily, or to reject it. FIGURE 1-3 shows an example security warning message.

FIGURE 1-3   Example SGD Server SSL Certificate Security Warning Message

Screenshot of an example security warning message.


If users reject the SSL certificate, the connection to SGD is terminated.

If users accept the SSL certificate temporarily, and they agree to the initial connection, the SSL certificate details are cached for the lifetime of the user session. When users next log in, they are prompted about the SSL certificate again. If users accept the SSL certificate permanently, and they agree to the initial connection, they are not prompted about the SSL certificate again. For details about agreeing to the initial connection, see Untrusted Initial Connection Warnings.

Users see security warnings about SSL certificates in the following circumstances:

  • Invalid dates – The current date is earlier than the Not Before date in the SSL certificate, or the current date is later than the Not After date in the SSL certificate

  • Incorrect host name – The name of the host the SGD Client is connecting to does not match the Subject or Subject Alt Name in the SSL certificate

  • Issuer unknown – The SSL certificate is signed by an unsupported CA

For details about how to avoid issuer unknown security warnings, see Avoiding Issuer Unknown Security Warnings.

Untrusted Initial Connection Warnings

SGD requires users to authorize their connections to SGD so that they only connect to servers they trust. The first time a user connects to an SGD server, they see an Untrusted Initial Connection message advising that they are connecting to a server for the first time, as shown in FIGURE 1-4.

FIGURE 1-4   Untrusted Initial Connection Warning

Screen capture of the Untrusted Initial Connection
warning.


Users can check the SSL certificate details by clicking the View Certificate button and checking that the Validity and Subject details are correct. Users must do this before clicking Yes to agree to the connection. When a user agrees to a connection, the following files are updated on the client device:

  • hostsvisited

  • certstore.pem

The hostsvisited and certstore.pem files are stored in the same location as the user’s client profile cache. See About the Profile Cache for details.

When a user agrees to a connection to an SGD server, the hostsvisited file on the client device is updated with the name of the SGD server. If the server SSL certificate is signed by an unsupported CA, the fingerprint of the CA certificate is also added. The user is not prompted about the connection again, unless there is a problem.

When a user agrees to a connection to an SGD server, and the server SSL certificate is valid, the server SSL certificate is added to the certstore.pem file on the client device.

If there is a problem with the server SSL certificate, for example because it is signed by an unsupported CA, users see a certificate security warning, as described in SGD Server SSL Certificate Security Warnings. If a user permanently accepts the SSL certificate, or the SSL certificate and its CA chain, and agrees to the connection to an SGD server, the SSL certificate is added to the certstore.pem file on the client device. When the user next logs in, they are not prompted about the SSL certificate. If a user accepts the SSL certificate temporarily, and they agree to the connection to an SGD server, the SSL certificate is not added to the certstore.pem file on the client device. When the user next logs in, they are prompted about the SSL certificate.

If there is a problem with the connection, for example because the server SSL certificate has changed, a Potentially Unsafe Connection message displays, as shown in FIGURE 1-5.

FIGURE 1-5   Potentially Unsafe Connection Message

Screen capture of the Potentially Unsafe Connection
warning.


To ensure that users only connect to SGD servers that are trusted, SGD Administrators can do the following:

See also Avoiding Issuer Unknown Security Warnings for details of how to prevent users from seeing issuer unknown security warnings.

Using a Preconfigured hostsvisited File

A preconfigured hostsvisited file can be used to prevent users from seeing a warning when the SGD Client first connects to an SGD server. You can also use it to restrict the SGD servers to which the SGD Client can connect.

To use a preconfigured hostsvisited file, first create a file containing the host names of all the SGD servers. If the server SSL certificate for an SGD server is signed by an unsupported CA, you must also add the fingerprint of the CA certificate. The easiest way to do this is to copy and edit an existing hostsvisited file, and then install it on client devices. You can also obtain the CA certificate fingerprint using the tarantella security fingerprint command.

You can manually add an <allowhostoverride> line to the hostsvisited file. If the value of <allowhostoverride> line is 0, the SGD Client can only connect to SGD servers that have entries in the hostsvisited file. If the value of <allowhostoverride> line is 1, or if the <allowhostoverride> line is missing, the SGD Client can connect to any SGD server. Users only see a warning when the SGD Client connects to an SGD server that is not listed in the hostsvisited file.The following is an example hostsvisited file.


<?xml version="1.0" encoding="UTF-8" ?>
<array>
 <allowhostoverride>0</allowhostoverride>
 <server peername="boston.indigo‐insurance.com">
  <certfingerprint>51:B7:6D:FA:6E:3B:BE:ED:37:73:D4:9D:5B:C5:71:F6
  </certfingerprint>
 </server>
</array>

Avoiding Issuer Unknown Security Warnings

Issuer unknown security warnings occur when the server SSL certificate for an SGD server is issued by an unsupported CA. The warning displays because the issuer of certificate cannot be validated.

The easiest way to avoid issuer unknown security warnings is to ensure that a server SSL certificate is signed by a supported CA. See Supported Certificate Authorities for details.

To enable the SSL certificate to be validated, you must install the CA certificate or certificate chain. However, even if you install the CA certificate, users see a security warning about the SLL certificate the first time they connect to the SGD server. The only way to prevent users from being warned about the certificate is add the server SSL certificate to the certstore.pem file on the client device. The server SSL certificate is stored in the /opt/tarantella/var/tsp/cert.pem file on each SGD server.

The SSL Daemon

The SSL Daemon is the SGD component that handles secure connections between SGD Clients and SGD servers. On the SGD host, the SSL Daemon is listed as one or more ttassl processes.

By default, the SSL Daemon listens on TCP port 5307 for AIP traffic that has been encrypted with SSL. However, if you are using firewall traversal, the SSL Daemon listens on port 443, and accepts AIP and HTTPS traffic. In this situation, the Daemon handles the AIP traffic but forwards the HTTPS traffic on to the SGD web server.

Sometimes the load on the SSL Daemon can affect performance. You can tune the SSL Daemon so that it starts new processes as the load increases. If you have a multi-processor server, tuning the number of SSL Daemon processes to the number of processors can also improve performance.

SSL Daemon tuning is specific to each SGD server. You have to tune each server individually.

By default, one SSL Daemon process starts when SGD security services are started and, as the number of connections increases, no further processes are started. You can increase the maximum number of SSL Daemon processes. This enables the SSL Daemon to start new processes as the number of connections increases, up to the maximum number of processes. If you find you regularly need multiple SSL Daemon processes, you can increase the minimum number of SSL Daemon processes. This controls the minimum number of SSL Daemon processes that are started automatically when SGD security services are started. See How to Tune SSL Daemon Processes for detail of how to change the maximum and minimum number of SSL Daemon processes.



caution icon

Caution - Once an SSL Daemon process is started, it continues to run even if the load reduces.



You can use log filters to monitor SSL Daemon processes. By default, all errors are logged. You can increase the amount of log output to assist with tuning or for troubleshooting, see How to Change SSL Daemon Log Filters. The log filters you use have the same format as the log filters used for the SGD server. See Using Log Filters to Troubleshoot Problems With an SGD Server. The same severity and destination file options can be used. By default, all errors are logged to the /opt/tarantella/var/log directory.

If the SSL Daemon exits unexpectedly, it makes 10 attempts to restart before failing completely. You can change the maximum number of restart attempts, see How to Change SSL Daemon Maximum Restart Attempts.

procedure icon  How to Tune SSL Daemon Processes

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in to the SGD host as superuser (root).

  2. Change the minimum number of SSL Daemon processes.

    Use the following command:


    # tarantella config edit \
    --tarantella‐config‐ssldaemon‐minprocesses num
    

    The default minimum is 1.

  3. Change the maximum number of SSL Daemon processes.

    Use the following command:


    # tarantella config edit \
    --tarantella‐config‐ssldaemon‐maxprocesses num
    

    The default maximum is 1.

  4. Restart the SGD server.

    You must restart the SGD server for the change to take effect.

procedure icon  How to Change SSL Daemon Log Filters

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in to the SGD host as superuser (root).

  2. Change the SSL Daemon log filters.

    Use the following command:


    # tarantella config edit \
    --tarantella‐config‐ssldaemon‐logfilter filter ...
    

    Use a comma-separated list of filters.

    The default filters are:

    ssldaemon/*/*error,multi/daemon/*error:sslmulti%%PID%%.log

  3. Restart the SGD server.

    You must restart the SGD server for the change to take effect.

procedure icon  How to Change SSL Daemon Maximum Restart Attempts

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log in to the SGD host as superuser (root).

  2. Change the maximum number of SSL Daemon restart attempts.

    Use the following command:


    # tarantella config edit \
    --tarantella‐config‐ssldaemon‐maxrestarts num
    

    The default maximum number is 10. Setting the number of restart attempts to -1 means there is no limit on the number of restart attempts.

  3. Restart the SGD server.

    You must restart the SGD server for the change to take effect.

Selecting a Cipher Suite for Secure Client Connections

You can select the cipher suite that is used for secure connections between SGD Clients and SGD servers, see How to Change the Cipher Suite for Secure Client Connections for details.

A cipher suite is a set of cryptographic algorithms used for the following:

A cipher suite specifies one algorithm for each of these tasks. For example, the RSA_WITH_RC4_128_MD5 cipher suite uses RSA for key exchange, RC4 with a 128‐bit key for bulk encryption, and MD5 for message authentication.

TABLE 1-1 lists the supported cipher suites.


TABLE 1-1   Supported Cipher Suites for Secure Client Connections
Supported Cipher Suite Client Preference OpenSSL Name
RSA_WITH_AES_256_CBC_SHA 1 AES256-SHA
RSA_WITH_AES_128_CBC_SHA 2 AES128-SHA
RSA_WITH_3DES_EDE_CBC_SHA 3 DES-CBC3-SHA
RSA_WITH_RC4_128_SHA 4 RC4-SHA
RSA_WITH_RC4_128_MD5 5 RC4-MD5
RSA_WITH_DES_CBC_SHA 6 DES-CBC-SHA

When selecting a cipher suite, you use the OpenSSL Name of the cipher suite, as shown in TABLE 1-1. If you select more than one cipher suite, the SGD Client determines which suite is used, based on the client preference order shown in the table above.

By default, the SGD Client uses the RSA_WITH_AES_256_CBC_SHA cipher suite.

procedure icon  How to Change the Cipher Suite for Secure Client Connections

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the primary SGD server in the array.

  2. Stop all the SGD servers in the array.

  3. Specify the cipher suite.

    Use the following command:


    # tarantella config edit \
    --tarantella-config-security-ciphers cipher-suite ...
    

    where cipher-suite is the OpenSSL Name of a cipher suite.

    If you specify more than one cipher-suite, use a colon-separated list.

    The default setting is AES256-SHA:RC4-MD5

  4. Restart all the SGD servers in the array.

    You must restart the SGD servers for the change to take effect.

Using External SSL Accelerators

SGD supports the use of external SSL accelerators. Performance can be improved by off‐loading the processor‐intensive transactions required for SSL connections to an external SSL accelerator. External SSL accelerators can also be used to centralize server SSL certificates.

To use an external SSL accelerator with SGD, do the following:

When you enable external SSL accelerator support, the SGD SSL Daemon can accept plain text traffic on the port configured for secure connections, and forward it to SGD as SSL traffic it had decrypted itself.

If you are using server‐side proxy servers, you might have to configure your array routes for external SSL accelerators. See Configuring Server-Side Proxy Servers.

procedure icon  How to Enable External SSL Accelerator Support

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. In the Administration Console, go the Secure Global Desktop Servers tab and select an SGD server.

  2. Go to the Security tab.

  3. Select the SSL Accelerator Support check box.

  4. Click Save.

  5. Restart the SGD server.

    You must restart the SGD server for the change to take effect.


Securing Connections Between SGD Servers

In a standard installation, the data transmitted between the SGD servers in an array is not encrypted. SGD Administrators can secure the connections between array members using SSL. Using SSL for these connections ensures the integrity of the data as follows:

Using SSL in this way is known as secure intra-array communication.

Using Secure Intra-Array Communication

Using secure intra-array communication means that each SGD server in the array has to have a valid certificate that has been signed by a trusted certificate authority (CA).

As the certificates used for secure intra-array communication are used only internally by SGD, the primary SGD server in the array acts as the CA. The primary SGD server has a self-signed CA certificate and a private key. All secondary SGD servers in the array have a copy of the primary SGD server’s CA certificate in a trusted certificate store, the truststore.

All SGD servers in the array, including the primary, have a peer SSL certificate and a private key. The peer SSL certificate is signed with the primary SGD server’s CA certificate and contains a common name (CN) which is the peer DNS name of the SGD server. As the peer SSL certificates are created using a self-signed CA certificate, they cannot be used to secure any other SGD-related connection. These certificates are referred to as peer SSL certificates to distinguish them from other types of SSL certificates.

When one SGD server in the array connects to another, including when using an administration tool, the SGD server being connected to presents its peer SSL certificate as part of the SSL negotiation. The connecting server evaluates the peer SSL certificate and checks the following:

If the peer SSL certificate is valid, a secure connection is established.

Secure intra-array communication can only be enabled on an SGD server that is not joined with other SGD servers in an array. When secure intra-array communication is enabled for an array, an SGD server can only join the array if it also has secure intra-array communication enabled.

Managing CA and Peer SSL Certificates

When you enable secure intra-array communication, SGD automatically generates and distributes the CA and peer SSL certificates to the members of the array. Whenever there is a change in the array structure, SGD automatically updates the CA and peer SSL certificates. The following table summarizes what happens.


Array Change Action
Server joins the array
  1. The primary SGD server CA certificate is installed on the new secondary server.

  2. The new secondary SGD server obtains a new peer SSL certificate signed with the primary SGD server CA certificate.

Server leaves the array
  1. The detached SGD server becomes the primary SGD server in an array containing one server.

  2. The detached SGD server creates a new CA certificate for itself.

  3. The detached SGD server creates a new peer SSL certificate for itself.

New primary server appointed
  1. The new primary SGD server generates a new CA certificate.

  2. The new primary CA certificate is installed on all secondary SGD servers.

  3. All SGD servers obtain a new peer SSL certificate signed with the new primary SGD server CA certificate.


SGD Administrators can use the tarantella security peerca --show command to view certificates in the truststore. The truststore contains the primary SGD server’s CA certificate.

procedure icon  How to Enable Secure Intra-Array Communication

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

You can only enable secure intra-array communication from the command line.

  1. Dismantle the array.

    If secure intra-array communication is not enabled for an array, you must dismantle the array, enable secure intra-array communication on each SGD server, and then rebuild the array.

    1. Log in as an SGD Administrator on the primary SGD server.

    2. Dismantle the array by detaching all the secondary servers.

      Use the following command:


      $ tarantella array detach --secondary server
      

    3. Check the status of each SGD server.

      Run the tarantella status command on each array member to check that the array is completely dismantled.

  2. Enable secure intra-array communication.

    Secure intra-array communication can only be enabled on an SGD server that is not joined with other SGD servers in an array.

    You enable secure intra-array communication for an SGD server as follows.

    1. Log in as superuser (root) on the SGD server.

    2. Stop the SGD server.

    3. Enable secure intra-array communication.

      Use the following command:


      # tarantella config edit \
      --tarantella-config-security-peerssl-enabled 1
      

    4. Start the SGD server.

  3. Rebuild the array.

    When secure intra-array communication is enabled for an array, an SGD server can only join the array if it also has secure intra-array communication enabled.

    Only add one server to an array at a time.

    When secure intra-array communication is enabled, you add an SGD server to an array as follows.

    1. Log in as superuser (root) on the SGD server that you want to add to the array.

    2. Display the fingerprint of the SGD server’s CA certificate.

      Use the following command:


      # tarantella security peerca --show
      

    3. Make a note of the fingerprint of the SGD server’s CA certificate.

    4. Log in as superuser (root) on the primary SGD server in the array.

    5. Join the SGD server to the array as a secondary server.

      Use the following command to add the SGD server.


      # tarantella array join --secondary serv
      

      You are prompted to trust the secondary SGD server’s CA certificate, and the fingerprint of the certificate is displayed.

    6. Check that the fingerprint is correct and complete the array join.

      Check that the certificate fingerprint matches the fingerprint displayed in Step . This is important as it verifies that the primary SGD server is communicating with the genuine secondary SGD server.

      If the fingerprints match, complete the array join by accepting the secondary SGD server’s CA certificate.

    7. Check the status of the array.

      Use the tarantella status command to check the status of the array.

Selecting a Cipher Suite for Secure Intra‐Array Communication

You can select the cipher suite that is used for secure connections between the SGD servers in the array, see How to Change the Cipher Suite for Secure Intra‐Array Communication for details.

A cipher suite is a set of cryptographic algorithms used for the following:

A cipher suite specifies one algorithm for each of these tasks. For example, the RSA_WITH_RC4_128_MD5 cipher suite uses RSA for key exchange, RC4 with a 128‐bit key for bulk encryption, and MD5 for message authentication.

TABLE 1-2 lists the supported cipher suites.


TABLE 1-2   Supported Cipher Suites for Secure Intra-Array Communication
Supported Cipher Suite JSSE Name
RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_SHA
RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_MD5
RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA

When selecting a cipher suite, you use the Javatrademark Secure Socket Extension (JSSE) name of the cipher suite, as shown in TABLE 1-2. If you select more than one cipher suite, the first cipher suite listed is used.

By default, SGD uses the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite.

procedure icon  How to Change the Cipher Suite for Secure Intra‐Array Communication

Ensure that no users are logged in to the SGD servers in the array and that there are no running application sessions, including suspended application sessions.

  1. Log in as superuser (root) on the primary SGD server in the array.

  2. Stop all the SGD servers in the array.

  3. Specify the cipher suite.

    Use the following command:


    # tarantella config edit \
    --tarantella-config-security-peerssl-ciphers cipher-suite ...
    

    where cipher-suite is the JSSE name of a cipher suite.

    If you specify more than one cipher-suite, use a colon-separated list.

    The default setting is TLS_RSA_WITH_AES_128_CBC_SHA.

  4. Start all the SGD servers in the array.


Securing Connections to Application Servers with SSH

SGD can use SSH to provide secure connections between SGD servers and application servers. SSH provides the following benefits:

This section includes the following topics:

SSH Support

SGD works with SSH version 2.x or later. Because of SSH version compatibility problems, use the same major version of SSH, either version 2 or version 3, on all SGD hosts and application servers.

SGD can automatically detect that SSH is installed on the SGD host if SSH is installed in one of the following directories:

If you want to run the SSH client from a different location, or you want to specify particular command-line arguments for the client, see Configuring the SSH Client for details.

To connect to an application server using SSH, the following must be true:

To connect to an X application using SSH, you must enable X11 forwarding. See Enabling X11 Forwarding for details.

Configuring the SSH Client

When using SSH with SGD, you can configure the command-line arguments used by the SSH client. The arguments can be configured globally, for individual applications, or a combination of both.

You configure the global options for the SSH client by setting the TTASSHCLIENT environment variable, see How to Set Global SSH Client Options for details. Use the global SSH client configuration in the following situations:

You configure the application options for the SSH client by configuring the SSH Arguments attribute for the application object, see How to Set Application SSH Client Options for details.

You can combine the global and application SSH client configuration to set the path to the SSH client and set the command-line arguments.



Note - If you do this, any global command-line arguments are ignored.



The following table shows the effect of global and application configuration on the ssh command used.


Global Configuration Application Configuration SSH Command Used
[none] [none] ssh -l user@host
[none] -X ssh -X -l user@host
/usr/ssh -X [none] /usr/ssh -X -l user@host
/usr/ssh -X -p port /usr/ssh -p port -l user@host

procedure icon  How to Set Global SSH Client Options

Ensure that no users are logged in to the SGD server and that there are no running application sessions, including suspended application sessions.

  1. Log on as superuser (root) on the SGD host.

  2. Stop the SGD server.

  3. Set the TTASSHCLIENT environment variable.

    Include the full path to the SSH client program and any required command‐line arguments. For example:


    # TTASSHCLIENT="/usr/local/bin/ssh -q -X"; export TTASSHCLIENT
    



    Note - If you only want to set command-line arguments for the SSH client, you have to include the full path to the SSH client program, even if the SSH program is in a location where SGD can detect it.



  4. Restart the SGD server.

procedure icon  How to Set Application SSH Client Options

  1. In the Administration Console, go the Applications tab and select the application.

  2. Go to the Launch tab.

  3. Ensure that the ssh option is selected for the Connection Method.

  4. In the SSH Arguments field, type the SSH arguments you want to use for the application.

  5. Click Save.

Enabling X11 Forwarding

To display X applications using SGD using an SSH connection, you must enable X11 forwarding.

procedure icon  How to Enable X11 Forwarding

  1. Log in as superuser (root) on the SGD host.

  2. Configure the SSH daemon.

    Edit the sshd_config file and add the following line:

    X11Forwarding yes

  3. Configure the SSH client.

    Do either of the following:

    • Edit the ssh_config file and include the following lines:

      ForwardAgent yes

      ForwardX11 yes

    • Configure the SSH client to use the -X command-line argument.

      See Configuring the SSH Client for details.

  4. Restart the SSH daemon.

Using SSH and the X Security Extension

SGD supports the X Security extension. The X Security extension only works with versions of SSH that support the -Y option. For OpenSSH, this is version 3.8 or later. You enable the X security extension by configuring the application objects individual applications as follows:

procedure icon  How to Enable the X Security Extension

  1. In the Administration Console, go to the Applications tab and select the application.

  2. Go to the Launch tab.

  3. Ensure that the ssh option is selected for the Connection Method.

  4. Select the X Security Extension check box.

  5. Click Save.

Using SSH and X Authorization

If SSH connections fail when X authorization is enabled, you might have to run the SSH daemon in IPv4-only mode because SGD might not support the X Security extension used on your server. You enable IP version 4 mode by editing your system SSH configuration file. For example:



Note - If the SSH configuration file does not exist on your system, you can create it.



You must restart the SSH daemon after making this change.

Using Advanced SSH Functions

Certain SSH functionality, such as client keys, requires that the SSH client process runs as a privileged user. However, for security reasons, the SGD server processes and the SSH client process run as a non‐privileged user.

To use advanced SSH functions, you must make the SGD ttasshhelper application a setuid root process. You do this by running the following commands as superuser (root) on each SGD server in the array:


# chown root /opt/tarantella/bin/bin/ttasshhelper
# chmod 4510 /opt/tarantella/bin/bin/ttasshhelper



caution icon

Caution - If you make these changes, you must protect your SGD servers from unauthorized access.



Known Limitation With Client Keys

If you are using the SSH client keys functionality, users might be prompted for a user name and password when they start an application. Users are prompted because SGD needs to know the user name to use for the SSH connection. Although users are also prompted for a password, the password is not actually used. Users are only prompted for a user name and password if they do not have an entry in the password cache for the application server, or if the password cache is disabled. If users are prompted, they only need to provide a user name. The password field can be left blank.