Exit Print View

Oracle Secure Global Desktop Administration Guide for Version 4.6

Document Information

Preface

1.  Networking and Security

2.  User Authentication

3.  Publishing Applications to Users

4.  Configuring Applications

5.  Client Device Support

Printing

Overview of SGD Printing

Setting Up Printing

Configuring Microsoft Windows Application Servers for Printing

Configuring UNIX and Linux Platform Application Servers for Printing

Configuring an SGD Server for Printing

Configuring Printing to Microsoft Windows Client Devices

Configuring Printing to UNIX, Linux, and Mac OS X Platform Client Devices

Managing Printing

Users Cannot Print From Applications Displayed Through SGD

Troubleshooting Other Printing Problems

Client Drive Mapping

Setting Up Client Drive Mapping

Configuring UNIX and Linux Platform Application Servers for CDM

Configuring an NFS Share for CDM

Starting CDM Processes on the Application Server

Configuring Microsoft Windows Application Servers for CDM

Enabling CDM Services in SGD

Running UNIX Platform CDM With Another SMB Service

Configuring the Client Drives Available to Users

Troubleshooting Client Drive Mapping

Logging for CDM

Audio

Setting Up Audio

Configuring Microsoft Windows Application Servers for Audio

Configuring UNIX and Linux Platform Application Servers for Audio

Configuring X Applications for Audio

Enabling SGD Audio Services

Configuring Client Devices for Audio

Troubleshooting Audio in Applications

Copy and Paste

Using Copy and Paste

Controlling Copy and Paste in Applications

An Example of Using Clipboard Security Levels

Tips on Configuring Copy and Paste

Copy and Paste Troubleshooting

Smart Cards

Using Smart Cards With Windows Applications

Setting Up Access to Smart Cards

Configuring the Microsoft Windows Application Server for Smart Cards

Enabling Smart Cards in SGD

Configuring Smart Card Readers on Client Devices

How to Log In to a Microsoft Windows Application Server With a Smart Card

Troubleshooting Smart Cards

Serial Ports

Setting Up Access to Serial Ports

Configuring the Microsoft Windows Application Server

Enabling Serial Port Access in SGD

Configuring the Client Device

6.  SGD Client and Webtop

7.  SGD Servers, Arrays, and Load Balancing

A.  Global Settings and Caches

B.  Secure Global Desktop Server Settings

C.  User Profiles, Applications, and Application Servers

D.  Commands

E.  Login Scripts

F.  Third-Party Legal Notices

Glossary

Index

Client Drive Mapping

Client drive mapping (CDM) enables SGD users to access the drives on their client device from applications running on UNIX, Linux, or Microsoft Windows platform application servers.

This section describes how to configure CDM for SGD users. Common problems when using CDM in SGD are also covered, along with tips on how to fix them.

This section includes the following topics:

Setting Up Client Drive Mapping

Setting up CDM involves the following configuration steps:

  1. Configure the application servers for CDM.

  2. Enable CDM services in SGD.

  3. Configure the drives you want users to access from SGD.

Configuring UNIX and Linux Platform Application Servers for CDM

Configuring UNIX and Linux platform application servers for CDM involves the following steps:

  1. Install the SGD Enhancement Module for UNIX and Linux Platforms.

    The Oracle Secure Global Desktop 4.6 Installation Guide has details of how to install the Enhancement Module.

    The Oracle Secure Global Desktop 4.6 Platform Support and Release Notes has details of the supported platforms for the SGD Enhancement Module.

  2. Configure the Network File System (NFS) share to be used for CDM.

    See Configuring an NFS Share for CDM.

  3. Start the CDM processes on the application server.

    See Starting CDM Processes on the Application Server.

Configuring an NFS Share for CDM

Configuring an NFS share for CDM involves the following:

Configuring a Shared Directory on the Application Server

You must have an NFS server installed and running on the application server. The NFS server must share, or export, a directory to be used for CDM. By default, the directory is /smb. You have to manually create and export this directory.

You can specify an alternative NFS share in the CDM configuration file, /opt/tta_tem/etc/client.prf. Edit the [nfsserver/mount/mountpoint={(/smb)}] setting to reflect the name of the share.

The NFS share must be accessible to localhost, and users must have read and write access to it. Consult your system documentation for details of how to configure an NFS server and export a directory.

Configuring How Client Drives Are Displayed on UNIX Platforms

When CDM is enabled, the user’s client drives or file systems are available by default in the My SGD Drives directory in the user’s home directory. The My SGD Drives directory is a symbolic link to the NFS share that is used for CDM.

You can configure the name and location of the symbolic link by adding settings to the CDM configuration file, /opt/tta_tem/etc/client.prf, as follows:

After making any changes to the CDM configuration file, you must restart the CDM processes on the application server. See Starting CDM Processes on the Application Server for details of how to do this.

Starting CDM Processes on the Application Server

To start the CDM processes on the application server, log in as superuser (root) and use the following commands:

# /opt/tta_tem/bin/tem stopcdm
# /opt/tta_tem/bin/tem startcdm

Configuring Microsoft Windows Application Servers for CDM

To use a Microsoft Windows application server for CDM, drive redirection must be enabled on the application server. Drive redirection is enabled by default.

Enabling CDM Services in SGD

This section describes how to enable CDM services for an array of SGD servers.

CDM can be enabled separately for applications that run on Microsoft Windows application servers (Windows CDM), and for applications that run on UNIX or Linux platform application servers (UNIX platform CDM).

By default, Windows CDM and UNIX platform CDM are disabled.

By default, you cannot use UNIX platform CDM and run a Server Message Block (SMB) service, such as Samba, on the SGD host. See Running UNIX Platform CDM With Another SMB Service for details of the required configuration if you want to use UNIX platform CDM and run an SMB service on the SGD host.

When you enable CDM services, you can also enable or disable dynamic drive mapping. This feature provides support for “hot plugging” of removable drives, such as USB memory sticks, during a user session. Dynamic drive mapping is enabled by default for an SGD array.

How to Enable SGD Client Drive Mapping Services

Changes to CDM only take effect for new user sessions. Users might have to log out of SGD and log in again to access the drives on their client device.

  1. In the Administration Console, display the Global Settings -> Client Device tab.

  2. (Optional) Enable Windows CDM.

    Select the Windows Client Drive Mapping check box.

  3. (Optional) Enable UNIX platform CDM.

    1. Select the Unix Client Drive Mapping check box.

    2. Start UNIX platform CDM services on each server in the array.

      Either restart all the SGD servers in the array, or use the tarantella start cdm command on each SGD server in the array.

      If you restart the SGD servers, ensure that no users are logged in to the SGD server, and that there are no application sessions, including suspended application sessions, running on the SGD server.

  4. (Optional) Enable Dynamic Drive Mapping.

    Dynamic drive mapping is enabled by default for an SGD array.

    Select the Dynamic Drive Mapping check box.

Running UNIX Platform CDM With Another SMB Service

In a default installation, you cannot use UNIX platform CDM and run another SMB service, such as Samba, on the SGD host. This is because they both use Transmission Control Protocol (TCP) port 139. To use CDM for UNIX and Linux platform applications, you must either disable the other SMB server or configure the host to enable more than one service to use TCP port 139.

To enable more than one service to use TCP port 139, you have to configure the SGD host to have more than one Internet Protocol (IP) address. To do this, either install another network interface card (NIC), or use IP aliasing to assign multiple IP addresses to a single NIC. This is described in How to Run UNIX Platform CDM and Another SMB Service on the Same Host.

How to Run UNIX Platform CDM and Another SMB Service on the Same Host

Repeat this procedure for each SGD server that also has an SMB service enabled.

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

  1. Stop the SGD server and configure the IP addresses you want it to bind to for CDM.

    Use the following command:

    # tarantella config edit \
    --tarantella-config-cdm-externalnbtaddress ip-address ...

    The default setting for ip-address is *, which means bind to all interfaces. Separate each IP address with a space.

  2. When you have configured the IP addresses, start the SGD server.

  3. Configure the other SMB service, or services, to bind to a different IP address.

Configuring the Client Drives Available to Users

You configure the client drives you want users to access with the Client Drive Mapping attribute on the Client Device tab for user profiles, organizational unit, and organization objects. CDM uses inheritance. You define access to client drives at an organization level, which you can override at an organizational unit level or user profile level. By default, users have read and write access to all drives.

For Windows applications, you can configure application-specific client drive access with the Client Drive Mapping attribute on the Client Device tab for the Windows application object. This overrides any CDM settings configured for organization, organizational unit, or user profile objects. The order of precedence when configuring CDM for Windows application objects is: Windows application -> user profile -> organizational unit -> organization.

When a user logs in to an SGD server from a Windows client device, information is gathered about the drives on the client device. For each available drive, the Client Drive Mapping attribute on the user profile is checked. If there is no matching client drive configured, the parent organizational unit’s Client Drive Mapping attribute is checked, and so on up the organizational hierarchy to the organization object.

If a match is found, then the associated access rights are granted for that drive. The access rights for a mapped client drive are shown in brackets after the drive name: (rw)means read-write access, (ro) means read only access.

At each level in the organizational level, you configure a number of drive mapping specifications. Each of these states a client drive letter and the access rights to that drive. For example, you might specify that a user has read-write access to client drive A. The first matching entry in the list is used. Make sure the most specific settings, for example, A or B, appear before more general settings, for example, All Drives.

When a user logs in to an SGD server from a UNIX, Linux, or Mac OS X platform client device, the SGD Client uses a local configuration file to configure access to the client file system. See Configuring the Drives Available to UNIX, Linux, and Mac OS X Platform Client Devices for more details.


Note - Changes to client drive specifications only take effect for new user sessions.


Configuring the Drives Available to UNIX, Linux, and Mac OS X Platform Client Devices

By default, users with UNIX, Linux, and Mac OS X platform client devices have access to their home directory and this is mapped to a drive called My Home.

Users can configure which part of their client file system they can access from applications by editing the $HOME/.tarantella/native-cdm-config configuration file. This file is automatically created when the SGD Client is installed. The file contains detailed instructions for users on how to create mapped drives.

The [CDM] section of this configuration file contains entries of the form <path> <type> <label> where:

Use a separate line for each drive and separate each of the fields with a space or a tab. If either the <path> or the <label> fields contains spaces or tabs, enclose the field in quotes.

You can use environment variables in the <path> or <label> fields. You delimit these with a dollar sign ($). To use a literal $, escape it with another $.

The following is an example configuration file:

[CDM]
$HOME$ fixed "My Home"
/tmp/$USER$ fixed Temp
"/mnt/win/My Documents" fixed "My Local Documents"
...
[/CDM]

Note - Changes to the native-cdm-config configuration file only take effect for new user sessions.


The access rights for a mapped client drive are shown in brackets after the drive name: (rw)means read-write access, (ro) means read only access.

An Example of Configuring Drive Availability for Users

The following example shows how to disable access to all client drives for all users in the Indigo Insurance organization. Only a single user in the organization, Ruby Port, is allowed to access the floppy drive on her Windows computer.

In the Administration Console, go to the Client Device tab and display the Client Drive Mapping table for the o=Indigo Insurance organization object. In the Client Drive Mapping table, select the check box next to All Drives. Click the Edit button and set the Access Rights to None. This disables access to all client drives.

In the Administration Console, go to the Client Device tab and display the Client Drive Mapping table for the Ruby Port user profile object. In the Client Drive Mapping table, click the New button and configure the following settings:

This gives Ruby Port full access to the floppy drive on her Windows computer.

Detecting Removable Drives

If users attach a removable drive such as a Universal Serial Bus (USB) memory stick during a user session, SGD detects and mounts the device automatically. This feature is called dynamic drive mapping.

Dynamic drive mapping is enabled by default for an SGD array.

To use dynamic drive mapping, either Windows CDM or UNIX platform CDM must be enabled.

On UNIX and Linux platform client devices that do not use hardware abstraction layer (HAL) to detect client drives, SGD looks for removable drives by monitoring the locations listed in the [DYNAMICSTORAGE] section of the $HOME/.tarantella/native-cdm-config configuration file. Depending on the client platform, the following default system locations are listed in the [DYNAMICSTORAGE] section of this file.

Client Platform
Location
Type
Linux
/media
removable
Solaris OS
/rmdsk

/cdrom

removable

cdrom

Sun Ray
${DTDEVROOT}/mnt
removable
Mac OS X
/Volumes
removable

You can specify additional directories to be monitored, by adding one or more entries to the [DYNAMICSTORAGE] section. For example, the following entry causes SGD to monitor the /opt directory for removable drives, in addition to the default location for the client platform.

[DYNAMICSTORAGE]
...
/opt removable
[/DYNAMICSTORAGE]

On Mac OS X client devices, virtual drives (.dmg files) are not detected as dynamic drives.

Troubleshooting Client Drive Mapping

The following are common problems when using CDM in SGD:

For UNIX Platform CDM, No Client Drives Are Mapped Within the User’s Session or There Are Fewer Drives Than Expected

Use the following checklist to resolve this problem.

Is the SGD Enhancement Module installed on the application server?

To access client drives from UNIX or Linux platform applications displayed through SGD, the SGD Enhancement Module must be installed on the application server.

The Oracle Secure Global Desktop 4.6 Platform Support and Release Notes has details of the supported platforms for the SGD Enhancement Module.

Is UNIX platform CDM enabled?

In the Administration Console, go to the Global Settings -> Client Device tab and ensure that the Unix Client Drive Mapping check box is selected.

Remember, UNIX platform CDM services only become available when you restart all SGD servers in the array. To manually start CDM services without restarting the array, run the tarantella start cdm command on all members of the array.

Have the user’s client drives been configured correctly?

The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.

For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.

For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If this file is not present, a default version is created automatically when the user next logs in to SGD.

Are UNIX platform CDM processes running?

On the host where SGD is installed, use the following command:

# ps -ef | grep ttacdmd

If UNIX platform CDM processes are running, there are at least two processes with the name ttacdmd.

If there are no any drive mapping processes, use the following command:

# grep cdm /opt/tarantella/var/log/*

Check the output for any messages.

On UNIX and Linux platform application servers, use the following command to check that CDM processes are running:

# /opt/tta_tem/bin/tem status

If CDM processes are not running, use the following command:

# /opt/tta_tem/bin/tem startcdm

If starting CDM processes produces errors such as "Failed to mount /smb", check that the NFS server is running and that the directory being used for CDM is exported correctly.

Check whether another service is using port 4242. If so, edit the /opt/tta_tem/etc/client.prf file and change the port number in the line [nfsserver/mount/port={(4242)}] and restart the CDM processes.

Are you using a proxy server?

Proxy servers drop a connection after a short period of time if there is no activity on the connection.

SGD sends keepalive packets to keep the connection open between the client device and the SGD server and by default this is every 100 seconds. This connection is used for CDM. Try increasing the frequency of the keepalive packets.

See also Proxy Server Timeouts.

Do the version numbers for the SGD Enhancement Module and the SGD server match?

Run the following command on the host where SGD is installed:

$ tarantella version

Make a note of the version number.

On UNIX and Linux platform application servers, run the following command:

$ /opt/tta_tem/bin/tem version

Are other services using TCP port 139?

UNIX platform CDM services must bind to TCP port 139, which is used for SMB services. This port might already be in use, for example by a product such as Samba.

To find out whether any other process is using port 139, stop the SGD server and then run the following commands on the host where SGD is installed:

$ netstat -an | grep 139
$ grep 139 /etc/xinetd.conf

To ensure that UNIX platform CDM services are available, stop any other products that bind to TCP port 139 and restart the SGD server.

Follow the instructions in How to Run UNIX Platform CDM and Another SMB Service on the Same Host.

Have all the client drives been found?

For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info.

For UNIX and Linux platform client devices, this information is written to the SGD Client log file.

For users with UNIX or Linux platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a client drive is not being detected automatically, add an entry to the [CDM] section of this file to specify the location where the drive is mounted.

Does logging reveal any errors?

On UNIX or Linux platform application servers, check for any drive mapping errors in the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory.

See also Logging for CDM.

Is the drive mapping connection between the UNIX or Linux platform application server and the SGD server working?

On UNIX or Linux platform application servers, drive mapping errors are reported to the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory. See also CDM Diagnostics for UNIX or Linux Platform Application Servers.

For Windows CDM, No Client Drives Are Mapped Within the User’s Session or There Are Fewer Drives Than Expected

Use the following checklist to resolve this problem.

Is drive redirection enabled on the Microsoft Windows application server?

Drive redirection is enabled by default on Microsoft Windows application servers.

To access client drives from Windows applications displayed through SGD, the SGD Enhancement Module does not have to be installed on the application server.

Is Windows CDM enabled?

In the Administration Console, go to the Global Settings -> Client Device tab and ensure that the Windows Client Drive Mapping check box is selected.

Have the user’s client drives been configured correctly?

The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.

For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.

For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If this file is not present, a default version is created automatically when the user next logs in to SGD.

Are Windows CDM processes running?

On Microsoft Windows application servers, use the Terminal Services Manager to check that there is an RDP session for the user.

Are you using a proxy server?

Proxy servers drop a connection after a short period of time if there is no activity on the connection.

SGD sends keepalive packets to keep the connection open between the client device and the SGD server and by default this is every 100 seconds. This connection is used for CDM. Try increasing the frequency of the keepalive packets.

See also Proxy Server Timeouts.

Have all the client drives been found?

For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info.

For UNIX and Linux platform client devices, this information is written to the SGD Client log file.

For users with UNIX or Linux platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a client drive is not being detected automatically, add an entry to the [CDM] section of this file to specify the location where the drive is mounted.

Does logging reveal any errors?

On Microsoft Windows application servers, check the Windows Event Viewer for any drive mapping errors.

See also Logging for CDM.

Is the drive mapping connection between the Microsoft Windows application server and the SGD server working?

To check whether the drive mapping connection between the application server and the SGD server is working, use the Terminal Services Manager on the Microsoft Windows application server to check that there is an RDP session for the user. See also CDM Diagnostics for Microsoft Windows Application Servers.

Removable Drives Attached During a User Session are Not Detected Automatically

Check that dynamic drive mapping is enabled for the SGD array.

$ tarantella config list --array-dyndevice

By default, dynamic drive mapping is enabled.

To use dynamic drive mapping, CDM must be enabled for the array. Go to the Global Settings -> Client Device tab in the Administration Console and check that Windows Client Drive Mapping or Unix Client Drive Mapping is enabled.

The Client Drive Mapping attribute on the Client Device tab for organization, organizational unit, and user profile objects determines which client drives each user can access. The user might be configured to have no access to any client drives. Remember to check the ancestor OUs in the organizational hierarchy. CDM settings are inherited, so you can give access to many users with one configuration change.

For Windows applications, application-specific client drive access can be configured using the Client Drive Mapping attribute on the Client Device tab for the Windows application object. Remember that this overrides any CDM settings configured for organization, organizational unit, or user profile objects.

For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries. If a removable drive is not being detected automatically, add an entry to the [DYNAMICSTORAGE] section of this file to specify the location where the drive is mounted.

Check the SGD Client log file for information about whether attached drives have been detected correctly. Set the SGD Client logging level to All to log verbose messages about dynamic drive mapping.

Invalid Password Errors on Microsoft Windows Application Servers

If no client drives are mapped in the Microsoft Windows application session and you see errors such as Add device failed with ERROR_INVALID_PASSWORD in the CDM log output, this can be caused by the LAN Manager authentication level setting. The LAN Manager authentication level controls the authentication protocols used for communications between a client and Microsoft Windows server. If the authentication level is set too high, CDM fails.

The solution is to edit the Security options\Network security\LAN Manager authentication level policy and select Send LM & NTLM - Use NTLMv2 session security if negotiated.

See Microsoft KB article 823659 for more details.

See also Logging for CDM.

More Client Drives Are Mapped Than Expected

Client drives are inherited within the organizational hierarchy, so you can give access to many users with one configuration change. Check the Client Drive Mapping attribute on the organizational unit object that the user profile object belongs to. If necessary, check all ancestors of the user profile, including the top-level organization object. You can override a setting that is specified in a parent organizational unit (OU) or organization object, by configuring the user profile’s Client Drive Mapping attribute. The first matching drive specification is used.

For users with UNIX, Linux, or Mac OS X platform client devices, check that the user’s $HOME/.tarantella/native-cdm-config file is present and has valid entries.

The Recycle Bin Does Not Work As Expected

On Microsoft Windows client devices, client drives accessed through SGD are treated by the application server as network drives. This means that Recycle Bin features are not available for client drives.

Deleting a file does not send the file to the Recycle Bin. The Recycled directory, if present, is not shown as the Recycle Bin, and its contents are not displayed.

Mapped Drives Have Unusual Names

On Microsoft Windows client devices, the names of mapped drives are of the form clientdrive (access) on clientname. For example:

C (rw) on MYCOMPUTER

On UNIX, Linux, and Mac OS X platform client devices, the names of mapped drives are configured in the user’s $HOME/.tarantella/native-cdm-config file. Check that this file has valid entries.

CDM Limitations for Shared Users

On Unix or Linux platform application servers, access to client file systems is given to users based on their UNIX system user ID and standard NFS file system privileges. If a shared account is used to access applications, CDM is not available. This is because SGD has no way to distinguish between these users, as they all have the same user ID.

Disabling CDM for a Client Device

For security purposes, you may want to disable CDM for a client device.

To disable CDM for the client device, edit the <enablecdm> entry in the <localsettings> section of the client profile. A setting of 0 disables CDM.

Logging for CDM

Logging can be used to diagnose problems with CDM. You configure and use logging for the SGD array and for application servers, as follows:

Enabling CDM Logging for the SGD Array

Add the following filters in the Log Filters field on the Monitoring tab of the Administration Console.

cdm/*/*:cdm%%PID%%.jsl
cdm/*/*:cdm%%PID%%.log
server/deviceservice/*:cdm%%PID%%.log
server/deviceservice/*:cdm%%PID%%.jsl
CDM Diagnostics for Microsoft Windows Application Servers

On Microsoft Windows application servers, drive mapping errors are written to the Windows Event Viewer.

CDM Diagnostics for UNIX or Linux Platform Application Servers

On UNIX or Linux platform application servers, drive mapping errors are reported to the clerr.log and the clPID.log files in the /opt/tta_tem/var/log directory.

SGD Client Logging for Client Devices

By default, the SGD Client logs any warning messages about client drives. Log messages are stored to a file, tcc.txt on the client device.

To record detailed information about CDM, set the SGD Client logging level to All. See SGD Client Logging for more information about configuring and using SGD Client logging.

For Windows client devices, the SGD Client displays information about the drives it has found. Click the right mouse button on the System Tray icon and select Connection Info. CDM information is written to the SGD Client log file.

For UNIX and Linux platform client devices, CDM information is written to the SGD Client log file.